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
Mario Ivankovits schrieb:
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.
Hello again,
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.
Of course that's a nice feature of Orchestra by now, but that's what I'd
call an implementation detail,
Hi Bernhard,
It's great to see some design discussion about Orchestra!
Bernhard Huemer schrieb:
Hi folks,
I've been using Orchestra for a few months now and in doing so I've
been questioning some major implementation decisions, to be more
specific I really want to discuss if it's really
hello,
are the wiki pages [1] and [2] up-to-date?
regards,
gerhard
[1] http://wiki.apache.org/myfaces/OrchestraDialogPageFlowDesign1
[2] http://wiki.apache.org/myfaces/OrchestraDialogPageFlowDesign2
2008/10/27 Mario Ivankovits [EMAIL PROTECTED]
Hi!
Example 1)
I've developed some views
Link [1] is obsolete; it is there only for historical purposes.
Link [2] is mostly up-to-date. There have been a few changes to the code
that are not reflected here, but it is 95% correct and certainly good
enough for a general understanding of orchestra-flow.
Regards,
Simon
Gerhard Petracek
Hi!
Example 1)
I've developed some views for a search dialog that I wanted to use in at
least two different conversations. Everything worked fine for the first
conversation. The following code listing should give you an idea of the
problem.
However (as noted in my other email) flow
Hello,
Any new ideas that could improve Orchestra would be great.
I'm not sure at the moment exactly what this rewrite
would do; what exactly are you proposing?
Well, basically I'd refactor the ConversationContext so that it's
actually the main conversation of Orchestra. The conversation
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).
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
10 matches
Mail list logo
