In case I wasn't clear, the use of naming conventions is IN ADDITION TO the annotation support. The updated docs clearly say you can mix and match.
On 12/21/06, Ron Piterman <[EMAIL PROTECTED]> wrote:
Kent Tong 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. Bad me, I didn't read the whole thread - my two cents: I would find it better to combine both, so one *may* use annotations, or one *may* implement an interface, which gives you a strong compile-time check... Cheers, Ron > 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
