Hi there -- I prefer the explicit "configure*" method approach for most of the reasons mentioned by Kent in his original post, but also for these major reasons:
Reduced ramp-up time for a new developer ------------------------------------------------------------- Under the current annotation approach, new developers have to learn new syntax and tricks to do things that they already knew how to do in java. ( i.e. use setters/getters) Using the configure approach, the only extra thing they need to learn is this configure* method signature. Given a choice between a new developer learning tapestry uniqueness and learning company-specific issues and code, I chose company-specific each and every time -- that is how they are going to add value the fastest to the company's code. Works with existing tools ------------------------------------- I know annotations, are hot and useful but as far as I can tell using the bindings with in a @Component add nothing that could not be done with *less* typing using the configure*() method. Why less typing? I use autocomplete on Eclipse! long variable names? no problem. Developers who accidently misspelled a method name? no problem. Supports refactoring. If I refactor using the existing annotation scheme I have to manually change all the bindings! Talk about a disincentive to being agile! Then everywhere the component is used I have to test to make sure that nothing got missed. double-yech. Using configure*() reduces the possible places I could screw-up. Isn't that what tools and frameworks are supposed to do? [Yes I know that I could still have problems in html files -- see below] Debugging and learning ----------------------------------- If a new-to-tapestry developer or an even a tapestry expert is debugging a component, a configure*() method would provide a valuable place to stick a breakpoint. In this method you would see the component fresh out of the component pool and you could step through it as the component and (its subcomponents initialize). May not be a big deal to the tap experts, but would have shortened my learning curve. Documentation ---------------------- As in one less thing for the Tapestry developers to document. While the tapestry documentation isn't horrid it isn't the best either. Documentation is always the last thing to be done (if ever). All the documentation about the special binding/validation syntax (and bug testing, and bug fixing, etc) would go away. Reduces the need for special tool support ------------------------------------------------------------ There was much hand-wringing about spindle's development being dropped, because tools are necessary. Well how about making it so that *existing* tools, supported by others outside the Tapestry community, do the trick? This lets the Tapestry community support those other tools, avoid custom solutions that depend on the good graces of a single developer, and broadens the number of people already familiar with the tools that they need to know to be productive using Tapestry. Custom tools would still be needed to help support refactoring of methods within html files but this problem is smaller than having to support refactoring within html files, binding annotations, .jwc files and .page files. Thanks for listening... -Pat Moore
