myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mario Ivankovits <ma...@ops.co.at>
Subject RE: [Orchestra] Drawbacks of Orchestra I'd like to discuss
Date Mon, 27 Oct 2008 12:33:24 GMT
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