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
