Hello,
The main problem I see with this approach is that you HAVE to use a
flow definition, else Orchestra has no chance to determine when to end
a conversation and when to reuse the current one.
Well, no, you don't have to use a flow definition. Managing the
conversation from a user's perspective is clearly defined as an
according API will be provided. If the user doesn't call a method like
"conversation.invalidate()" the conversation won't end.
For example, I'm thinking of creating a configurable artifact that
manages the lifecycle of a conversation - a so-called
"ConversationManager". The basic implementation would require the user
to call the method "manager.startConversation()", i.e. the user would
have to configure the beans so that a ConversationManager will be
injected. However, another ConversationManager could possibly know how
to deal with annotations like @Create or @End. It would be even possible
to configure a special ConversationManager that automatically creates a
new conversation if you try to access it (i.e. just as it is now) and of
course there's the possibility of using a flow definition for that purpose.
In a web-application, where you have global menues where the user is
able to "suspend" the current conversation and jump right to the start
of another one (or resume it) it is hard to find the conversation
demarcation without a flow description. In fact I tried such thing in
Orchestra BEFORE I started to go the named-conversation way. Orchestra
just fits way better with this "free-floating-named-conversations" in
our application.
Well, I'm not particularly against named conversations. I'm just saying
that neither the view nor a Spring bean is responsible for determining
the name of this conversation, but a special "flow logic" is (and I'm
still not talking about flow definitions).
For example, in this case I'd prefer to write a NavigationHandler for my
application that knows how to deal with this usecase. Basically it uses
the according API to suspend the current conversation and resume the
according one. Of course, Orchestra could only do that automatically if
there was something like a flow definition, but I'd prefer to expose an
API so that the user is able to write such a NavigationHandler on his own.
However, this approach enables you to control conversations in a more
fine-grained way. For example, if you've got a master-/detail-view being
surrounded by global navigation menus, you could use the exposed API so
that you'll resume the conversation for the detail you've choosen
previously if you select it again (of course, assuming that you only
have suspended the conversation, i.e. you've clicked on a global menu
entry before).
Also no user-interaction is required (pause, restart, etc) and no
other sort of convention.
Well, of course you could say that this is a burden for the user, but it
comes with great flexibility too (see my master-/detail-view example).
Convenient default implementations could then reduce the complexity
without limitating the user's flexibility.
For me the single-conversation approach looks like a limitation,
which to break out requires a flow-description.
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.
regards,
Bernhard
On 10/27/2008 +0100,
Mario Ivankovits <[EMAIL PROTECTED]> wrote:
Hi!
Well, basically I'd refactor the ConversationContext so that it's
actually the main conversation of Orchestra. The conversation itself is
almost independent of Spring (of course, there's still an according
implementation of the Scope interface, but it will be implemented way
easier). It's possible to nest conversations, i.e. a there's a certain
hierarchy of conversations.
The main problem I see with this approach is that you HAVE to use a flow
definition, else Orchestra has no chance to determine when to end a
conversation and when to reuse the current one.
In a web-application, where you have global menues where the user is able to "suspend"
the current conversation and jump right to the start of another one (or resume it) it is hard to
find the conversation demarcation without a flow description. In fact I tried such thing in
Orchestra BEFORE I started to go the named-conversation way. Orchestra just fits way better with
this "free-floating-named-conversations" in our application.
As far as I know Spring WebFlow is such a system and is able to deal with
persistence contexts already.
Each conversation has got it's own lifecycle and therefore it's
possible
to register so-called "conversation listeners" in order to hook logic
into such lifecycle phases.
Some of the events you outlined are already there in Orchestra. Also using
Orchestra without persistence at all works great, on a per-scope-configuration
basis!
Still, the beauty of Orchestra is that it supports use-cases like:
1) Doing Order-Processing
2) Suspend task 1 and do some different things like, update customers
master-data
3) Go back to Order-Processing and continue
All this works without a single line of flow-description and by nicely separate
the persistence contexts, so the memory of task 2 has been freed while task 1
is stil there.
Also no user-interaction is required (pause, restart, etc) and no other sort of
convention.
On top of THAT we built the flow, so each flow separates even more by still
keeping the easy-to-use multiple conversation feature. Where a flow is required
(e.g. search-pages) you can use them now.
So, it is not only using two conversations during the same render-request, no,
it is about using different parallel conversations for different tasks without
additional configuration on view level.
In fact, if one finds a method how Orchestra can determin what is the CURRENT
conversation we could get rid of the viewController-scope, but since Orchestra
talks about beans and not about views in its innerst, that is hard to find.
For me the single-conversation approach looks like a limitation, which to break
out requires a flow-description.
Sorry, at all it is hard for me to see what is better to do it like Spring
WebFlow.
Ciao,
Mario
