This is the direction I'm looking to evolve the framework. This will start being easier in 4.1. I'll be able to seperate user code from framework code since user code will no longer extend from Tapestry base classes (a compatibility layer will remain until 4.2 or 4.3). Right now, Tapestry code and user code gets too involved with each other via inheritance, makes it hard to seperate. I really want there to be a much more minimal API, a stable SPI, and more internal ocde that is free to change at any time. If I started a new Tapestry from scratch, you can imagine all this as day-1. It's much harder to evolve release by release than to throw it all away. I still think we can get there, eventually. The new infrastructure in 4.0 is making this trend much easier.
On 11/29/05, Leonardo Quijano Vincenzi <[EMAIL PROTECTED]> wrote: > In this point I think is *very* important to have a design plan for > Tapestry. Probably the main cause of going from beta to beta is random > API changes because of the "this is better..."... "no! this is even > better!" ... "no, that was broken, it doesn't support X"...etc cycle. > > A release plan can help us in this respect. Separating the frameworks in > several mostly self-contained parts also helps. For example, I propose > the following separation of Tapestry: > > - Tapestry-Core > - Tapestry-Annotations > - Tapestry-Portlets > - Tapestry-Components > > -- > Ing. Leonardo Quijano Vincenzi > DTQ Software > > > > > --------------------------------------------------------------------- > 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]
