That diagram does look nice. I'm sure it's some mac only thing but I'll hold out hope anyways. :)
On 12/21/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
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
-- Jesse Kuhnert Tapestry/Dojo team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
