Page/component initialisation and properties

[Petter Måhlén <pe...@elevance.se>]

Hi everyone,

I have a couple of thoughts that I would like to get some feedback on. I was
thinking of adding it to the Wiki wishlist, but realised that it would
probably be better to get some second opinions first, since I am still very
new to Tapestry. In general, I really like Tapestry, it's a major difference
in productivity compared to my previous struggles with Struts and similar
frameworks. The only thing I haven't been able to get my head round is how
to handle initialisation of components and passing information from one
component to another in an easy way. I have a couple of ideas that I think
would represent improvements, but maybe I have just missed or misunderstood
things.

1. I think that one of pageBeginRender and prepareForRender should be taken
out, at least in the sense of being an overridable method that can be used
by component developers. I see no advantage in having two possible locations
for initialisation, but lots of potential (and actual, in my case)
confusion.
2. In the method available for initialisation (I would probably vote for
pageBeginRender, since that is less 'internal' than prepareForRender), all
component parameters and properties should be a) valid, in the sense of
having the proper initial values and b) legally modifiable (unless there are
specific read-only properties such as probably an "in" parameter).
3. A corollary to 2 is that a component must be able to count on its
containing component or page already being initialised, meaning that the
initialisation method for that component has already been called. This works
today with prepareForRender, but not with pageBeginRender.

I think this is more or less orthogonal to the Wiki thoughts on "Reworking
Component Parameters" (http://wiki.apache.org/jakarta-tapestry/Tapestry31).
That is, I would like both. :) 

One additional issue related to the caching of property values discussed on
the Wiki is that of persistence, or perhaps more appropriately, scope. Scope
could maybe be "render" (valid during render of this component and contained
components - useful for if you need to store some kind of information during
the rendering and don't want two components of the same class on the same
page to interfere with each other), "request" (for stuff that needs to
available to more than one component on a page), "session" (for stuff that
needs to be available from one request to another). It's not quite the same
as caching - I can imagine a scenario where you would want a "session" scope
property that you know will never change, like maybe an internal user id or
something. This would mean it could be read once and then cached. On the
other hand, a list of objects to be displayed on a page needs to have
"session" scope as well, to make sure that the user can update the objects,
but it should not be cached from request to request since the underlying
data could perhaps be edited by another user, etc.

I realise this would be a fairly large modification, but could it be a
useful direction for 3.1, perhaps? Or is it maybe already in place, only I
have missed it?

/ Petter


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