tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Howard Lewis Ship <hls...@gmail.com>
Subject Re: Eliminating side-effects of pooling
Date Sun, 06 Feb 2005 21:33:35 GMT
I'll have to let this one settle a bit. I'm a little nervous about
introducing any half measures.

You are dead one that the IPage interface encompasses too many
responsibilities and needs to be divided up.

What we end up with is a true component, fully encapsulated by
Tapestry and represented as a very, very minimal interface ... and
what I call a peer, which is  the part provided by the developer.

In my vision of 4.0, the peer has a link to the component injected
into it ... as well as all the injections we see in 3.1.

BTW, this will make the component: asset:, etc.binding prefixes more
valuable, because the ognl: prefix will be focused on the peer, not
the component.

Getting past the abstract classes will take some doing.  It indicates
to me a much more  involved AOP approach, with more interception at
the class loader stage, to transform the classes as they are loaded...
removing instance variables,  changing instance variable references,
and adding new methods and constructors.. It also means that there
will need to be a one-to-one correspondince between page (and
component) and class ... and I think this indicates a reversal from
prior approaches, in that we'll start from the page class and use
annotations to identify the optional specification file. It isn't
clear, short of a Tapestry 2.3 style mapping, exactly how we will map
between page name and page class ... perhaps we will have to designate
a package (or list of packages) and start "sniffing" for page classes.

In this respect, Tapestry 3.1, with its focus on injection, may be a
good transition to 4.0 where this aspect will be essential.

I would vastly prefer a version of Tapestry that did not require
abstract classes and accessors.

More thoughts to come ...

On Sun, 6 Feb 2005 23:10:45 +0200, Mind Bridge <mindbridgeweb@yahoo.com> wrote:
> Hi,
> 
> These are some thoughts invoked by the recent post on JIRA.
> 
> A page object is currently doing the following actions:
> 
> (1) Object creation and initialization
> (2) Page structure setup, component setup, bindings, parameter verification,
> etc.
> 
> Of these (1) is relatively fast, and (2) is quite slow. As a result, page
> pooling is essentially required because of (2).
> 
> Unfortunately, page pooling causes a lot of problems, it seems [A].  It is
> possible, however, to separate (1) and (2) and at the same time keep things
> transparent -- no change will be needed in existing applications.
> 
> Here is my suggestion:
> 
> - Rename the current BasePage to, say, PageData.
> 
> - Create a new BasePage that is essentially a proxy. It implements IPage,
> but before render/rewind it is given the appropriate PageData, and all
> method invocations of the IPage interface forward the call to the provided
> PageData.
> 
> - PageData is pooled, in exactly the same way as the current pages. The new
> BasePage and the user objects that inherit it are discarded after each
> request, however, and are recreated completely and reinitialized at the next
> request.
> 
> (Replace Page with Component above when talking about components)
> 
> The main effect is that non-persisten properties with an initial value will
> no longer need to be declared in the JWC file as they will be
> recreated/reinitialized each time. The whole process will be fast, however,
> as the slow part (2) is pooled. The scheme will also require little effort
> to be implemented. Notably, the components will also need to be pooled, but
> then that is needed anyway when pages have dynamic structures (a la Block)
> if wrapper pages are to be avoided, and the code is already there for pages.
> 
> Please note that I see this only an intermediate step to a full-blown
> solution that uses POJOs, does not require you to inherit BasePage, uses
> composition, etc. That will require 4.0, however, while the above will be
> fine for 3.X [B]
> 
> Comments?
> 
> -mb
> 
> [A] For example, there are a lot of messages on the user list of the type "I
> turned off (or on) caching and my app behaves differently!". The whole need
> of "initial-value", defining non-persistent properties, etc, does not seem
> to be well understood. The whole process is more compicated than what people
> are used to.
> 
> [B] One possibility that people will probably appreciate a lot is to support
> both ways to define pages/components -- it is not that hard to do so.
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
> 
> 


-- 
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work.  http://howardlewisship.com

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


Mime
View raw message