> 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="" 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.
