Hi Andrew,
I don't know Seam but probably I'll take a look to it. My main concern
about the solution 1) is that, using the ADF Faces Dialog Frameworks,
it seems to me that a different request is issued for the popup
window. I will need to explore custom navigations handler too.
Anyway, I think that probably the best solution for me would be a
tapestry-like model: I'd like a way to define my view declaring its
"input parameters", and use it like an object. I like tapestry, but
JSF has the great advantage of being supported by major vendors.
-Cosma
2006/5/30, Andrew Robinson <[EMAIL PROTECTED]>:
Well, the param is usually what you would use in these instances.
1) As for redirecting, you could use a custom navigation handler to
"Add back" your parameters onto a query string, or you could save your
parameters in a conversation (Seam) or session state for the next
call.
2) As for updateActionListener, you could make one HashMap property on
a bean, and set your parameters into that Map so that you only need
one backing bean property (a map). i.e. #{paramBean.params['x']}
Since I haven't used ADF yet (waiting for an official MyFaces
release), I can't comment on 3 or 4.
I usually use #1. My parameters are usually only used to assist the
action or action listeners though, I don't use them for the next page
(I use my backing bean's state to render pages - I have a lot of Seam
conversation state beans).
So to answer your main question, I use JBoss-Seam conversations for
passing values between views. I'm sure there are many other ways that
other people have done it.
-Andrew
On 5/30/06, Cosma Colanicchia <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I've been experimenting JSF for my company for some weeks by now. I'd
> like to discuss with you about the different ways the framework allows
> for passing parameters between views, which is a primary requirements
> for CRUD operations. I've tried many, each one with advantages and
> drawbacks:
>
> 1) Nesting an <f:param> inside the UICommand
> Problems: doesn't work with redirects, need to access an
> "ExternalContext" to retrieve the value
>
> 2) Nesting an <t:updateActionListener> (or a <af:setActionListener>)
> updating a backing bean property
> Problems: requires to create a property on a backing bean only for
> passing the parameter
>
> 3) Using the PageFlowScope of ADF Faces
> Problems: the target action has to be part of dialog (or to start one)
>
> 4) Getting the current row from a custom DataModel (or CollectionModel
> for ADF Faces)
> Problems: it can be used only when the source of the action is an
> UICommand inside a data table
>
> Am I missing something? What do you thing about those methods? Which
> one do you prefer? I know that each one is better for some situation,
> but I'd like to adopt a consistent scheme across my application, to
> simplify maintenance and to be able to recycle some view by defining a
> standard interface.
>
> I'd like very much to hear your opinion.
>
> Cosma
>
