myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Arash Rajaeeyan" <arash.rajaee...@gmail.com>
Subject Re: spring conversation start (@manfred)
Date Tue, 19 Dec 2006 20:07:47 GMT
I also think it is much better

1) just let frameworks (Shale, Seam, ...) handle the conversation scope.

or

2) use ADF like Bean Managment in MyFaces

I mean using some thing like:
<*managed-bean-scope*>*process*</*managed-bean-scope*>
looks much more natural way to use another scope, for JSF developers than
defining some scopes in faces-config and some others using tags.

also since Trinidad is under MyFaces umbrella may be just generalize their
approach using best techniques in ADF, shale, seam.


On 12/19/06, Craig McClanahan <craigmcc@apache.org> wrote:
>
>
>
> On 12/19/06, Mario Ivankovits <mario@ops.co.at> wrote:
> >
> > Hi Craig!
> > > One of the architectural approaches that MyFaces developers seem to do
> > > pretty often, even when they don't have to, is think of everything as
> > > needing a component.
> > Hehe, yes indeed. But I'll try to move away from such approaches, the
> > Spring Conversation integration should no longer need them, even if
> > supported.
> >
> > > * Dialog instances can be started programmatically
> > Yes, thats easy.
> >
> > > or
> > >   by looking for a special prefix on the logical outcome
> > >   returned by an action.
> > Thats something we have to take a look at, though, we don't want to
> > build a full featured dialog framework.
> > Lets go small steps, maybe spring-webflow fits in there, but for sure
> > shale-dialog will have its place here too.
>
>
> If you haven't looked at Shale Dialog lately (last couple of months), it
> has been substantially enhanced -- it might suit your needs directly.  A
> couple of interesting tidbits:
>
> * Totally independent of view controller (although it works fine
>   in conjunction with view controller if you want)
>
> * Separated API and implementation -- currently two implementations
>   available (a "basic" one much like the original but with lots of
> bugfixes,
>   and one based on Jakarta Commons SCXML).  An implementation that
>   integrates directly with Spring's conversation stuff (but still used the
>   same APIs) would be interesting to take a look at.
>
>
> > * Instead of explicitly modifying the URL
> > </snip>
> >
> > > ... the dialog identifier
> > >   (and any other related stuff) is stored as a generic attribute
> > >   on the view root component.
> > Hey, this one is interesting, I'll give it a try.
> >
> > > The latter approach has an advantage in that you can pass any sort of
> > > state that is serializable (and therefore get <t:saveState> out of
> > > your pages too!  :-), and a disadvantage that it doesn't react well to
> > > the redirect-after-post pattern.  But it is worth taking a look at.
> > The advantage of the url-parameter method is to allow to easily render
> > links WITHOUT the conversationContext attribute and thus a new
> > conversation context will be started.
> > Maybe a mix of both strategies will be fine ...
>
>
> Indeed, I should have mentioned that Shale Dialog does support a mixed
> case, where you *can* start a conversation using a request parameter.  That
> turned out to be useful when you wanted a popup dialog to have its own
> context, independent of the one for the parent window or frame.  The docs[1]
> are reasonably up to date, plus there are some sample and test apps for both
> dialog implementations.
>
> Thanks alot!
> >
> > Ciao,
> > Mario
> >
> >
> Craig
>
>
> [1] http://shale.apache.org/shale-dialog/
>
>


-- 
Arash Rajaeeyan

Mime
View raw message