On Wed, 18 Mar 2015 07:32:43 -0300, Poggenpohl, Daniel
<daniel.poggenp...@isst.fraunhofer.de> wrote:
Hello,
Hi!
from what I gather, Tapestry intercepts requests and looks for the
according page instances in the server-side application.
Correct, as Tapestry is implemented as a servlet filter, not a servlet, so
"intercepting requests" is a valid statement IMHO. :)
The session id, if present, is transmitted with the request
This is up to the servlet container. Tapestry just uses the HttpSession
provided by Jetty, Tomcat, etc.
, so the appropriate page instance is used that maybe has some
session-@Persist'ed members.
Not correct. @Persist'ed fields (methods aren't persisted) bytecode is
actually changed by Tapestry so, when you're reading it, the actual code
being executed is a method call. Same when you're writing to the field.
You can take a look at the source of PersistWorker to see how this
transformation is done. Since Tapestry 5.2, it doesn't even use a page
pool anymore: each page class has exactly one instance and non-annotated
fields are changed to method calls and the in-request state is delegated
to a Map. But, of course, you don't need to worry about it at all: this is
just opaque implementation details, so much that almost nothing changed to
how your page classes behave when the page pool was removed. Almost
because the @Retain annotation lost its meaning and use, as it was tied to
the page pool, but that annotation was barely used anyway.
So, the session id is probably stored somewhere in the HTML response or
in a local cookie.
That's up to the servlet container, the one which actually implements
HttpSession, which is used by Tapestry as a black box, not caring how it's
implemented.
Any session-@Persisted members are taken and used for generating the
response, but only stored server-side.
It depends on @Persist strategy, the default being storing in the
HttpSession, but there's also client storage too.
The only bigger memory footprint are the possible multitude of
server-side stored @Persist'ed members, if complex members are stored in
the instances. Even then, if I use JPA.ENTITY as a strategy, the
entities are probably not stored as entity instances, but only as their
ID's. Then, the entities are queried for when page requests arrive.
This paragraph is correct.
--
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
