You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by Mario Ivankovits <ma...@ops.co.at> on 2006/12/19 11:34:53 UTC
spring conversation start (@manfred)
Hi!
Our plan was to implicit start a conversation as soon as a conversation
been will be created through spring.
Well, to know which conversationContext we are currently working in
(this context is required for "multiple window" awareness) we have to
add a request parameter to every rendered url.
This already works pretty well, BUT one has to ensure that the
s:startConversation tag is the very first on a page using conversations
to allow the system to configure itself appropriate so that the url
parameter will be appended.
At least, the s:startConversation has to be before e.g. the form stuff.
Now, with implicit started conversations this is not that easy any more.
I see two solutions:
1) still support the startConversation (in addition to the implicit
started one for sure). In fact I'll keep backward compatibility anyway,
so this will happen anyway.
2) standardize the backing-bean concept (aka ViewController)
Technically spoken: We have a PhaseListener which try to lookup a bean
using a name derived from the viewId (like shale's ViewController).
If this bean is in conversation scope (or one of its injected properties
if you have request scoped backing-beans - like me ;-) ) this would have
started a conversation then and the system is fine again.
What do you think, would someone see such a standardization as a bad thing?
IMHO having such a view controller concept would help much (not only for
conversations), e.g. we too can have those "prerender" methods etc we
often would like to have.
Ciao,
Mario
Re: spring conversation start (@manfred)
Posted by Martin Marinschek <ma...@gmail.com>.
Hi Craig,
Facelets supports a
setPropertyActionListener
as well - if Clay does, I can't say.
regards,
Martin
On 12/20/06, Craig McClanahan <cr...@apache.org> wrote:
>
>
> On 12/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
> > > Just out of curiousity, where did they add "it"? I don't see any
> reference
> > > to updateActionListener in 1.2.
> >
> > it is named setPropertyActionListener in the spec and in trinidad
> > setActinListener
>
> Thanks ... I had not recalled that from when I last did a detailed review of
> all the 1.2 changes. Hmm, between that and <f:valueChangeListener>, JSF has
> a pretty good analog to the "Beans Binding" JSR for Swing (JSR-296) :-), but
> only if you're using JSP :-(. I presume that the alternative view handlers
> like Clay and Facelets will deal with that issue on their own.
>
> > -M
>
> Craig
>
>
> > > By the way, is this similar to (or identical to) your idea for a
> preupdate()
> > > method in Shale's ViewController (SHALE-338)? If so, I still like the
> idea
> > > ... just need to see the follow through :-).
> > >
> > > Craig
> > >
> > > > Just my $0.02
> > > >
> > > > -M
> > > >
> > > > On 12/20/06, Werner Punz < werpu@gmx.at> wrote:
> > > > > Craig McClanahan schrieb:
> > > > > >
> > > > > > 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. To me, this involves the person building the
> > > view
> > > > > > in decisions that really belong to the person working on the
> business
> > > > > > logic. Yes, it's often the same person, but where is the
> separation
> > > of
> > > > > > concerns?
> > > > > >
> > > > > That was indeed the concerns of the original scope tag
> > > > > (I am using it currently btw. it is excellent work)
> > > > > the original intent was to have a viable replacement for savestate
> > > > > which would allow quick and dirty scoping with a
> > > > > a visual/tag approach.
> > > > >
> > > > > Mario did this approach and he solved it in an excellent way
> > > > > and yes, there is a break in separation of concerns and it was
> > > > > intended by design to ease the development of small applications,
> > > > >
> > > > > you basically push the scope control and parts of the transaction
> > > > > handling into the visual part.
> > > > >
> > > > > But the idea was to have a tag like way for those things, and if you
> > > > > need it differently (which many apps do but many small ones dont)
> > > > > have other frameworks deal with it.
> > > > >
> > > > > Now Mario, now he is moving into the Spring domain with his stuff,
> seems
> > > > > to be covering, let other frameworks do the scope control approach,
> > > > > as well.
> > > > >
> > > > > Btw. The scope tag of Mario is really excellent you should give it a
> > > > > try, but I agree, separation of concerns is not really there and
> cannot
> > > > > be by design principle, but there are other frameworks and solutions
> > > > > to deal with this.
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > > http://tinyurl.com/fmywh
> > > >
> > > > further stuff:
> > > > blog: http://jroller.com/page/mwessendorf
> > > > mail: mwessendorf-at-gmail-dot-com
> > > >
> > >
> > >
> >
> >
> > --
> > Matthias Wessendorf
> > http://tinyurl.com/fmywh
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
Re: spring conversation start (@manfred)
Posted by Craig McClanahan <cr...@apache.org>.
On 12/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
>
> > Just out of curiousity, where did they add "it"? I don't see any
> reference
> > to updateActionListener in 1.2.
>
> it is named setPropertyActionListener in the spec and in trinidad
> setActinListener
Thanks ... I had not recalled that from when I last did a detailed review of
all the 1.2 changes. Hmm, between that and <f:valueChangeListener>, JSF has
a pretty good analog to the "Beans Binding" JSR for Swing (JSR-296) :-), but
only if you're using JSP :-(. I presume that the alternative view handlers
like Clay and Facelets will deal with that issue on their own.
-M
Craig
> By the way, is this similar to (or identical to) your idea for a
> preupdate()
> > method in Shale's ViewController (SHALE-338)? If so, I still like the
> idea
> > ... just need to see the follow through :-).
> >
> > Craig
> >
> > > Just my $0.02
> > >
> > > -M
> > >
> > > On 12/20/06, Werner Punz < werpu@gmx.at> wrote:
> > > > Craig McClanahan schrieb:
> > > > >
> > > > > 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. To me, this involves the person building the
> > view
> > > > > in decisions that really belong to the person working on the
> business
> > > > > logic. Yes, it's often the same person, but where is the
> separation
> > of
> > > > > concerns?
> > > > >
> > > > That was indeed the concerns of the original scope tag
> > > > (I am using it currently btw. it is excellent work)
> > > > the original intent was to have a viable replacement for savestate
> > > > which would allow quick and dirty scoping with a
> > > > a visual/tag approach.
> > > >
> > > > Mario did this approach and he solved it in an excellent way
> > > > and yes, there is a break in separation of concerns and it was
> > > > intended by design to ease the development of small applications,
> > > >
> > > > you basically push the scope control and parts of the transaction
> > > > handling into the visual part.
> > > >
> > > > But the idea was to have a tag like way for those things, and if you
> > > > need it differently (which many apps do but many small ones dont)
> > > > have other frameworks deal with it.
> > > >
> > > > Now Mario, now he is moving into the Spring domain with his stuff,
> seems
> > > > to be covering, let other frameworks do the scope control approach,
> > > > as well.
> > > >
> > > > Btw. The scope tag of Mario is really excellent you should give it a
> > > > try, but I agree, separation of concerns is not really there and
> cannot
> > > > be by design principle, but there are other frameworks and solutions
> > > > to deal with this.
> > > >
> > > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > > http://tinyurl.com/fmywh
> > >
> > > further stuff:
> > > blog: http://jroller.com/page/mwessendorf
> > > mail: mwessendorf-at-gmail-dot-com
> > >
> >
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
Re: spring conversation start (@manfred)
Posted by Matthias Wessendorf <ma...@apache.org>.
> Just out of curiousity, where did they add "it"? I don't see any reference
> to updateActionListener in 1.2.
it is named setPropertyActionListener in the spec and in trinidad
setActinListener
-M
> By the way, is this similar to (or identical to) your idea for a preupdate()
> method in Shale's ViewController (SHALE-338)? If so, I still like the idea
> ... just need to see the follow through :-).
>
> Craig
>
> > Just my $0.02
> >
> > -M
> >
> > On 12/20/06, Werner Punz < werpu@gmx.at> wrote:
> > > Craig McClanahan schrieb:
> > > >
> > > > 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. To me, this involves the person building the
> view
> > > > in decisions that really belong to the person working on the business
> > > > logic. Yes, it's often the same person, but where is the separation
> of
> > > > concerns?
> > > >
> > > That was indeed the concerns of the original scope tag
> > > (I am using it currently btw. it is excellent work)
> > > the original intent was to have a viable replacement for savestate
> > > which would allow quick and dirty scoping with a
> > > a visual/tag approach.
> > >
> > > Mario did this approach and he solved it in an excellent way
> > > and yes, there is a break in separation of concerns and it was
> > > intended by design to ease the development of small applications,
> > >
> > > you basically push the scope control and parts of the transaction
> > > handling into the visual part.
> > >
> > > But the idea was to have a tag like way for those things, and if you
> > > need it differently (which many apps do but many small ones dont)
> > > have other frameworks deal with it.
> > >
> > > Now Mario, now he is moving into the Spring domain with his stuff, seems
> > > to be covering, let other frameworks do the scope control approach,
> > > as well.
> > >
> > > Btw. The scope tag of Mario is really excellent you should give it a
> > > try, but I agree, separation of concerns is not really there and cannot
> > > be by design principle, but there are other frameworks and solutions
> > > to deal with this.
> > >
> > >
> >
> >
> > --
> > Matthias Wessendorf
> > http://tinyurl.com/fmywh
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>
>
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: spring conversation start (@manfred)
Posted by Craig McClanahan <cr...@apache.org>.
On 12/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
>
> > By the way, is this similar to (or identical to) your idea for a
> preupdate()
> > method in Shale's ViewController (SHALE-338)? If so, I still like the
> idea
> > ... just need to see the follow through :-).
>
> :) I am on it, but got "blocked" by other *tasks*
Boy do I know *that* story :-). Looking forward to the results, whenever
they happen, although we're really close to rolling 1.0.4 now, so it might
have to wait for the next feature release.
Stay tuned
> -M
Craig
> Craig
> >
> > > Just my $0.02
> > >
> > > -M
> > >
> > > On 12/20/06, Werner Punz < werpu@gmx.at> wrote:
> > > > Craig McClanahan schrieb:
> > > > >
> > > > > 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. To me, this involves the person building the
> > view
> > > > > in decisions that really belong to the person working on the
> business
> > > > > logic. Yes, it's often the same person, but where is the
> separation
> > of
> > > > > concerns?
> > > > >
> > > > That was indeed the concerns of the original scope tag
> > > > (I am using it currently btw. it is excellent work)
> > > > the original intent was to have a viable replacement for savestate
> > > > which would allow quick and dirty scoping with a
> > > > a visual/tag approach.
> > > >
> > > > Mario did this approach and he solved it in an excellent way
> > > > and yes, there is a break in separation of concerns and it was
> > > > intended by design to ease the development of small applications,
> > > >
> > > > you basically push the scope control and parts of the transaction
> > > > handling into the visual part.
> > > >
> > > > But the idea was to have a tag like way for those things, and if you
> > > > need it differently (which many apps do but many small ones dont)
> > > > have other frameworks deal with it.
> > > >
> > > > Now Mario, now he is moving into the Spring domain with his stuff,
> seems
> > > > to be covering, let other frameworks do the scope control approach,
> > > > as well.
> > > >
> > > > Btw. The scope tag of Mario is really excellent you should give it a
> > > > try, but I agree, separation of concerns is not really there and
> cannot
> > > > be by design principle, but there are other frameworks and solutions
> > > > to deal with this.
> > > >
> > > >
> > >
> > >
> > > --
> > > Matthias Wessendorf
> > > http://tinyurl.com/fmywh
> > >
> > > further stuff:
> > > blog: http://jroller.com/page/mwessendorf
> > > mail: mwessendorf-at-gmail-dot-com
> > >
> >
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
Re: spring conversation start (@manfred)
Posted by Matthias Wessendorf <ma...@apache.org>.
> By the way, is this similar to (or identical to) your idea for a preupdate()
> method in Shale's ViewController (SHALE-338)? If so, I still like the idea
> ... just need to see the follow through :-).
:) I am on it, but got "blocked" by other *tasks*
Stay tuned
-M
> Craig
>
> > Just my $0.02
> >
> > -M
> >
> > On 12/20/06, Werner Punz < werpu@gmx.at> wrote:
> > > Craig McClanahan schrieb:
> > > >
> > > > 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. To me, this involves the person building the
> view
> > > > in decisions that really belong to the person working on the business
> > > > logic. Yes, it's often the same person, but where is the separation
> of
> > > > concerns?
> > > >
> > > That was indeed the concerns of the original scope tag
> > > (I am using it currently btw. it is excellent work)
> > > the original intent was to have a viable replacement for savestate
> > > which would allow quick and dirty scoping with a
> > > a visual/tag approach.
> > >
> > > Mario did this approach and he solved it in an excellent way
> > > and yes, there is a break in separation of concerns and it was
> > > intended by design to ease the development of small applications,
> > >
> > > you basically push the scope control and parts of the transaction
> > > handling into the visual part.
> > >
> > > But the idea was to have a tag like way for those things, and if you
> > > need it differently (which many apps do but many small ones dont)
> > > have other frameworks deal with it.
> > >
> > > Now Mario, now he is moving into the Spring domain with his stuff, seems
> > > to be covering, let other frameworks do the scope control approach,
> > > as well.
> > >
> > > Btw. The scope tag of Mario is really excellent you should give it a
> > > try, but I agree, separation of concerns is not really there and cannot
> > > be by design principle, but there are other frameworks and solutions
> > > to deal with this.
> > >
> > >
> >
> >
> > --
> > Matthias Wessendorf
> > http://tinyurl.com/fmywh
> >
> > further stuff:
> > blog: http://jroller.com/page/mwessendorf
> > mail: mwessendorf-at-gmail-dot-com
> >
>
>
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: spring conversation start (@manfred)
Posted by Craig McClanahan <cr...@apache.org>.
On 12/19/06, Matthias Wessendorf <ma...@apache.org> wrote:
>
> Well,
>
> sometimes somethings work well, even the "design" is not that best.
> Regard the separation, I think that is true for the
> "updateActionListener" as well.
> I love that guy, Trinidad has a similar and now the spec folks saw
> what's useful und added it
Just out of curiousity, where did they add "it"? I don't see any reference
to updateActionListener in 1.2.
By the way, is this similar to (or identical to) your idea for a preupdate()
method in Shale's ViewController (SHALE-338)? If so, I still like the idea
... just need to see the follow through :-).
Craig
Just my $0.02
>
> -M
>
> On 12/20/06, Werner Punz <we...@gmx.at> wrote:
> > Craig McClanahan schrieb:
> > >
> > > 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. To me, this involves the person building the
> view
> > > in decisions that really belong to the person working on the business
> > > logic. Yes, it's often the same person, but where is the separation
> of
> > > concerns?
> > >
> > That was indeed the concerns of the original scope tag
> > (I am using it currently btw. it is excellent work)
> > the original intent was to have a viable replacement for savestate
> > which would allow quick and dirty scoping with a
> > a visual/tag approach.
> >
> > Mario did this approach and he solved it in an excellent way
> > and yes, there is a break in separation of concerns and it was
> > intended by design to ease the development of small applications,
> >
> > you basically push the scope control and parts of the transaction
> > handling into the visual part.
> >
> > But the idea was to have a tag like way for those things, and if you
> > need it differently (which many apps do but many small ones dont)
> > have other frameworks deal with it.
> >
> > Now Mario, now he is moving into the Spring domain with his stuff, seems
> > to be covering, let other frameworks do the scope control approach,
> > as well.
> >
> > Btw. The scope tag of Mario is really excellent you should give it a
> > try, but I agree, separation of concerns is not really there and cannot
> > be by design principle, but there are other frameworks and solutions
> > to deal with this.
> >
> >
>
>
> --
> Matthias Wessendorf
> http://tinyurl.com/fmywh
>
> further stuff:
> blog: http://jroller.com/page/mwessendorf
> mail: mwessendorf-at-gmail-dot-com
>
Re: spring conversation start (@manfred)
Posted by Matthias Wessendorf <ma...@apache.org>.
Well,
sometimes somethings work well, even the "design" is not that best.
Regard the separation, I think that is true for the
"updateActionListener" as well.
I love that guy, Trinidad has a similar and now the spec folks saw
what's useful und added it
Just my $0.02
-M
On 12/20/06, Werner Punz <we...@gmx.at> wrote:
> Craig McClanahan schrieb:
> >
> > 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. To me, this involves the person building the view
> > in decisions that really belong to the person working on the business
> > logic. Yes, it's often the same person, but where is the separation of
> > concerns?
> >
> That was indeed the concerns of the original scope tag
> (I am using it currently btw. it is excellent work)
> the original intent was to have a viable replacement for savestate
> which would allow quick and dirty scoping with a
> a visual/tag approach.
>
> Mario did this approach and he solved it in an excellent way
> and yes, there is a break in separation of concerns and it was
> intended by design to ease the development of small applications,
>
> you basically push the scope control and parts of the transaction
> handling into the visual part.
>
> But the idea was to have a tag like way for those things, and if you
> need it differently (which many apps do but many small ones dont)
> have other frameworks deal with it.
>
> Now Mario, now he is moving into the Spring domain with his stuff, seems
> to be covering, let other frameworks do the scope control approach,
> as well.
>
> Btw. The scope tag of Mario is really excellent you should give it a
> try, but I agree, separation of concerns is not really there and cannot
> be by design principle, but there are other frameworks and solutions
> to deal with this.
>
>
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: spring conversation start (@manfred)
Posted by Werner Punz <we...@gmx.at>.
Craig McClanahan schrieb:
>
> 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. To me, this involves the person building the view
> in decisions that really belong to the person working on the business
> logic. Yes, it's often the same person, but where is the separation of
> concerns?
>
That was indeed the concerns of the original scope tag
(I am using it currently btw. it is excellent work)
the original intent was to have a viable replacement for savestate
which would allow quick and dirty scoping with a
a visual/tag approach.
Mario did this approach and he solved it in an excellent way
and yes, there is a break in separation of concerns and it was
intended by design to ease the development of small applications,
you basically push the scope control and parts of the transaction
handling into the visual part.
But the idea was to have a tag like way for those things, and if you
need it differently (which many apps do but many small ones dont)
have other frameworks deal with it.
Now Mario, now he is moving into the Spring domain with his stuff, seems
to be covering, let other frameworks do the scope control approach,
as well.
Btw. The scope tag of Mario is really excellent you should give it a
try, but I agree, separation of concerns is not really there and cannot
be by design principle, but there are other frameworks and solutions
to deal with this.
Re: spring conversation start (@manfred)
Posted by Arash Rajaeeyan <ar...@gmail.com>.
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 <cr...@apache.org> wrote:
>
>
>
> On 12/19/06, Mario Ivankovits <ma...@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
Re: spring conversation start (@manfred)
Posted by Craig McClanahan <cr...@apache.org>.
On 12/19/06, Mario Ivankovits <ma...@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/
Re: spring conversation start (@manfred)
Posted by Mario Ivankovits <ma...@ops.co.at>.
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.
> * 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 ...
Thanks alot!
Ciao,
Mario
Re: spring conversation start (@manfred)
Posted by Craig McClanahan <cr...@apache.org>.
On 12/19/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi!
>
>
> Our plan was to implicit start a conversation as soon as a conversation
> been will be created through spring.
>
> Well, to know which conversationContext we are currently working in
> (this context is required for "multiple window" awareness) we have to
> add a request parameter to every rendered url.
> This already works pretty well, BUT one has to ensure that the
> s:startConversation tag is the very first on a page using conversations
> to allow the system to configure itself appropriate so that the url
> parameter will be appended.
> At least, the s:startConversation has to be before e.g. the form stuff.
>
> Now, with implicit started conversations this is not that easy any more.
>
> I see two solutions:
> 1) still support the startConversation (in addition to the implicit
> started one for sure). In fact I'll keep backward compatibility anyway,
> so this will happen anyway.
> 2) standardize the backing-bean concept (aka ViewController)
> Technically spoken: We have a PhaseListener which try to lookup a bean
> using a name derived from the viewId (like shale's ViewController).
> If this bean is in conversation scope (or one of its injected properties
> if you have request scoped backing-beans - like me ;-) ) this would have
> started a conversation then and the system is fine again.
>
> What do you think, would someone see such a standardization as a bad
> thing?
> IMHO having such a view controller concept would help much (not only for
> conversations), e.g. we too can have those "prerender" methods etc we
> often would like to have.
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. To me, this involves the person building the view in
decisions that really belong to the person working on the business logic.
Yes, it's often the same person, but where is the separation of concerns?
Given that statement to show my biases :-), there are two aspects of the way
that Shale's dialog manager deals with these issues that you might want to
take a look at:
* Dialog instances can be started programmatically, or
by looking for a special prefix on the logical outcome
returned by an action. Nothing at all needs to be placed
in the page itself for this to work ... and a particular page
can be reused inside or outside a dialog.
* Instead of explicitly modifying the URL (as described above),
or adding a custom HTTP header (as Seam used to do ... don't
know what 1.1 does at the moment), the dialog identifier
(and any other related stuff) is stored as a generic attribute
on the view root component. Typically this will be stored (for
a Shale app) in the prerender() method ... the corresponding
generic way would be a "before render response" event handler
in a phase listener.
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.
Ciao,
> Mario
Craig
Re: spring conversation start (@manfred)
Posted by Mario Ivankovits <ma...@ops.co.at>.
Hi!
> as you may know seam also has its own phase listener and bean
> managment facility.
Having a phase listener does not necessarily mean we break the JSF
lifecycle or something else.
> can seam users also continue using myfaces?
definitely: Yes!
MyFaces JSF "Impl" will always try to be the base for any JSF conforming
app, also like MyFaces Tomahawk will always try to work with any JSF impl.
The ConversationTag at all and the Spring integration in particular is a
MyFaces sandbox component/technology and we will see where it will end,
but even in MyFaces-sandbox it is an optional behavior. If there is any
influence with seam we are happy to know and fix it.
> (seam has its own conversation mechanism,
> http://docs.jboss.com/seam/1.1GA/reference/en/html/conversations.html)
Yes, and using Spring Conversation is just another possibility. The
question is: Is seam already is the only truth?
> will nested conversations also be allowed?
We support "parallel" (instead of "nested") conversations.
We will see whats easier to handle.
IMHO: Having a declarative ONLY pageflow configuration allows nested
conversations. If you have a loosely coupled page conversation you'll
most likely have parallel conversations - maybe with an more aggressive
timeout.
If you treat a parallel conversation as nested or not is up to the
programmer (as long as you do not have an external dialog/conversation
configuration)
Ciao,
Mario
Re: spring conversation start (@manfred)
Posted by Matthias Wessendorf <ma...@apache.org>.
> then what will happen to users who use Seam or future WebBean with MyFaces?
> as you may know seam also has its own phase listener and bean managment
> facility.
webbeans is not ready for now.
regarding seam, I think that this feature is not mandatory, sorta
optional extension.
perhaps jsf itself should provide better "access" to the mb facility
-M
> can seam users also continue using myfaces?
> (seam has its own conversation mechanism,
> http://docs.jboss.com/seam/1.1GA/reference/en/html/conversations.html)
>
> will nested conversations also be allowed?
>
>
> On 12/19/06, Mario Ivankovits <ma...@ops.co.at> wrote:
> > Hi!
> >
> >
> > Our plan was to implicit start a conversation as soon as a conversation
> > been will be created through spring.
> >
> > Well, to know which conversationContext we are currently working in
> > (this context is required for "multiple window" awareness) we have to
> > add a request parameter to every rendered url.
> > This already works pretty well, BUT one has to ensure that the
> > s:startConversation tag is the very first on a page using conversations
> > to allow the system to configure itself appropriate so that the url
> > parameter will be appended.
> > At least, the s:startConversation has to be before e.g. the form stuff.
> >
> > Now, with implicit started conversations this is not that easy any more.
> >
> > I see two solutions:
> > 1) still support the startConversation (in addition to the implicit
> > started one for sure). In fact I'll keep backward compatibility anyway,
> > so this will happen anyway.
> > 2) standardize the backing-bean concept (aka ViewController)
> > Technically spoken: We have a PhaseListener which try to lookup a bean
> > using a name derived from the viewId (like shale's ViewController).
> > If this bean is in conversation scope (or one of its injected properties
> > if you have request scoped backing-beans - like me ;-) ) this would have
> > started a conversation then and the system is fine again.
> >
> > What do you think, would someone see such a standardization as a bad
> thing?
> > IMHO having such a view controller concept would help much (not only for
> > conversations), e.g. we too can have those "prerender" methods etc we
> > often would like to have.
> >
> >
> > Ciao,
> > Mario
> >
> >
>
>
>
> --
> Arash Rajaeeyan
--
Matthias Wessendorf
http://tinyurl.com/fmywh
further stuff:
blog: http://jroller.com/page/mwessendorf
mail: mwessendorf-at-gmail-dot-com
Re: spring conversation start (@manfred)
Posted by Arash Rajaeeyan <ar...@gmail.com>.
>2) standardize the backing-bean concept (aka ViewController)
>Technically spoken: We have a PhaseListener which try to lookup a bean
>using a name derived from the viewId (like shale's ViewController).
then what will happen to users who use Seam or future WebBean with MyFaces?
as you may know seam also has its own phase listener and bean managment
facility.
can seam users also continue using myfaces?
(seam has its own conversation mechanism,
http://docs.jboss.com/seam/1.1GA/reference/en/html/conversations.html)
will nested conversations also be allowed?
On 12/19/06, Mario Ivankovits <ma...@ops.co.at> wrote:
>
> Hi!
>
>
> Our plan was to implicit start a conversation as soon as a conversation
> been will be created through spring.
>
> Well, to know which conversationContext we are currently working in
> (this context is required for "multiple window" awareness) we have to
> add a request parameter to every rendered url.
> This already works pretty well, BUT one has to ensure that the
> s:startConversation tag is the very first on a page using conversations
> to allow the system to configure itself appropriate so that the url
> parameter will be appended.
> At least, the s:startConversation has to be before e.g. the form stuff.
>
> Now, with implicit started conversations this is not that easy any more.
>
> I see two solutions:
> 1) still support the startConversation (in addition to the implicit
> started one for sure). In fact I'll keep backward compatibility anyway,
> so this will happen anyway.
> 2) standardize the backing-bean concept (aka ViewController)
> Technically spoken: We have a PhaseListener which try to lookup a bean
> using a name derived from the viewId (like shale's ViewController).
> If this bean is in conversation scope (or one of its injected properties
> if you have request scoped backing-beans - like me ;-) ) this would have
> started a conversation then and the system is fine again.
>
> What do you think, would someone see such a standardization as a bad
> thing?
> IMHO having such a view controller concept would help much (not only for
> conversations), e.g. we too can have those "prerender" methods etc we
> often would like to have.
>
>
> Ciao,
> Mario
>
>
--
Arash Rajaeeyan