It would be great if Tapestry provided a really nice clear solution to
conversation state (and continuations), but in the meantime the
workarounds are actually not all that hard. Have you looked at the 3
Wizard examples and the Conversations List at http://jumpstart.doublenegative.com.au:8080/jumpstart/
?
One modification I'd like to make to the Wizards is to defer assigning
a conversation id until you're on your way from the first page to the
second page.
Howard's talking about somehow making 5.1 work with Spring WebFlow.
I'll follow that one with great interest, but I'll be wearing my
sceptics hat as I fear that the SWF medicine might be worse than the
problem it's trying to solve.
Here are some good discussions of the problem:
http://www.developertutorials.com/tutorials/java/develop-complex-web-applications-050422/page1.html
http://rifers.org/blogs/gbevin/2005/4/11/continuations_continuations
http://www.artima.com/forums/flat.jsp?forum=226&thread=197351
http://debasishg.blogspot.com/2006/07/spring-web-flow-declarative-web.html
Geoff
On 14/01/2009, at 5:25 PM, Kalle Korhonen wrote:
I don't know if there's a better thread for discussing page scope and
conversation (if you know other threads, please link them in) but
I'm just
doing research on this topic for supporting conversations in Trails.
Shortly, I'm hoping that it'd be possible to have a generic
implementation
for conversations by dictating that a conversation should always
happen on a
single "page" or url with asynchronous calls. From my point of view,
assuming that only the beginning of a conversation can be
bookmarkable and
that a conversation has one-to-one mapping with a url are reasonable
conventions and will greatly simplify the required logic (compared to
xml-based navigation flow configurations). These conversations could
also be
cleaned from session before the session expires and can have
individual
timeout values.
Regarding the problem with multiple pages that others have already
pointed
out, with or without using cookies the urls need to be different (so
the
page contexts can be kept separate). Typically when editing a single
object,
you don't even want to allow multiple windows and this can be easily
dealt
with cookies transparently to the user. The only good example of where
multi-window support is actually useful that I can come up with is
search
(say when you are trying to find the best flight to a destination).
There, I
wouldn't even like to necessary have a conversation identifier as
part of
the url, but as a parameter (e.g. /travelsearch?conversationId=123)
since
it's not meaningful to bookmark a url with a conversationId in it,
but T5
doesn't allow one to easily manipulate urls and the page context is
extremely handy way of making sure all subsequent action requests
(from the
same page) are participating in the same conversation. However, one
of the
issues with T5 I haven't been able to satisfactorily solve is
forcing a page
to use an additional context parameter. I've tried with returning
the same
page from onActivate then setting a conversation id in onPassivate,
which
works in principle but only if I persist the conversation id which
kind of
defies the point. Anybody happen to have a good, generic solution for
automatically adding parameters to the activation context (so they are
visible in the url)? I'd be also interested to know if anybody has
thoughts
on these ideas or is further along in providing a generic
implementation for
conversations in T5.
Kalle
On Fri, Dec 12, 2008 at 11:00 AM, Daniel Jue <teamp...@gmail.com>
wrote:
In the past I manually implemented this behavior by mixing server
side and
client side persistence. My code-fu was probably not very elegant.
In my case, a user could open a report page after filling out a
page of
variables. These report pages would open in a new browser window/
tab. So
instantly you have the situation where two reports can be open but
use
different data. I would store a client side string on each report
page,
and
LRU hash map on the ASO side would match it to the relative data,
just
before the report was run and a new page opened. If it was in the
LRU, I
could grab the cached report. If not, I still had enough
information to
run
the report again. If the report page needed to be refreshed (such as
sorting something on the page, non-async), the client side key
would look
up
the data.
I used a small LRU limit (like 5) to keep the size down.
Daniel
On Fri, Nov 28, 2008 at 10:18 PM, thermus <msch...@gmail.com> wrote:
I'm interested in this as well. Specifically if a user has two page
instances open, how can T5 persistence be used reliably?
I found on Safari and Firefox (not sure about IE, but likely a
problem
there
as well) that the persisted session properties are shared between
page
instances and each page can overwrite the another. My searches
didn't
come
up with a definitive answer although I did see that the question
has been
asked several times. Can anyone comment on this or provide a
workaround?
Peter Stavrinides wrote:
... but what would be ideal in my humble view is a proper page
persistence
Strategy, where a value is retained until the user leaves the
page. In
truth someone posted such a solution which used a cookie, and it
seemed
to
behave exactly as it should, nevertheless I am still against
relying on
a
cookie. I understand this may be difficult to implement due to
Tapestry's
inner workings, particularly the way pages are pooled, but since
conversational state covers some of this ground (the difference
being a
conversation is tied to not only the page, but the window so each
tab
is
treated as a new conversation)...
--
View this message in context:
http://www.nabble.com/Persistance-tp20732003p20743522.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
