I wanted to throw in a quick +1 for Kent's comments. Convention is fine sometimes, but not on this one. We have quite a few developers, and although not all of them do significant work on our Tapestry related code, everybody needs to understand and work in it sometimes. A convention based system would require checking external documentation, or just "knowing" how it works, or calling me after spending an hour not understanding why their beginRender code stopped being called. If this convention was shipped, and there was a way to turn it off, I'd do it. Another thing: Since these won't come from base classes, every one of these "convention" based lifecycle methods would have to be individually javadoc'd by the page developer (with nearly duplicate docs) to explain how the method relates to the lifecycle. Javadoc is great, but in a bigger dev organization you don't always get perfect usage. If this was an annotation, that doc about the lifecycle participation would derive automatically from the doc on the Annotation class. Oh, and on the issue about eight annotations vs one with an enum: I prefer the multiple annotations, but I don't really think it's a big deal either way. "@BeginRender" just looks cleaner to me than "@Render( RenderPhase.BEFORE )". jeff
________________________________ From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Wed 12/20/2006 10:39 PM To: Tapestry development Subject: Re: T5: Render phase methods by name, not annotation This is an interesting thread ... we're really seeing where the convention vs. configuration is going. And I see some people who are nervous about convention (the name of the method) vs. configuration (annotating the method). On 12/20/06, Kent Tong <[EMAIL PROTECTED]> wrote: > > Howard Lewis Ship <hlship <at> gmail.com> writes: > > > I have a feeling that in many cases, people will prefer this approach to > the > > annotation approach. Again, the methods can have any visibility, any > return > > type, and flexibility on parameters. > > > > Advantage for me: when training, I can just say "name your method > > beginRender()" ... I can later, if necessary, introduce the annotations. > > Personally I find it just as easy to say "mark your method with > @BeginRender" without further explanations. Therefore, I don't see any > advantage of this approach. In addition, it has some disadvantages: > 1) If the code is refactored (method name is changed), magically the > program will stop working. > 2) If the programmer gets the method name wrong (eg, "startRender" > instead of "beginRender"), there is no early warning until the code > is run. > 3) The name of a method should express what the method does, not when > the method should be invoked (eg, loadCustomer() vs beginRender()). > Surely this can be easily worked around by having beginRender() call > loadCustomer(), but this is bastardizing/overloading the purpose of > the method name. > 4) As a result of 3), the programmer cannot explicitly express his > intention to participate in the rendering phase. If later someone else > modifies the code, particularly if he is not very familiar with Tapestry > as Jesse pointed out, he may not know the significance of the method > name and may change it to better reflect what the method does. With > an annotation it is highly unlikely that he will change it when it is > something that he doesn't understand. > > -- > Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT) > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship TWD Consulting, Inc. Independent J2EE / Open-Source Java Consultant Creator and PMC Chair, Apache Tapestry Creator, Apache HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com <http://howardlewisship.com/>
