I've updated the site and deployed new snapshots. There's a snazzy diagram made with OmniGraffle to describe component rendering (alas, yEd does a better job with layout, but everything else is better in OmniGraffle).
I've also added a similar naming conventions system for component event handlers, i.e.: onSubmit() or onSubmitFromMyForm(). On 12/21/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
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
-- 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
