I Guess there is also a (positive) performance issue there (or rather
memoray consumption), since the "peer" (somehow I like "model" better)
will be instanciated for every page instance, all other parts could be
singletones.
Cheers,
Ron
Howard Lewis Ship wrote:
This is something I've been aiming at for a while.
I will speak of components; this also applies to pages as well.
In Tapestry, components are objects that have a number of concerns.
The most basic concerns are:
- transient and persistent property management (via enhanced subclass)
- access to message catalog (via enhanced subclass)
- access to parameter bindings, assets, meta-data (via super-class)
- component heirarchy structure (parent and child components, etc.)
(via super-class)
- lifecycle management (via enhancement and/or super-class)
- custom buisness logic (methods of class)
... etc.
Now, there's an inherent tug-of-war between the super-class
(BaseComponent, AbstractComponent) and the user-provided sub-class.
There's a lot of API inherited from the base class that, in most
cases, the user class has no need or rigtht to access. For example,
from the user class point of view, the structure of the component and
it's specification should be immutable, yet there are many add and set
methods exposed, waiting to be mis-used.
As has been seen in the last couple of years with the interest in
POJOs, inheritance is problematic; it increases the "surface area" of
the API.
Tapestry 4.0, with its emphasis on injecting anything and everything
into a class via abstract properties, sets the stage for properly
addressing this issue.
My vision is to divide what is today the "component" into two pieces,
which (for the moment) I call the "peer" and the "resources".
The peer is a user supplied class, as today, but not needing to extend
from a Tapestry base class.
The component is a fixed implementation, private to Tapestry.
The resources is a "bridge", injected into the peer, that gives the
peer limited access to the structure, bindings, assets, and so forth,
of the component. It's a facade over portions of the component and
page APIs.
The advantage here is that we'll have a much more straightforward
relationship between the framework and the user code. This will
quickly allow the framework to evolve internally without fear of
affecting user code. We will be able to migrate towards an approach
that separates user-related APIs from Tapestry internal APIs. Right
now they're all in one big blob, which brings many changes into
conflict between fixing bugs and APIs and maintaining backwards
compatibility.
My ultimate vision is that the API for Tapestry, the "public" portion
used by end users, will shrink markedly, and be a few event interfaces
and a handful of read-only interfaces.
Of course, new versions of the existing base classes will be kept
around to provide backwards compatibility. As I envision it, the base
classes will largely be reworked to delegate to the "resources"
object.
Many issues still remain to be resolved in my head.
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
