On 4/9/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > > In fact, this is why I'm focusing my efforts on an entirely new > codebase for Tapestry5. I'll be finally keeping internal and public > APIs seperate. There'll be very little API in Tapestry5 beyond a few > annotations. All the implementation details will be on the "other side > of the fence", free to evolve from release to release without > affecting existing application code. This should finally address the > issues that keep the Tapestry major (and minor) release numbers > incrementing too quickly. I hope to see a 5.0.57 some day!
Howard, This sounds theorically very good, but one recent change in 4.0.1 broke a signature in the Form class. One would think that this is an internal component and shouldn't be used but given the feedback on the mailing list, many people have been using it. Also for our website, we have been customizing several "internal" components often just for small changes that were not possible to be done otherwise. In Tapestry 3, this wasn't too bad using inheritance. In Tapestry 4, making these types of customization is already more challenging as many small elements of the components classes have package visibility or protected. I have a simple example... We needed to make some links that submit a form and also open a popup window. To do that, we had to write a custom LinkSubmit, and this requires now to copy the whole AbstractSubmit class and this ends in duplicate code which I don't like at all. I'm somehow afraid that by having less API, this type of situation could be worse. And this somehow would definitely ease to make "basic" components but could make some other types of components way more difficult. Thanks, Henri.
