That remains to be seen; my current vision doesn't take this into account. It's pretty much the same as Tapestry today, except that where today you have a subclass of AbstractComponent as the nodes of the component heirarchy tree, tomorrow you'll have a pair of objects; the fixed ComponentImpl class and the user-supplied "peer" class.
On 12/21/05, Ron Piterman <[EMAIL PROTECTED]> wrote: > 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] > > -- 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]
