Exactly, I wasn't too happy when I saw that change (to FormSupport), since it broke a Tacos component I was using.
Really, that release should be numbered 4.1.0, because of the non-backwards compatible code change. Less is more. My vision for Tapestry5 will mean that changes to the API of components will not affect the peer classes provided by application developers. So, I see the API as almost entirely a set of annotations on your classes, fields and methods. There will be an SPI, which will be properly backwards compatible. The majority of the code will be internal implementation, not subject to backwards compatibility, and not visible to the user application. On 4/10/06, Henri Dupre <[EMAIL PROTECTED]> wrote: > 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. > > -- 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]
