Hi!
The problem is, that it is hard to ensure having a stopConversation
for each startConversation, and what about reloading the page where
possibly the startConversation gets called twice.
Well, if I'm not completely mistaken, you also have to invalidate all
Orchestra conversations manually by now.
Well, for conversation.access this is no problem, they die with any request not
accessing any bean in the conversation.
For manual-scoped conversations, this is true.
However due to the "map" based approach, the impact of not having a converation
closed is much less, and if the user navigates back it can resume the work automagically.
Manual conversations also have a timeout; when not used for a while they are
garbage-collected. Will this work as well in your approach? The "not used"
thing won't work so well, yes?
I don't see the point, why forcing the user to stop
the conversation manually is a problem.
Normally the user wont play nicely - and a web application should not force the
user to do so. But, to say the truth, we often use the conversation.access for
the persistence stuff and conversation.manual for storing non-persistence state
of the conversation which allows to restart easily.
This gives the user a great application experience I think.
Reloading the page, however, doesn't matter. Well, of course, it
creates
another conversation but sooner a later a timeout will invalidate the
one that has been created first.
But then you can not talk about "nested conversations", then you too have the same
"flat" structure as Orchestra has by today.
When you talk about "nested conversation" you normally also mean to invalidate
all child conversations once the parent timeout. This clearly can not work for your
scenario.
So you too have to distinguish between "nested conversations" and start a new
"conversation".
Currently "nested conversations" are supported through Orchestra Flow ... which
also requires some sort of configuration/convention for the flow demarcation.
Another problem ist that not each and every page-flow is triggered
by a navigation-handler event, what about get requests - e.g. from
the main menu.
The NavigationHandler was just supposed to be an example. However,
somewhere, of course, you have to implement that logic, i.e. some
callback method is needed in order to handle the "conversation
selection", for example, you could use a ViewController for GET
Requests.
But then again you do not know if you'd like to start or end a conversation
without specific external configuration. You can not state this as
implementation detail. Starting and ending a conversation in a reasonable and
controlled way is what it is all about. Orchestra just allowes to handle it in
a less hot way.
Of course, it's best practice not to pass any entities between
Orchestra
conversations, but that's just true because each Orchestra conversation
has got its own persistence context. Seperating conversations and
persistence contexts allows you to use the conversation scope in a more
fine-grained way (for example, I'd like to reset filter criteria of a
search conversation without closing the persistence context).
How many levels do you want the developer to keep in mind? If you separate the
conversation from the persistence scope you also have to be aware that, once
the persistence context dies all
the conversation cached in a conversation bean is detached. Creating a new
persistence scope and pulling in conversation beans with entites loaded using
another persistence scope will not work.
The only workaround is to NOT cache any entity in the conversation bean and
look it up from the persistence context each and every time. Which is doable,
for clustering probably needed, but hard to code.
And yes, the "reset filter criteria" is just what is easily possible (and used)
with orchestra. Simply invalidate the conversation which holds the criteria.
BTW: This conversation lives in a scope which does not use any persistence
context at all here. This is just a matter of scope configuration.
You could count it as "example 3" of things I don't like in Orchestra. I
have to use a single persistence context for a certain dialog (I'm
calling it dialog now so that you don't mix it up with Orchestra
conversations). Now I'd like to split this dialog into seperate
conversations, but I can't because I have to reuse the persistence
context so I'm actually reseting some values manually. :-f
This is just not true, you can use as many persistence contexts as you would
like to. You just have to be aware how to pass information from one
conversation to another one.
That you should not pass entities between persistence contexts is a limitation
of the persistence framework - and nothing which is a real problem in any
application, is it?
I don't know what you mean by "split this dialog" as no persistence framework allows you
to "split" its session, but if you'd like to
push the data to other conversation scoped beans you are free to do so -
technically spoken.
However, actually I wanted to talk about my search-use-case as I think
that's no problem. Even with a single conversation model it's still
possible to create nested conversations (which would meet all
requirements for this use-case).
If the user uses some sort of global navigation you do not know which
conversation to end. This is NOT trivial to solve without flow configurations.
Nested-Conversations without external flow configuration won't work, I promise.
Probably there are even further more examples where a NavigationHandler
won't work, but that actually really doesn't matter, because using an
API the user has got the possibility to adapt Orchestra to his/her
needs. (Btw. implementing another scope that fulfills ones requirements
is somehow "extending Orchestra" and not really "using Orchestra" ..).
But to test out your ideas you first have to extend Orchestra, as it clearly
does not fit your needs, and then we can decide making it the new best practice.
Orchestra has a sandbox, no problem to start there.
I think you've answered that already on your own. If "hacking around"
is
needed for something "trivial" like that, something has to be done, at
least in my opinion.
Sorry that "hacking around" triggered somehting like that. With "hacking
around" I just meant developing your idea.
Orchestra is using another philosophy you have in mind. There is not much to
say about that.
Implementing and using your "trivial" (your word ;-) ) idea is anything else
than trivial I think.
Well, basically you've told me to implement my own conversation scope
and my own approach to persistence context handling, if I really feel
the need for something like that. But what remains of "the core of
Orchestra"? - the ConversationContext.
Yes, and if it is really that good we can use that as new system ground for
Orchestra, what is bad with that?
You also do not have to go the "proxied" bean way. You simply can use a filter
to setup the persistence. That is really easy. Just lookup the conversation and call
bind/unbind on the persistence provider.
The problem I see is that I still do not understand how your implementation
will work with all the scenarios we are currently using - we can not drop these
scenarios.
For me, nested-conversations won't work without some sort of flow description
(external or annotations does not matter) which will assure that the
conversation stack is always clean and in known state.
I also can not see how a single-conversation model will be able to emulate the
multi-conversation model Orchestra currently uses later on then.
Unfortunately I am not able to convince you about the beauty of Orchestra. But
that is ok, differente people have different views and needs. Going the scope
way has been discussed with others and at that time we came to the conclusio
that this is a well-known pattern and easy to understand. And as I said, it
works very well here and is easy to code with.
BTW: I never cared how other frameworks worked as I wanted to implement the
vision which has been built in my head after some discussions with other
developers. That other frameworks work different does not mean that they are
better, even if the framework is that company-backed (and thus more accepted)
like JBoss Seam or Spring WebFlow.
Clearly I can not welcome a rewrite of Orchestra as long as I do not get to the
point you vision. We are at Version 1.3 and Orchestra is used, even in the wild.
Which does not mean that I am against your ideas. The opposite is the case, if
all your promises turn out to be true, and if this realy adds some value, well,
why not drop the way Orchestra currently works in favor of your way.
Just, I need to see it in action.
You have to understand that this can not be demonstrated by rewriting Orchestra trunk,
thus, I suggested to "hack-around" your idea into the current Orchestra API.
Which you declined.
Next thing I can propose is to create a branch of Orchestra and start rewriting
it there. Since I do not understand all your visions you have to do the main
work.
Keep in mind that stuff like
* Orchestra Flow - handling dialog scenarios
* allowing converters/validators using persistence
* allowing multiple, different configured, conversations at the same time (same
request/same view) (long-living criteria-selector whith short-living
criteria-result-view)
* allow to jump in the application back and forth using the navigation by not
creating new conversations all the time, reuse the conversation (if still
living) so the user can resume the work
* allow to timout other conversations if not accessed any more.
(order-processing, customer-update scenario)
has to work with your new design too.
Also keep in mind that the current solution just requires to call
"Conversation.invalidate" in some cases. So Orchestra supports the "do not clutter
your code with persistence stuff" paradigm. The main idea of most ORM frameworks.
Also, please keep in mind that Orchestra has to be different to the others e.g. Seam and
WebFlow, else we have to stand the question why to use Orchestra ... something I will not
spend my time for - to say the truth, even I would use the "orignals" then.
Is this an acceptable proposal? I really would like to see it work and
incorporate it into Orchestra then.
If not, the last thing I see is to start another project, which surely is
suboptimal; to say its best.
Ciao,
Mario
