Another side note while thinking about it, WebBeans early draft has been
released and contains a conversation scope:
http://jcp.org/en/jsr/detail?id=299
Regards,
~ Simon
On 11/7/07, Simon Lessard <[EMAIL PROTECTED]> wrote:
>
> Hi Simon,
>
> pageFlowScope includes back button and multiple tabs/windows support as
> well. The main disadvantages with it is that it make shallow copies between
> request, meaning you have to put the raw data directly in it, else the
> backup to previous version won't work correctly upon back button usage. I
> also dislike the EL using pageFlowScope. In project, we use a home made
> extension that fix both of those issues but has some drawbacks:
>
> 1. Create an annotation @PageFlowBean to mark the classes to be used
> as page flow beans;
> 2. Create a PageFlowBeanHandler with three methods: clear, get,
> persist and register;
> 3. Create a PageFlowBeanELResolver calling handler.get, if null
> delegating to the default resolver chain, if the found bean is marked
> @PageFlowBean, call handler.register, this remove the need of
> #{pageFlowScope.}, note that the scope still has to be cleared manually;
> 4. Create a Decorator ApplicationFactory that set the base
> ELResolver as PageFlowBeanELResolver with a delegate to default ELResolver
> chain (why did it have to be so complicated to decorate resolver in JSF
> 1.2?);
> 5. Create a LifecycleFactory decorator to return a Lifecycle calling
> handler.persist at the end of its render method. The persist method
> save the serialized state of the pageFlow beans in the Trinidad
> pageFlowScope to be correctly restored during the subsequent requests.
>
> The main drawback we're having with it is a performance overhaul linked to
> serialization as well as not enforcing the declared scope if the class is
> marked @PageFlowBean so the good practice is to define them as "none" or
> "request". We also had to add an attribute to the annotation to allow a bean
> name list filter so that you can have two beans of the same class, one in
> page flow scope and the other in any declared scope. Anyway, this was just
> to show you that it'S achievable using Trinidad as well.
>
>
> Regards,
>
> ~ Simon
>
> On 11/7/07, simon <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> > I've been reading up on Trinidad Dialogs (including "pageFlow" feature),
> > and comparing them with Orchestra conversations.
> >
> > It seems to me that there is some overlap in features here. I'd
> > appreciate your help in getting a fair comparison together.
> >
> > I'm mostly looking at these three pages:
> >
> > http://myfaces.apache.org/trinidad/devguide/communicatingBetweenPages.html
> >
> > http://myfaces.apache.org/trinidad/devguide/dialogs.html
> >
> >
> > http://myfaces.apache.org/orchestra/myfaces-orchestra-core/conversation.html
> >
> > The orchestra docs give the following reasons for using conversations
> > instead of session-scope:
> > (1) at end of a flow, discard related beans to save memory
> > (2) at restart of flow, start with clean beans, not leftovers from
> > previous run
> > (3) support multiple concurrent windows there is also an undocumented
> > (because somewhat debatable) additional one:
> > (4) support "back" button by keeping snapshots of user data (either
> > client or server side).
> >
> > Trinidad pageFlow provides some kind of support for (1) and (2). However
> > views that are expected to be used in dialogs must use EL expressions
> > that reference pageFlow.*, ie must be written for it. The backing beans
> > for such screens are "normal" beans, and therefore are created directly
> > in their declared scope (request/session). Any non-request-scoped bean
> > will not be cleaned up on dialog end; only pageFlow is.
> >
> > So it seems to me that the correct way to use Trinidad dialogs is:
> > * always use request-scoped backing beans only
> > * EL expressions can read data from the pageFlow map, eg display
> > outputText. However they need to explicitly write "#{ pageFlow.foo}" to
> > get the data.
> > * EL expressions don't write to the pageFlow map; any input components
> > map to properties on the request-scoped bean. Of course those values get
> > lost after
> > render, but on postback the input components send that data back.
> > * If the backing bean wants to store any "computed" data, it must put()
> > it into the pageFlow map, and later read it back out again (with a
> > typecast). This map is probably best injected into it; the bean just
> > needs to know that this object can be used to externalise its state (if
> > any) into.
> >
> > Is this correct?
> >
> > In my experience, it's pretty hard to write a JSF app wth backing beans
> > that are only in request scope; I find myself using Session scope a lot
> > despite its drawbacks. Request-scoped beans are just too hard to use in
> > some circumstances.
> >
> > It seems to me therefore that Trinidad pageFlow (and the Dialog support
> > that is built on top of it) are really focused on page sequences a
> > couple of pages in length, where the pages don't do any clever or
> > complicated logic. Is this the general goal?
> >
> > And that converting an application that currently uses session-scoped
> > beans to using Trinidad dialogs extensively would be significant work?
> >
> > I guess one of the objects in the pageFlow could be effectively "the
> > real stateful backing bean", combining both logic and state into one
> > instance. However it would have to be explicitly put there by something
> > rather than allowing the VariableResolver to just create it in its
> > natural scope when an EL expression accessed it. And all accesses to it
> > would be clumsy as they either would have to be delegated via the
> > request-scoped bean, or the EL expression would need to use "pageFlow.*"
> >
> > again. So I presume this is not really a recommended approach?
> >
> > Re (3), the "page flow key" is kept as a URL param, so I guess that as
> > long as all the backing beans are request-scoped this would allow a user
> >
> > to have multiple windows open on the same or different dialogs. But it
> > will not work for any backing bean that is stateful itself.
> >
> > Re(4): snapshots of the pageFlow map can easily be made. This is
> > sufficient, however, only if the application uses only request-scoped
> > beans (no session-scoped beans at all).
> >
> > Note that I'm not trying to criticise pageFlow or Trinidad dialogs here,
> > just get an understanding of how they are expected to be used, and what
> > the pros/cons are.
> >
> > Regards,
> >
> > Simon
> >
> >
> >
> >
>
