Hi!
This discussion was already made in this mailing list. There's a very nice
archive at http://www.nabble.com/Tapestry---User-f340.html. Search for
"conversation scope"
(http://www.nabble.com/forum/Search.jtp?query=conversation+scope&sort=date&local=y&forum=340)
or Seam integration.
Em Mon, 15 Dec 2008 09:28:45 -0300, kristjankelt
<kristjank...@hotmail.com> escreveu:
Hello,
I must say first that I really like the design concept of the Tapestry 5.
It's component oriented design and IoC supporting it are really
promising.
But could somebody please explain me the logic behind Tapestry 5 page
persistence handling. I just do not get it.
I think that I have a pretty common use case where there is a page with a
list of items with links to the item detail page.
Users usually open many different detail pages for further investigation
(in
a new tab or in a new window).
A real world example of this is eBay, where you can open several action
items to view detailed information.
Let's imagine that the detail page has to hold it's state somehow.
Now the situation gets really weird. As far as I understand (please tell
me
that I'm wrong), Tapestry 5 keeps only one copy of the persistent state
per
page and session, no mater how many instances of the same page are
actually
created by the user on the client side.
Good example of this misbehavior is Tapestry 5 grid component. Put it on
the
page, create two instances of the page and use the column sorting feature
and look what happens.
You might say that you can use the client side persistence strategy, but
there is another and bigger problem. The persistence strategy must be
set on
the field level and not on the page level.
Honestly, please tell me one use case where this is needed? This design
fault disables the possibility to change grid component persistence
strategy
to match the page strategy.
I would like to suggest also some possible solutions for the further
discussion.
First, a default persistence strategy should be set on the page level
(with
the annotation). When not set, it will default to the session strategy
(or
to omething that is appropriate).
Now, when there is really a need for a different strategy for one field,
then and only then this should be set on the field level.
The second thing would be a new persistence strategy, that will keep one
state per one page instance. It is quite tricky to archive because an
unique
id should be generated and tracked per page instance.
The hardest part is to make sure that every component will include this
id
with it's conversation with the server side.
With best regards,
Kristjan Kelt
--
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
Consultor, desenvolvedor e instrutor em Java
http://www.arsmachina.com.br/thiago
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
