myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bernhard Huemer <bernhard.hue...@gmail.com>
Subject Re: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Date Mon, 27 Oct 2008 13:36:59 GMT
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 <mario@ops.co.at> 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


Mime
View raw message