On Wed, 18 Mar 2015 05:21:51 -0300, Poggenpohl, Daniel
<daniel.poggenp...@isst.fraunhofer.de> wrote:
Hello,
Hi!
Have you seen http://tapestry.apache.org/persistent-page-data.html?
For example, I have a page and database entities used in the page. What
is the difference in using @Persist for these entities? If I don't use
@Persist, are these objects only stored server-side in the VM?
Non-annotated fields are kept during the request and thrown away when it
finishes. Where it's stored depends on the value attribute of @Persist for
that given field. With @Persist(PersistenceConstants.SESSION), it's
basically putting the field into the HttpSession with an attribute name
crafted to be unique among pages and components, avoiding mix-ups. With
@Persist(PersistenceConstants.CLIENT), it's stored on the client, as a
query parameter or hidden field. With
@Persist(PersistenceConstants.FLASH), it's stored in the session, but
automatically removed after it's read in another request. This information
was taken from here:
http://tapestry.apache.org/5.3/apidocs/org/apache/tapestry5/PersistenceConstants.html.
If you're using tapestry-hibernate, you can use
@Persist(HibernatePersistenceConstants.ENTITY). If you're using
tapestry-jpa, you can use @Persist(JpaPersistenceConstants.ENTITY). These
last two store just class name and id, not the entity object itself.
If I use @Persist,
- where is the data stored on the client side? In a cookie? Could I read
this data?
See above.
- What does using SESSION lead to? Creating a session cookie?
This is up to the servlet container, not Tapestry.
- should I rather persist primitive type (e.g. int) entity ID's in the
page or can I use the entities themselves?
It depends on the usage. If you just want to store just a reference to the
object, not storing changes that weren't propagated to the database yet,
- Does JPA.ENTITY automatically store only the entity ID's in the cookie
between requests?
I'm not sure what you mean by JPA.ENTITY here. Anyway, Tapestry itself,
out-of-the-box, doesn't use cookies to store @Persist'ed fields, but you
can use Or use the ENTITY persistent field strategies explained above. In
addition, you can also implement your own PersistentFieldStrategy to store
@Persist'ed fields in any way you want: session, database, cookie, by id,
whole object ...
Should I rather use entity ID's or entities? If entities are used in
multiple methods, they always needed to loaded via DAO. After the first
query the objects probably are cached to speed up later ones, aren't
they?
Tapestry itself doesn't cache your objects unless you explicitly ask. You
can use the @Cached annotation in a page, component and mixin method and
the method return value will be cached on first call in a given request,
with subsequent method calls in the same request just returning the cached
values.
Anyway, the recommended approach is to *not* use @Persist unless you've
left with no other option. The best way to pass an entity reference from
one page to another or to an event link is using the context, as explained
here: http://tapestry.apache.org/page-navigation.html. This avoid usage of
HttpSession, lowering the memory usage and avoiding problems when the user
uses multiple tabs.
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
