On Tue, 19 Jan 2010 19:26:52 -0200, Massimo Lusetti <[email protected]>
wrote:
One idea that's occured to me is that, in addition to instrumenting
injected fields and parameter fields, we could use the same trick for
ordinary fields, holding transient per-request data. Effectively, the
page would contain no mutable state, all mutable state for the page
would be shunted off into a per-request HashMap.
... while this feels like a derivation from a jure-language...
It really feels like some dynamic languages such as Javascript.
Jure language???
Well field access is quite common so putting an overhead on that are
doesn't sounds so appealing
Thinking about it, non-annotated fields are not used that much except in
pages with loops or grids.
That said we already have have an application server to run T5 that
holds a various types of pools and threads so i see simplifications of
the "T5 page" mechanism as a great plus,
Making Tapestry page instances stateless would make they seem a little
like servlets and the fields as type-safe attributes in the request scope.
:)
What about component fields? Would they be stored by complete id? And
mixin fields?
having one instance of a page
instead of a pool to serve requests is by definition a good thing
while i'm not sure to follow you where you want to "store" the map
holding the "request states"
The map could be stored in a ThreadLocal in even in the HttpServletRequest.
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, software architect and developer, Ars Machina Tecnologia da
Informação Ltda.
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
