Hello,
(1) we often mix access to beans in different conversations (ie with
different lifetimes) on the same page. One common example is a page
displaying a persistent bean, a search-criteria and a results list.
AIUI your suggestion introduces a "default" conversation for the
request, but these different things might be in the "default"
conversation in some views, and not in others.
I've already mentioned a few times that such use-cases can't be
implemented with a single conversation model and that's the reason why
we can't drop the current approach entirely, but I do think that some of
those use-cases can be implemented with nested conversations too.
For example, determining search criteria is something that you could
either do on the same page or in a different dialog. If you provide
according JSF input components on the same page, you can use the request
scope and if you're providing a special dialog that enables the user to
specify the search criteria, you can use a nested conversation.
Of course, now you're gonna tell me some usecases where neither the
"request scope"-approach nor the "nested-conversation"-approach will
work, but that doesn't matter as I've already "admitted" that there are
such use-cases, but those are not usual ones (or at least not ones that
you can't solve differently).
Orchestra has been developed so that it's possible to use multiple
conversations on the same view, simply because you need multiple
conversations on the same view. I do not and most importantly neither do
others too, because otherwise noone would be using Web Flow or Seam.
However, don't get me wrong as it's a great thing that Orchestra
supports usecases that other frameworks don't support, but these
usecases shouldn't be the reason for limiting the user's possibilites.
(2) As mario mentioned, ensuring endConversation is called
appropiately is basically impossible. WebFlow might be able to arrange
it because it insists that the webapp documents every valid navigation
transition and so can detect navigations that are not in its list. But
orchestra doesn't want to go down that road. I don't mean that the
WebFlow approach is wrong, just that Orchestra currently has a
low-configuration JSF-ish approach and that has its benefits too.
Why is ensuring an according "endConversation" method is called
impossible? If you don't call "conversation.invalidate()" by now the
EntityManager won't be closed (I'm ignoring the timeout for now) and I
don't think that this is a problem either? I really don't see any
difference here.
Of course, a low-configuration approach has got its benefits too,
otherwise I wouldn't have started this discussion as I'd be using Spring
Web Flow all the time. However, I think that this doesn't introduce
further configuration overhead.
(3) If something calls startConversation, then how does it get
access to the stuff that was in the previous "default conversation"?
Well, first of all I want to clarify that there's nothing like a
"default conversation". There's just the current conversation which
might be "null" if the user hasn't called startConversation yet (or
whatever approach you'd like to implement for starting conversations).
You can access the calling conversation with a method like
"conversation.getParentConversation()" or something like that, but I
think that's not what you want to know, is it? Most probably you're
looking for something that allows you to inject a bean of a certain
conversation into one of another conversation, aren't you?
Actually, it's even possible to do that, but you have to allow it, i.e.
you have to pass those beans as parameters. However, no additional API
is needed for that as you only have to register them as attributes
(However, special care has to be taken regarding lifecycle callbacks of
such "parameter attributes", but that's an implementation detail again ..).
Furthermore I'd like to keep the current conversation model, so you're
still able to configure which conversation to use for a certain bean,
the difference is just that I'd like to build it on top of a single
conversation model.
regards,
Bernhard Huemer
On 10/27/2008 +0100,
Simon Kitching <[EMAIL PROTECTED]> wrote:
Mario Ivankovits schrieb:
Simply said, yes that's true, but the flow description doesn't have to
be an XML flow definition. What I'd like to see, is an Orchestra API
that allows me to describe my flows programmatically at runtime as this
is a much more powerful approach for managing conversations.
You can create your own flow implementation on top of orchestra and use a special
conversation scope implementation which uses the conversation name "_main" as a
fixed string. Then, the only thing you have to deal with is the conversationContext.
If your custom scope avoids creating the conversation if it doesn't exist you
even can try to implement the @Create stuff.
I think in Orchestra everything is there to help you developing your ideas
without rewriting the core of Orchestra.
I would second Mario's suggestion.
AIUI, your suggestion effectively introduces a "default" conversation,
and beans can be declared as being in the "default" conversation. The
default conversation for a specific conversationContext gets changed via
API calls. And something sets up the persistence-context for the default
conversation as soon as the request starts rather than waiting for a
method-call to a specific bean. That sounds like something that could be
implemented now, without changing Orchestra much or at all, just by
having a conversation with a magic name like "_main".
If something is missing in the Orchestra API to allow this then we can
talk about adding it in to make your approach possible. But Orchestra
does work right now, for some real-world projects. So it would seem
reasonable to test the new idea rather than ripping everything up first
if we can.
Having a conversation (and associated persistence context) set up as
soon as the request starts (rather than only setting it up while a
method on a conversation-scoped bean is running) would be nice. But
there are a lot of potential issues with this too, like:
(1) we often mix access to beans in different conversations (ie with
different lifetimes) on the same page. One common example is a page
displaying a persistent bean, a search-criteria and a results list. AIUI
your suggestion introduces a "default" conversation for the request, but
these different things might be in the "default" conversation in some
views, and not in others.
(2) As mario mentioned, ensuring endConversation is called appropiately
is basically impossible. WebFlow might be able to arrange it because it
insists that the webapp documents every valid navigation transition and
so can detect navigations that are not in its list. But orchestra
doesn't want to go down that road. I don't mean that the WebFlow
approach is wrong, just that Orchestra currently has a low-configuration
JSF-ish approach and that has its benefits too.
(3) If something calls startConversation, then how does it get access to
the stuff that was in the previous "default conversation"?
Regards,
Simon
