f:param, updateActionListener, pageFlowScope, getCurrentRowData.. which design for CRUD with JSF?

[Cosma Colanicchia <co...@gmail.com>]

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

Re: f:param, updateActionListener, pageFlowScope, getCurrentRowData.. which design for CRUD with JSF?

[Cosma Colanicchia <co...@gmail.com>]

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 <an...@gmail.com>:
> 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 <co...@gmail.com> 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
> >
>

Re: f:param, updateActionListener, pageFlowScope, getCurrentRowData.. which design for CRUD with JSF?

[Andrew Robinson <an...@gmail.com>]

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 <co...@gmail.com> 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
>

Re: param, updateActionListener, pageFlowScope, getCurrentRowData.. which design for CRUD with JSF?

[Cosma Colanicchia <co...@gmail.com>]

Ok, I didn't know you was using hibernate :-)

2006/5/30, Frank Felix Debatin <ff...@gmx.net>:
> > I see that use setActionListener to refresh an entire bean
>
> > from your list one.
>
> Actually, the "item" that is passed is a proxy that carries
> an id and entity name that resolves to a hibernate
> persistent object in the current request's transaction ;-)
> Works perfectly fine.
>
> Frank Felix
>
>
>

RE: param, updateActionListener, pageFlowScope, getCurrentRowData.. which design for CRUD with JSF?

[Frank Felix Debatin <ff...@gmx.net>]

> I see that use setActionListener to refresh an entire bean

> from your list one.

Actually, the "item" that is passed is a proxy that carries
an id and entity name that resolves to a hibernate
persistent object in the current request's transaction ;-)
Works perfectly fine. 

Frank Felix

Re: param, updateActionListener, pageFlowScope, getCurrentRowData.. which design for CRUD with JSF?

[Cosma Colanicchia <co...@gmail.com>]

Hi Frank, thank for sharing your approach.

I see that use setActionListener to refresh an entire bean from your
list one. I immagine that you use directly this bean in your edit page
(if not, why pass all the bean instead of only the identifier
property?).

This is an interesting approach, but I see two problems. The first is
that your list has to be based on the very same javabean you use for
edit (no fields taken from other related tables or calculated fields
in the query). The second is the risk that the user works on
out-of-date data. For these reasons, I'm more orientend towards a
"pass the ID and load the detail" solution.

Anyway, +1 for setActionListener. Next? :-)




2006/5/30, Frank Felix Debatin <ff...@gmx.net>:
> We're using <af:setActionListener> consistently, doing
> things like:
>
> <af:table var="item">
>         ...
>         <af:column>
>                 <af:commandLink ...>
>                         <af:setActionListener from="#{item}"
>                                 to="#{EditItem.item}"/>
>                 </af:commandLink>
>         </af:column>
> </af:table>
>
> All in all nice.
>
> If I would need to start from scratch, I'd probably use a
> facelets custom EL function like this:
>
>         <af:commandLink action="my:invoke('page', item)"/>
>
> where my:invoke stores the parameter in some kind of hash
> map for later retrieval. Or the backing bean base class has
> an overridable invoke(Object obj) method, or similar.
>
> Regards
> Frank Felix
>
>
>
>
> > -----Original Message-----
> > From: Cosma Colanicchia [mailto:cosmacol@gmail.com]
> > Sent: Tuesday, May 30, 2006 3:16 PM
> > To: MyFaces Discussion
> > Subject: f:param, updateActionListener, pageFlowScope,
> > getCurrentRowData.. which design for CRUD with JSF?
> >
> > 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
> >
>
>

RE: param, updateActionListener, pageFlowScope, getCurrentRowData.. which design for CRUD with JSF?

[Frank Felix Debatin <ff...@gmx.net>]

We're using <af:setActionListener> consistently, doing
things like:

<af:table var="item">
	...
	<af:column>
		<af:commandLink ...>
			<af:setActionListener from="#{item}"
				to="#{EditItem.item}"/>
		</af:commandLink>
	</af:column>
</af:table>

All in all nice. 

If I would need to start from scratch, I'd probably use a
facelets custom EL function like this: 

	<af:commandLink action="my:invoke('page', item)"/>

where my:invoke stores the parameter in some kind of hash
map for later retrieval. Or the backing bean base class has
an overridable invoke(Object obj) method, or similar. 

Regards
Frank Felix
	

 

> -----Original Message-----
> From: Cosma Colanicchia [mailto:cosmacol@gmail.com] 
> Sent: Tuesday, May 30, 2006 3:16 PM
> To: MyFaces Discussion
> Subject: f:param, updateActionListener, pageFlowScope, 
> getCurrentRowData.. which design for CRUD with JSF?
> 
> 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
>