Trinidad: dialogs and pageFlow general usage

[simon <sk...@apache.org>]

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

Re: Trinidad: dialogs and pageFlow general usage

[Simon Lessard <si...@gmail.com>]

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 <si...@gmail.com> 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 <sk...@apache.org> 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
> >
> >
> >
> >
>

Re: Trinidad: dialogs and pageFlow general usage

[Simon Lessard <si...@gmail.com>]

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 <sk...@apache.org> 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
>
>
>
>