You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Dimitri Taranov <dt...@silverpointcapital.com> on 2008/04/11 22:40:41 UTC

Please Help find Page Initialization API

We are using Tapestry 4.0 for over a year.  Since, we were not able to
find a reliable (called on every request) and consistent (Information
from HttpServletRequest is available through RequestCycle at the time of
call) way to initialize and cleanup the pages to achieve behavior quoted
from the User Guide below.

We are trying to initialize BusinessBehaviourBean which is stored in the
pages instance variable.  We want this bean to have a lifecycle of the
request.  Thus, when page is pulled from the page pool we want to
initialize it.  Then use it for the duration of the request.  Then,
clean it up before returning to the page pool.  At the time we are
initializing this page instance variable we need full access to
information from the HttpServletRequest object.  That is: request
parameters, session objects etc...   For example the bean is user
specific.  Thus we need to know who the user making request is.
We tried few approaches:
1.	Override prepareForRender().  However, that doesn't always work
since  prepareForRender() is not always called by the framework.
2.	Override attach() and finishLoad().  However, RequestCycle is
not available when those are called.   This makes HttpServletRequest
info not available at this point.  At this point servlet container is
aware of the request, so it should be made available by API.

Can anybody suggest how to do this type of initialization?

>>>>>>>>>>>>>>>>>>>>>
Quote from User Guide:
Servlets, and by extension, JavaServer Pages, are inherently stateless.
That is, they will be used simultaneously by many threads and clients.
Because of this, they must not store (in instance variables) any
properties or values that are specific to any single client. 
This creates a frustration for developers, because ordinary programming
techniques must be avoided. Instead, client-specific state and data must
be stored in the HttpSession or as 
HttpServletRequest attributes. This is an awkward and limiting way to
handle both transient state (state that is only needed during the actual
processing of the request) and persistent state (state that should be
available during the processing of this and subsequent requests). 
Tapestry bypasses most of these issues by not sharing objects between
threads and clients. Tapestry uses an object pool to store constructed
page instances. As a page is needed, it is removed from the page pool.
If there are no available pages in the pool, a fresh page instance is
constructed. 
For the duration of a request, a page and all components within the page
are reserved to the single request. There is no chance of conflicts
because only the single thread processing the request will have access
to the page. At the end of the request cycle, the page is reset back to
a pristine state and returned to the shared pool, ready for reuse by the
same client, or by a different client. 


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org