Instantiating Conveters in Backing Beans

[De...@ak.blm.gov]

Like most of you, there are plenty of places in my backend beans where I 
grab an identifying value from the request and use it to get an 
object/resultSet from the ORM/JDBC.  I prefer to put this code in a 
Converter but I just can't see how to do this when a user navigates from 
one view to another (user clicks on an item in a list of Customers, goes 
to a form for just that Customer).

Usually Converters are "marketed" as a part of the "Apply Request Values" 
phase.  Perhaps there is something wrong w/ my eyes, but I don't see why 
they cannot be created in the backing bean as well.  After all, there are 
some use cases where validation and messaging are more convenient from the 
backing bean. 

Do any of you see any risks w/ this approach?  before I start doing it all 
over my project ;-)

Dennis Byrne

Re: Instantiating Conveters in Backing Beans

[De...@ak.blm.gov]

> You can certainly use a converter that is bound to a backing bean 
property:

Hmm... this had never occurred to me.
 
> where "intConverter" might be a property of type IntegerConverter. 
> Sun Java Studio Creator does this kind of thing for you when you
> explicity assign a Converter to a component.

Does Java Studio Creator have any template way to handle the situation I 
describe above?  My shop is always arguing about the best way to take a 
user to a "foo page" after they have selected a foo from an "foos page". 
Here is an excerpt from a meeting I have in few hours:

1.) manual request parse
        A.) description:
                <f:param name=”id” value=”#{backendbean.item.id}”/>
                String id = request.getParam(“id”);
                if(id != null && ! “”.equals(id)){ // biz. Logic }
        B.) pros – works everywhere
        C.) cons - minor JSP/Backend bean coupling, more coupling w/out 
forceId, lots of code, just like ASP/PHP
2.) UIData/DataModel.getRowData()
        A.) Description:
                h:commandLink
                YourClass object = (YourClass)dm.getRowData()
        B.) pros – least code
        C.) cons - can only be used w/ a dataTable; concurrency problems 
w/ session scoped model; must go beyond the spec in order to safely do 
this with request scoped backend bean
3.) ActionEvent walking
        A.) Description
                <h:commandLink action=”#{foo.boo}” 
actionListener=”#{foo.foo}”><f:param name=”id” value=”X”></h:commandLink>
                String id = 
(String)ActionEvent.getComponent().getChildren().get().getValue()
        B.) pros – similar to manual request parsing
        C.) cons – similar to manual request parsing, sacrifices 
navigation abilities because there is no return value.
4.) Converters
        A.) pros – transparency
        B.) cons – can’t be used when going from a list of Customers to a 
page for Customer #X , Spec author says No ;-)

At this point, I'm pretty much just going to go in there are say that 
there is no one way to handle the situation and that choosing between 
these for each individual sitauation is why we get paid.

Re: Instantiating Conveters in Backing Beans

[Craig McClanahan <cr...@gmail.com>]

On 8/29/05, Dennis_Byrne@ak.blm.gov <De...@ak.blm.gov> wrote:
>  
> Like most of you, there are plenty of places in my backend beans where I
> grab an identifying value from the request and use it to get an
> object/resultSet from the ORM/JDBC.  I prefer to put this code in a
> Converter but I just can't see how to do this when a user navigates from one
> view to another (user clicks on an item in a list of Customers, goes to a
> form for just that Customer). 
>  
> Usually Converters are "marketed" as a part of the "Apply Request Values"
> phase.  Perhaps there is something wrong w/ my eyes, but I don't see why
> they cannot be created in the backing bean as well.  After all, there are
> some use cases where validation and messaging are more convenient from the
> backing bean.   
>  
> Do any of you see any risks w/ this approach?  before I start doing it all
> over my project ;-) 
>  
> Dennis Byrne
>  

You can certainly use a converter that is bound to a backing bean property:

<h:inputText ... converter="#{backingBean.intConverter}"/>

where "intConverter" might be a property of type IntegerConverter. 
Sun Java Studio Creator does this kind of thing for you when you
explicity assign a Converter to a component.

That being said, I'm somewhat less comfortable with the idea of using
a converter for database retrieval operations, as you are
contemplating.  It's really designed for type conversions.  The other
thing to remember is that Converters are two way thngs ... it's used
in Apply Request Values (String->Object), but also in Render Response
(Object->String).

Craig