Yes, very sorry for the backwards breaking API change. I hope it is the first and last major API related mistake that I make.
In regard to Howard's designs, I hope I can describe what I think without sounding too zealous and whatnot, but I think they are reallly really good. It will drop all sorts of barriers that currently exist for adoption because of the inheritance chain, as well as a lot of other things. More importantly than that (for me at least) is that it does a ~lot~ more than just break the inheritance chain. It starts to build an API that creates a uniform interaction/behaviour across both sides of the fence, server and browser. This will create less of a barrier for people needing to learn both concepts, which they will if they want to create rich web applications in the browser without coding in the dark. Things like mix-ins, the annotated event listeners, etc..They are all design patterns that are currently being used by the uber web gurus leading the whole web X.0 charge. I feel really grateful/lucky to witness what is happening and am very happy that I get to play some small role in it. I wouldn't be surprised at all if it did the same thing to web dev that things like hibernate have done to j2ee . (though I hope it's not trivializing it. ) I'm not nearly as good at expressing my thoughts as others, but the concepts being put forth here really encapsulate the best of all current programming practices that affect us (in the web world at least). Intuitive default behaviours that help reduce the need to bind specific values to input fields to do mundane validation and form handling is similar to some of the things RoR is doing. The SPI as well as the command sort of event interface concept represents a lot of what is making eclipse such a successful product. Mixins are of course both a RoR / browser javascript / any dynamic language sort of behaviour. I'm sure I'm not seeing / describing it all the way it's being invisioned but from whatever knowledge I've accumulated so far it's really nearly as perfect as it can get with Java . (for now :) ) 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. > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://opennotion.com
