You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2006/12/21 01:31:50 UTC
T5: Render phase methods by name, not annotation
Just made a change to T5, tell me what you think:
You can now identify render phase methods by simple method name, rather than
annotation. For each render phase (SetupRender, BeginRender) there's a
corresponding method name (setupRender(), beginRender()). Effectively,
Tapestry treats methods with the specific name exactly the same as methods
with the annotation. Thus, the common example can be rewritten as:
package org.example.app.components;
import org.apache.tapestry.annotations.ComponentClass;
import org.apache.tapestry.annotations.Parameter;
@ComponentClass
public class Count
{
@Parameter
private int _start = 1;
@Parameter(required = true)
private int _end;
@Parameter
private int _value;
private boolean _increment;
void setupRender()
{
_value = _start;
_increment = _start < _end;
}
boolean afterRender()
{
if (_increment)
{
int newValue = _value + 1;
if (newValue <= _end)
{
_value = newValue;
return true;
}
}
else
{
int newValue = _value - 1;
if (newValue >= _end)
{
_value = newValue;
return true;
}
}
return false;
}
}
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.
I'm going to look into doing something for event handler methods (currenlty,
via @OnSubmit).
--
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
Re: T5: Render phase methods by name, not annotation
Posted by D&J Gredler <dj...@gmail.com>.
This isn't directed specifically at this change, but...
What is the problem with having users subclass some sort of BasePage class?
It seems we're coming full circle: extend BasePage and override methods ->
annotate your methods -> "weak override" (i.e. name your methods a certain
way but don't get IDE help with refactoring, finding references, etc). Don't
get me wrong, EJB2 was the devil incarnate ;-) and abstract page classes are
"different" but I don't grok the current POJO craze that makes it a golden
rule to *never* use the basic tenet of object-oriented programming:
inheritance. Is this some side-effect of single inheritance at the language
level in Java?
Again, I'm not trying to criticize (and indeed this change does seem to make
things simpler as long as you aren't looking for IDE support with certain
operations). I just want to understand! So... anyone have a clue stick for
me?
Take care,
Daniel
On 12/21/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> Just made a change to T5, tell me what you think:
>
> You can now identify render phase methods by simple method name, rather
> than
> annotation. For each render phase (SetupRender, BeginRender) there's a
> corresponding method name (setupRender(), beginRender()). Effectively,
> Tapestry treats methods with the specific name exactly the same as methods
> with the annotation. Thus, the common example can be rewritten as:
>
> package org.example.app.components;
>
> import org.apache.tapestry.annotations.ComponentClass;
> import org.apache.tapestry.annotations.Parameter;
>
> @ComponentClass
> public class Count
> {
> @Parameter
> private int _start = 1;
>
> @Parameter(required = true)
> private int _end;
>
> @Parameter
> private int _value;
>
> private boolean _increment;
>
> void setupRender()
> {
> _value = _start;
>
> _increment = _start < _end;
> }
>
> boolean afterRender()
> {
> if (_increment)
> {
> int newValue = _value + 1;
>
> if (newValue <= _end)
> {
> _value = newValue;
> return true;
> }
> }
> else
> {
> int newValue = _value - 1;
>
> if (newValue >= _end)
> {
> _value = newValue;
> return true;
> }
> }
>
> return false;
> }
> }
>
> 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.
>
> I'm going to look into doing something for event handler methods
> (currenlty,
> via @OnSubmit).
>
> --
> 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
>
>
RE: T5: Render phase methods by name, not annotation
Posted by Jeff Lubetkin <je...@zillow.com>.
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:hlship@gmail.com]
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 <ke...@cpttm.org.mo> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
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/>
Re: T5: Render phase methods by name, not annotation
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <ke...@cpttm.org.mo> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
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
Re: T5: Render phase methods by name, not annotation
Posted by RonPiterman <rp...@gmx.net>.
Kent Tong wrote:
> Ron Piterman <rpiterman <at> gmx.net> writes:
>
>> 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...
>
> By method naming, Howard means just method naming *without* implementing
> any interface.
yes I know, but it skips my mind why do such a thing - if the methods
are predefined, why not create an interface for them? is there a solid
reason?
though using tapestry for quite a while I don't remember tapestry event
method names - should I?
when I implement a listener (for a page event), I add the implemenets
clause, navigate in the IDE to the interface (eclipse F3) and copy the
method into my class.
I think howard is considering taking into the pages/component classes a
concept that is very fruitfull in the IoC, but is contraproductive for
this usecase.
Cheers,
Ron
>
> --
> Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: Render phase methods by name, not annotation
Posted by Kent Tong <ke...@cpttm.org.mo>.
Ron Piterman <rpiterman <at> gmx.net> writes:
> 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...
By method naming, Howard means just method naming *without* implementing
any interface.
--
Author of a book for learning Tapestry (http://www.agileskills2.org/EWDT)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: Render phase methods by name, not annotation
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <hl...@gmail.com> 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 <hl...@gmail.com> 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 <rp...@gmx.net> 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: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> >
> > --
> > 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: Render phase methods by name, not annotation
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <hl...@gmail.com> 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 <rp...@gmx.net> 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: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> --
> 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
Re: T5: Render phase methods by name, not annotation
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <rp...@gmx.net> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
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
Re: T5: Render phase methods by name, not annotation
Posted by Ron Piterman <rp...@gmx.net>.
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: Render phase methods by name, not annotation
Posted by Davor Hrg <hr...@gmail.com>.
I'm not so involved with the project as you folks.... but as a user ....
I agree with Kent.
my opinion is that naming conventions are not a welcome additions here.
Annotations are not so hard to explain, especially as they are used more and
more.
method name should state what it is doing, and annotation is perfect here to
say when in render phase it should happen.
Clean code is a bliss, why enable people making it ugly if you don't have to
?
Davor Hrg
On 12/21/06, Kent Tong <ke...@cpttm.org.mo> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: T5: Render phase methods by name, not annotation
Posted by Massimo Lusetti <ml...@gmail.com>.
On 12/21/06, Kent Tong <ke...@cpttm.org.mo> wrote:
> 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.
Well i take your point but, modifying a class which interact with a
framework without knowing how the framework work, seems obvious to
expect unknown behavior. Don't you?
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: Render phase methods by name, not annotation
Posted by Kent Tong <ke...@cpttm.org.mo>.
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: Render phase methods by name, not annotation
Posted by Massimo Lusetti <ml...@gmail.com>.
On 12/21/06, andyhot <an...@di.uoa.gr> wrote:
> the separate annotations look cleaner to me.
>
> i don't quite see the benefits of that enum... Also, didn't testng start
> with a
> single @Configuration to end up with Before/After Test/Method/Class/Suite ?
>
> I prefer that, even though it's 8 times more!
FWIW I'm with Andy, it even has the advantage of IDE support based on
class prompting. And for the sake of simplicity, i would stick with
the motto, do small classes that do small thing but does them very
well.
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: Render phase methods by name, not annotation
Posted by Jesse Kuhnert <jk...@gmail.com>.
This thread has been fun I agree. Mostly I just wanted to dump out my
brewing fears of making sure the render cycle was as intuitive as can
reasonably be made possible (as I believe it to be the ever elusive
main thing that people indirectly attribute to the supposed "steep
learning curve" ) , as well as fears of seeing annotation concepts
from other un-related areas crop up ...
Obviously I trust and know Howard will choose the most pragmatic
approach that makes sense at this point, esp. as this is all in his
head currently and I'm not mentally able to be "there" right now. Does
fear mongering count as constructive help? ;)
On 12/21/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> @Render(value=RenderPhase default=BEFORE)
>
> RenderPhase: enum SETUP, BEFORE, BEFORE_TEMPLATE, BEFORE_BODY, AFTER_BODY,
> AFTER_TEMPLATE, AFTER, CLEANUP
>
> On 12/20/06, Jesse Kuhnert <jk...@gmail.com> wrote:
> >
> > There probably are some very specific circumstances where you want to
> > make a clear delineation between rendering vs.
> > configuration/setup/maintenance type tasks - but like I said ...this
> > was more just me sharing thoughts as I thought them.
> >
> > I still like the general idea of condensing the (majority) of phases
> > into a single param though. (maybe @BeforeRender @AfterRender would
> > still be good instead of using before=true/after=true )
> >
> > The other specific reason why I brought up the TestNG analogy was for
> > the "dangerous for us" reason why those concepts might work well for
> > TestNG which is still primarily concerned with constructs specific to
> > a java class and not to rendering a system of interlocking components.
> > (in possibly many varied ways / uses to achieve different rendering
> > techniques )
> >
> > On 12/20/06, andyhot <an...@di.uoa.gr> wrote:
> > > Howard Lewis Ship wrote:
> > > > This is certainly something we can revisit. @Render plus an enum that
> > > > defines when to invoke would work just as well as the eight? current
> > > > seperate annotations.
> > >
> > > the separate annotations look cleaner to me.
> > >
> > > i don't quite see the benefits of that enum... Also, didn't testng start
> > > with a
> > > single @Configuration to end up with Before/After
> > Test/Method/Class/Suite ?
> > >
> > > I prefer that, even though it's 8 times more!
> > >
> > >
> > > >
> > > > On 12/20/06, Jesse Kuhnert <jk...@gmail.com> wrote:
> > > >>
> > > >> Yeah, I think this was a case of me not doing enough homework which
> > is
> > > >> why I was afraid to speak up, but I didn't mean for one method to be
> > > >> re-used for different phases..More like:
> > > >>
> > > >> @ComponentClass
> > > >> public class Count
> > > >> {
> > > >> @Parameter
> > > >> private int _start = 1;
> > > >>
> > > >> @Parameter(required = true)
> > > >> private int _end;
> > > >>
> > > >> @Parameter
> > > >> private int _value;
> > > >>
> > > >> private boolean _increment;
> > > >>
> > > >> @Render("setup")
> > > >> void setupRender()
> > > >> {
> > > >> _value = _start;
> > > >>
> > > >> _increment = _start < _end;
> > > >> }
> > > >>
> > > >> @Render(after=true)
> > > >> boolean afterRender()
> > > >> {
> > > >> if (_increment)
> > > >> {
> > > >> int newValue = _value + 1;
> > > >>
> > > >> if (newValue <= _end)
> > > >> {
> > > >> _value = newValue;
> > > >> return true;
> > > >> }
> > > >> }
> > > >> else
> > > >> {
> > > >> int newValue = _value - 1;
> > > >>
> > > >> if (newValue >= _end)
> > > >> {
> > > >> _value = newValue;
> > > >> return true;
> > > >> }
> > > >> }
> > > >>
> > > >> return false;
> > > >> }
> > > >> }
> > > >>
> > > >> <snipped>
> > > >> >
> > > >> > Just re-read your paragraph and now I think I'm not getting your
> > idea.
> > > >> > Perhaps you could post a version of the Count component with
> > > >> annotations
> > > >> the
> > > >> > way you'd like to see them?
> > > >> >
> > > >>
> > > >>
> > > >> --
> > > >> 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: dev-unsubscribe@tapestry.apache.org
> > > >> For additional commands, e-mail: dev-help@tapestry.apache.org
> > > >>
> > > >>
> > > >
> > > >
> > >
> > >
> > > --
> > > Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
> > > Tapestry / Tacos developer
> > > Open Source / J2EE Consulting
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> >
> > --
> > 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: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: Render phase methods by name, not annotation
Posted by Howard Lewis Ship <hl...@gmail.com>.
@Render(value=RenderPhase default=BEFORE)
RenderPhase: enum SETUP, BEFORE, BEFORE_TEMPLATE, BEFORE_BODY, AFTER_BODY,
AFTER_TEMPLATE, AFTER, CLEANUP
On 12/20/06, Jesse Kuhnert <jk...@gmail.com> wrote:
>
> There probably are some very specific circumstances where you want to
> make a clear delineation between rendering vs.
> configuration/setup/maintenance type tasks - but like I said ...this
> was more just me sharing thoughts as I thought them.
>
> I still like the general idea of condensing the (majority) of phases
> into a single param though. (maybe @BeforeRender @AfterRender would
> still be good instead of using before=true/after=true )
>
> The other specific reason why I brought up the TestNG analogy was for
> the "dangerous for us" reason why those concepts might work well for
> TestNG which is still primarily concerned with constructs specific to
> a java class and not to rendering a system of interlocking components.
> (in possibly many varied ways / uses to achieve different rendering
> techniques )
>
> On 12/20/06, andyhot <an...@di.uoa.gr> wrote:
> > Howard Lewis Ship wrote:
> > > This is certainly something we can revisit. @Render plus an enum that
> > > defines when to invoke would work just as well as the eight? current
> > > seperate annotations.
> >
> > the separate annotations look cleaner to me.
> >
> > i don't quite see the benefits of that enum... Also, didn't testng start
> > with a
> > single @Configuration to end up with Before/After
> Test/Method/Class/Suite ?
> >
> > I prefer that, even though it's 8 times more!
> >
> >
> > >
> > > On 12/20/06, Jesse Kuhnert <jk...@gmail.com> wrote:
> > >>
> > >> Yeah, I think this was a case of me not doing enough homework which
> is
> > >> why I was afraid to speak up, but I didn't mean for one method to be
> > >> re-used for different phases..More like:
> > >>
> > >> @ComponentClass
> > >> public class Count
> > >> {
> > >> @Parameter
> > >> private int _start = 1;
> > >>
> > >> @Parameter(required = true)
> > >> private int _end;
> > >>
> > >> @Parameter
> > >> private int _value;
> > >>
> > >> private boolean _increment;
> > >>
> > >> @Render("setup")
> > >> void setupRender()
> > >> {
> > >> _value = _start;
> > >>
> > >> _increment = _start < _end;
> > >> }
> > >>
> > >> @Render(after=true)
> > >> boolean afterRender()
> > >> {
> > >> if (_increment)
> > >> {
> > >> int newValue = _value + 1;
> > >>
> > >> if (newValue <= _end)
> > >> {
> > >> _value = newValue;
> > >> return true;
> > >> }
> > >> }
> > >> else
> > >> {
> > >> int newValue = _value - 1;
> > >>
> > >> if (newValue >= _end)
> > >> {
> > >> _value = newValue;
> > >> return true;
> > >> }
> > >> }
> > >>
> > >> return false;
> > >> }
> > >> }
> > >>
> > >> <snipped>
> > >> >
> > >> > Just re-read your paragraph and now I think I'm not getting your
> idea.
> > >> > Perhaps you could post a version of the Count component with
> > >> annotations
> > >> the
> > >> > way you'd like to see them?
> > >> >
> > >>
> > >>
> > >> --
> > >> 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: dev-unsubscribe@tapestry.apache.org
> > >> For additional commands, e-mail: dev-help@tapestry.apache.org
> > >>
> > >>
> > >
> > >
> >
> >
> > --
> > Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
> > Tapestry / Tacos developer
> > Open Source / J2EE Consulting
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
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
Re: T5: Render phase methods by name, not annotation
Posted by Jesse Kuhnert <jk...@gmail.com>.
There probably are some very specific circumstances where you want to
make a clear delineation between rendering vs.
configuration/setup/maintenance type tasks - but like I said ...this
was more just me sharing thoughts as I thought them.
I still like the general idea of condensing the (majority) of phases
into a single param though. (maybe @BeforeRender @AfterRender would
still be good instead of using before=true/after=true )
The other specific reason why I brought up the TestNG analogy was for
the "dangerous for us" reason why those concepts might work well for
TestNG which is still primarily concerned with constructs specific to
a java class and not to rendering a system of interlocking components.
(in possibly many varied ways / uses to achieve different rendering
techniques )
On 12/20/06, andyhot <an...@di.uoa.gr> wrote:
> Howard Lewis Ship wrote:
> > This is certainly something we can revisit. @Render plus an enum that
> > defines when to invoke would work just as well as the eight? current
> > seperate annotations.
>
> the separate annotations look cleaner to me.
>
> i don't quite see the benefits of that enum... Also, didn't testng start
> with a
> single @Configuration to end up with Before/After Test/Method/Class/Suite ?
>
> I prefer that, even though it's 8 times more!
>
>
> >
> > On 12/20/06, Jesse Kuhnert <jk...@gmail.com> wrote:
> >>
> >> Yeah, I think this was a case of me not doing enough homework which is
> >> why I was afraid to speak up, but I didn't mean for one method to be
> >> re-used for different phases..More like:
> >>
> >> @ComponentClass
> >> public class Count
> >> {
> >> @Parameter
> >> private int _start = 1;
> >>
> >> @Parameter(required = true)
> >> private int _end;
> >>
> >> @Parameter
> >> private int _value;
> >>
> >> private boolean _increment;
> >>
> >> @Render("setup")
> >> void setupRender()
> >> {
> >> _value = _start;
> >>
> >> _increment = _start < _end;
> >> }
> >>
> >> @Render(after=true)
> >> boolean afterRender()
> >> {
> >> if (_increment)
> >> {
> >> int newValue = _value + 1;
> >>
> >> if (newValue <= _end)
> >> {
> >> _value = newValue;
> >> return true;
> >> }
> >> }
> >> else
> >> {
> >> int newValue = _value - 1;
> >>
> >> if (newValue >= _end)
> >> {
> >> _value = newValue;
> >> return true;
> >> }
> >> }
> >>
> >> return false;
> >> }
> >> }
> >>
> >> <snipped>
> >> >
> >> > Just re-read your paragraph and now I think I'm not getting your idea.
> >> > Perhaps you could post a version of the Count component with
> >> annotations
> >> the
> >> > way you'd like to see them?
> >> >
> >>
> >>
> >> --
> >> 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: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >
> >
>
>
> --
> Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
> Tapestry / Tacos developer
> Open Source / J2EE Consulting
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: Render phase methods by name, not annotation
Posted by andyhot <an...@di.uoa.gr>.
Howard Lewis Ship wrote:
> This is certainly something we can revisit. @Render plus an enum that
> defines when to invoke would work just as well as the eight? current
> seperate annotations.
the separate annotations look cleaner to me.
i don't quite see the benefits of that enum... Also, didn't testng start
with a
single @Configuration to end up with Before/After Test/Method/Class/Suite ?
I prefer that, even though it's 8 times more!
>
> On 12/20/06, Jesse Kuhnert <jk...@gmail.com> wrote:
>>
>> Yeah, I think this was a case of me not doing enough homework which is
>> why I was afraid to speak up, but I didn't mean for one method to be
>> re-used for different phases..More like:
>>
>> @ComponentClass
>> public class Count
>> {
>> @Parameter
>> private int _start = 1;
>>
>> @Parameter(required = true)
>> private int _end;
>>
>> @Parameter
>> private int _value;
>>
>> private boolean _increment;
>>
>> @Render("setup")
>> void setupRender()
>> {
>> _value = _start;
>>
>> _increment = _start < _end;
>> }
>>
>> @Render(after=true)
>> boolean afterRender()
>> {
>> if (_increment)
>> {
>> int newValue = _value + 1;
>>
>> if (newValue <= _end)
>> {
>> _value = newValue;
>> return true;
>> }
>> }
>> else
>> {
>> int newValue = _value - 1;
>>
>> if (newValue >= _end)
>> {
>> _value = newValue;
>> return true;
>> }
>> }
>>
>> return false;
>> }
>> }
>>
>> <snipped>
>> >
>> > Just re-read your paragraph and now I think I'm not getting your idea.
>> > Perhaps you could post a version of the Count component with
>> annotations
>> the
>> > way you'd like to see them?
>> >
>>
>>
>> --
>> 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: Render phase methods by name, not annotation
Posted by Howard Lewis Ship <hl...@gmail.com>.
This is certainly something we can revisit. @Render plus an enum that
defines when to invoke would work just as well as the eight? current
seperate annotations.
On 12/20/06, Jesse Kuhnert <jk...@gmail.com> wrote:
>
> Yeah, I think this was a case of me not doing enough homework which is
> why I was afraid to speak up, but I didn't mean for one method to be
> re-used for different phases..More like:
>
> @ComponentClass
> public class Count
> {
> @Parameter
> private int _start = 1;
>
> @Parameter(required = true)
> private int _end;
>
> @Parameter
> private int _value;
>
> private boolean _increment;
>
> @Render("setup")
> void setupRender()
> {
> _value = _start;
>
> _increment = _start < _end;
> }
>
> @Render(after=true)
> boolean afterRender()
> {
> if (_increment)
> {
> int newValue = _value + 1;
>
> if (newValue <= _end)
> {
> _value = newValue;
> return true;
> }
> }
> else
> {
> int newValue = _value - 1;
>
> if (newValue >= _end)
> {
> _value = newValue;
> return true;
> }
> }
>
> return false;
> }
> }
>
> <snipped>
> >
> > Just re-read your paragraph and now I think I'm not getting your idea.
> > Perhaps you could post a version of the Count component with annotations
> the
> > way you'd like to see them?
> >
>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
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
Re: T5: Render phase methods by name, not annotation
Posted by Jesse Kuhnert <jk...@gmail.com>.
Yeah, I think this was a case of me not doing enough homework which is
why I was afraid to speak up, but I didn't mean for one method to be
re-used for different phases..More like:
@ComponentClass
public class Count
{
@Parameter
private int _start = 1;
@Parameter(required = true)
private int _end;
@Parameter
private int _value;
private boolean _increment;
@Render("setup")
void setupRender()
{
_value = _start;
_increment = _start < _end;
}
@Render(after=true)
boolean afterRender()
{
if (_increment)
{
int newValue = _value + 1;
if (newValue <= _end)
{
_value = newValue;
return true;
}
}
else
{
int newValue = _value - 1;
if (newValue >= _end)
{
_value = newValue;
return true;
}
}
return false;
}
}
<snipped>
>
> Just re-read your paragraph and now I think I'm not getting your idea.
> Perhaps you could post a version of the Count component with annotations the
> way you'd like to see them?
>
--
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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: Render phase methods by name, not annotation
Posted by Howard Lewis Ship <hl...@gmail.com>.
But a lot of this presupposes that the method names are going to change,
which they are not (with the new committment to backwards compatibility).
On 12/21/06, D&J Gredler <dj...@gmail.com> wrote:
>
> Comments inline:
>
> On 12/21/06, Massimo Lusetti <ml...@gmail.com> wrote:
> >
> > On 12/21/06, D&J Gredler <dj...@gmail.com> wrote:
> >
> > > Massimo -
> > >
> > > I'm talking about things like quickly finding all the places you hook
> > into
> > > the SetupRender / BeginRender / xxx phase, automatically refactoring
> > these
> > > methods up or down a level, etc, all without requiring intimate
> > knowledge of
> > > the framework or project. Kent and Jeff have made this point elsewhere
> > in
> > > this thread.
> >
> > Couldn't this be achieved by you have your own interface and/or base
> > classes?
>
>
> Yep, but this thread is about the framework defaults. We're not just
> talking
> about "I want to do this" or "he needs to do that", we're talking "this is
> the option that will save hundreds of developers thousands of hours in the
> aggregate". I just happen to be one of those developers ;-)
>
> > I like the "convention over configuration" approach, but is flagging a
> > > method with an annotation really configuration? Maybe, but barely.
> > You're
> > > asking people to code in Java (rather than Python or Ruby or Groovy),
> > but
> > > you want them to (partially) give up some of the biggest benefits of
> > > strongly-typed languages. That sounds like an uphill battle to me. I
> > think
> > > you're going to have to be very clear with the users on what benefits
> > they
> > > can expect to see in exchange for this sacrifice.
> > >
> > > The obvious answer, of course, is that users do not have to make this
> > > sacrifice if they do not wish to, since they will always have the
> option
> > of
> > > flagging their methods with annotations. I'd argue, however, that (a)
> > > requiring the developer to make this choice initially, and (b)
> requiring
> > him
> > > to continue to be aware of both options, possibly mixing them, is much
> > more
> > > of a cognitive load on the developer than just requiring him to flag
> his
> > > methods with annotations. "Convention over configuration" isn't an end
> > in
> > > and of itself, it's a means to an end -- namely the ease of use that
> > leads
> > > to lower development costs and higher quality.
> >
> > I've to admit I've had the same feeling as you about loosing some
> > compile time checks, but as long as there's still Annotation based i
> > feel safe.
> > At the end i think that if you want to work with a framework or
> > library you should first know as much as you can about it, even if you
> > work in a team, there should be a person which is in charge of knowing
> > that specific part of the whole project, so i don't consider valid
> > statements the ones like "all without requiring intimate knowledge of
> > the framework or project.". I simply don't find it feasible :)
>
>
> As far as I'm concerned, that's the utopian goal, and the closer Tapestry
> is
> to achieving it, the better off we all are.
>
> Take care,
>
> Daniel
>
>
--
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
Re: T5: Render phase methods by name, not annotation
Posted by D&J Gredler <dj...@gmail.com>.
Comments inline:
On 12/21/06, Massimo Lusetti <ml...@gmail.com> wrote:
>
> On 12/21/06, D&J Gredler <dj...@gmail.com> wrote:
>
> > Massimo -
> >
> > I'm talking about things like quickly finding all the places you hook
> into
> > the SetupRender / BeginRender / xxx phase, automatically refactoring
> these
> > methods up or down a level, etc, all without requiring intimate
> knowledge of
> > the framework or project. Kent and Jeff have made this point elsewhere
> in
> > this thread.
>
> Couldn't this be achieved by you have your own interface and/or base
> classes?
Yep, but this thread is about the framework defaults. We're not just talking
about "I want to do this" or "he needs to do that", we're talking "this is
the option that will save hundreds of developers thousands of hours in the
aggregate". I just happen to be one of those developers ;-)
> I like the "convention over configuration" approach, but is flagging a
> > method with an annotation really configuration? Maybe, but barely.
> You're
> > asking people to code in Java (rather than Python or Ruby or Groovy),
> but
> > you want them to (partially) give up some of the biggest benefits of
> > strongly-typed languages. That sounds like an uphill battle to me. I
> think
> > you're going to have to be very clear with the users on what benefits
> they
> > can expect to see in exchange for this sacrifice.
> >
> > The obvious answer, of course, is that users do not have to make this
> > sacrifice if they do not wish to, since they will always have the option
> of
> > flagging their methods with annotations. I'd argue, however, that (a)
> > requiring the developer to make this choice initially, and (b) requiring
> him
> > to continue to be aware of both options, possibly mixing them, is much
> more
> > of a cognitive load on the developer than just requiring him to flag his
> > methods with annotations. "Convention over configuration" isn't an end
> in
> > and of itself, it's a means to an end -- namely the ease of use that
> leads
> > to lower development costs and higher quality.
>
> I've to admit I've had the same feeling as you about loosing some
> compile time checks, but as long as there's still Annotation based i
> feel safe.
> At the end i think that if you want to work with a framework or
> library you should first know as much as you can about it, even if you
> work in a team, there should be a person which is in charge of knowing
> that specific part of the whole project, so i don't consider valid
> statements the ones like "all without requiring intimate knowledge of
> the framework or project.". I simply don't find it feasible :)
As far as I'm concerned, that's the utopian goal, and the closer Tapestry is
to achieving it, the better off we all are.
Take care,
Daniel
Re: T5: Render phase methods by name, not annotation
Posted by Massimo Lusetti <ml...@gmail.com>.
On 12/21/06, D&J Gredler <dj...@gmail.com> wrote:
> Massimo -
>
> I'm talking about things like quickly finding all the places you hook into
> the SetupRender / BeginRender / xxx phase, automatically refactoring these
> methods up or down a level, etc, all without requiring intimate knowledge of
> the framework or project. Kent and Jeff have made this point elsewhere in
> this thread.
Couldn't this be achieved by you have your own interface and/or base classes?
> I like the "convention over configuration" approach, but is flagging a
> method with an annotation really configuration? Maybe, but barely. You're
> asking people to code in Java (rather than Python or Ruby or Groovy), but
> you want them to (partially) give up some of the biggest benefits of
> strongly-typed languages. That sounds like an uphill battle to me. I think
> you're going to have to be very clear with the users on what benefits they
> can expect to see in exchange for this sacrifice.
>
> The obvious answer, of course, is that users do not have to make this
> sacrifice if they do not wish to, since they will always have the option of
> flagging their methods with annotations. I'd argue, however, that (a)
> requiring the developer to make this choice initially, and (b) requiring him
> to continue to be aware of both options, possibly mixing them, is much more
> of a cognitive load on the developer than just requiring him to flag his
> methods with annotations. "Convention over configuration" isn't an end in
> and of itself, it's a means to an end -- namely the ease of use that leads
> to lower development costs and higher quality.
I've to admit I've had the same feeling as you about loosing some
compile time checks, but as long as there's still Annotation based i
feel safe.
At the end i think that if you want to work with a framework or
library you should first know as much as you can about it, even if you
work in a team, there should be a person which is in charge of knowing
that specific part of the whole project, so i don't consider valid
statements the ones like "all without requiring intimate knowledge of
the framework or project.". I simply don't find it feasible :)
Thanks for your time, regards
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: Render phase methods by name, not annotation
Posted by D&J Gredler <dj...@gmail.com>.
Massimo -
I'm talking about things like quickly finding all the places you hook into
the SetupRender / BeginRender / xxx phase, automatically refactoring these
methods up or down a level, etc, all without requiring intimate knowledge of
the framework or project. Kent and Jeff have made this point elsewhere in
this thread.
Howard -
I like the "convention over configuration" approach, but is flagging a
method with an annotation really configuration? Maybe, but barely. You're
asking people to code in Java (rather than Python or Ruby or Groovy), but
you want them to (partially) give up some of the biggest benefits of
strongly-typed languages. That sounds like an uphill battle to me. I think
you're going to have to be very clear with the users on what benefits they
can expect to see in exchange for this sacrifice.
The obvious answer, of course, is that users do not have to make this
sacrifice if they do not wish to, since they will always have the option of
flagging their methods with annotations. I'd argue, however, that (a)
requiring the developer to make this choice initially, and (b) requiring him
to continue to be aware of both options, possibly mixing them, is much more
of a cognitive load on the developer than just requiring him to flag his
methods with annotations. "Convention over configuration" isn't an end in
and of itself, it's a means to an end -- namely the ease of use that leads
to lower development costs and higher quality.
Phew!
Time to go look at Martin's email address again! ;-)
On 12/21/06, Massimo Lusetti <ml...@gmail.com> wrote:
>
> On 12/21/06, D&J Gredler <dj...@gmail.com> wrote:
>
> > So basically testability and backwards compatibility. I mourn the loss
> of
> > IDE support for refactoring, reference searching, etc, but I see your
> point.
> > Thanks for clearing things up!
>
> What kind of IDE refactoring support and reference searching are you
> talking about?
> I would like to understand this point...
>
> --
> Massimo
> http://meridio.blogspot.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: T5: Render phase methods by name, not annotation
Posted by Massimo Lusetti <ml...@gmail.com>.
On 12/21/06, D&J Gredler <dj...@gmail.com> wrote:
> So basically testability and backwards compatibility. I mourn the loss of
> IDE support for refactoring, reference searching, etc, but I see your point.
> Thanks for clearing things up!
What kind of IDE refactoring support and reference searching are you
talking about?
I would like to understand this point...
--
Massimo
http://meridio.blogspot.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: Render phase methods by name, not annotation
Posted by Martin Strand <do...@gmail.com>.
Perhaps this abstract base class could instead be an interface that you
can optionally implement to get some IDE support.
On Thu, 21 Dec 2006 05:15:34 +0100, D&J Gredler <dj...@gmail.com>
wrote:
> Also true... but not by default. I'm just mentioning the downsides,
> making
> sure we're clear on the tradeoffs involved.
>
> On 12/21/06, andyhot <an...@di.uoa.gr> wrote:
>>
>> D&J Gredler wrote:
>> > So basically testability and backwards compatibility. I mourn the loss
>> of
>> > IDE support for refactoring, reference searching, etc, but I see your
>> > point.
>> > Thanks for clearing things up!
>>
>> You can always have your own base class - anyhow you like!
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: Render phase methods by name, not annotation
Posted by D&J Gredler <dj...@gmail.com>.
Also true... but not by default. I'm just mentioning the downsides, making
sure we're clear on the tradeoffs involved.
On 12/21/06, andyhot <an...@di.uoa.gr> wrote:
>
> D&J Gredler wrote:
> > So basically testability and backwards compatibility. I mourn the loss
> of
> > IDE support for refactoring, reference searching, etc, but I see your
> > point.
> > Thanks for clearing things up!
>
> You can always have your own base class - anyhow you like!
>
Re: T5: Render phase methods by name, not annotation
Posted by andyhot <an...@di.uoa.gr>.
D&J Gredler wrote:
> So basically testability and backwards compatibility. I mourn the loss of
> IDE support for refactoring, reference searching, etc, but I see your
> point.
> Thanks for clearing things up!
You can always have your own base class - anyhow you like!
>
> On 12/21/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>>
>> D&J:
>>
>> POJOs go hand-in-hand with a strong testing philosophy. One of the
>> problems
>> with unit testing Tapestry 4 pages and components is that you often
>> end up
>> "testing" framework code you've inherited. You have to have and
>> understanding of internals of Tapestry in order to test your own code.
>> There's also the fragile base class problem ... backwards compatibility,
>> as
>> we've seen, is very hard to maintain at the same time as adding new
>> features.
>>
>> Right now, Tapestry 5 supports a single parameter to render phase
>> methods:
>> an optional MarkupWriter. The magic is that if, in the future, we find
>> that
>> many render phase methods could benefit from some additional parameters,
>> we
>> can define access to those as well. Existing methods in existing
>> code are
>> unaffected, code that wants to make use of new features simply defines
>> parameters with the newly available types.
>>
>> In Tapestry 5, the class enhancement hides all the interactions between
>> Tapestry internal code and user application code. It can do some very
>> tricky
>> things and do things very efficiently. It's basically like having a
>> Tapestry consultant on staff, wriiting customized code for you ... it
>> just
>> happens automatically, at runtime.
>>
>> Jesse:
>>
>> There's a few reasons for the new rendering cycle approach. One is
>> efficiency by avoiding tail recursion. Second there's the concept of
>> mixins; all these rendering phases represent extension points that
>> mixins
>> can plug into. By taking the flow of control out of user code, the
>> framework has absolute knowledge of what's happening ... I think you ran
>> into some of these issues in 4.1. What you describe might end up
>> being a
>> single method that gets invoked multiple times, is passed an Enum
>> describing
>> the phase, and needs a case statement in the middle ... I don't like
>> that
>> idea much.
>>
>> The approach also works well for base classes. I've been swinging
>> around
>> to
>> the idea that every method in a base class sould be either abstract or
>> final. The annotation approach allows you to specifiy a final method and
>> still have it invoked at the correct phase and sequence. For me, the
>> great
>> stumbling block in extending base classes is knowing which methods
>> need to
>> be overridden, and when the super-class implementation should be invoked
>> (first, last, in the middle? on tuesdays?). This is one of the
>> limitations
>> of inheritance, and you can see that the Tapestry 5 code base is
>> extremly
>> flat (nearly everthing extends Object, and I don't think there is an any
>> object that is more than a single class away from Object).
>>
>> You point about a future with more rendering phases is valid, but I'm
>> not
>> sure a single-method approach has any advantage over the
>> annotations-driven
>> approach. Future classes will be able to take advantage of new
>> phases one
>> way or the other.
>>
>> In terms of tutorials and training: this latest approach (specific
>> names)
>> will work great. In tutorials and labs people just want to know what to
>> type. Trust me, this is how I make my living. Once it gets in through
>> the
>> fingertips and into the brain, we can start explaining that Tapestry
>> does
>> more.
>>
>>
>> Just re-read your paragraph and now I think I'm not getting your idea.
>> Perhaps you could post a version of the Count component with annotations
>> the
>> way you'd like to see them?
>>
>> On 12/20/06, Jesse Kuhnert <jk...@gmail.com> wrote:
>> >
>> > I have some thoughts on this but am a little afraid to share them as I
>> > know I haven't invested nearly enough time thinking about it to say
>> > very strongly that I think they are right....but I guess I'll ramble
>> > on anyways., heh
>> >
>> > I think there is one very core problem with even this style of
>> > rendering, not the logic of it but in some of the black box effects it
>> > might have. When I first found Tapestry I was coming from a world
>> > where I hadn't touched web developed in a good 5-6 years and had been
>> > living in a land concerned purely with either high end sort of
>> > enterprise appservery things , desktop gui client development using
>> > various native && swing gui toolkits as well as low level device
>> > development/etc....When I saw your component model it was an immediate
>> > and unquestioning "this is it" moment and I haven't looked back since.
>> > (well I have, but only to keep myself honest and things still look
>> > pretty good to me ;) )
>> >
>> > There are however a ~lot~ of people who don't immediately think of the
>> > same thing that you might when they here the word "render". In basic
>> > web development yeah, they know about IO streams and that you're
>> > generally writing some crap back to the browser - but they probably
>> > aren't thinking of it in the literal sense of how most rendering
>> > outside of web development actually works. (which is of course
>> > extremely similar to how Tapestry does it). Even people who have
>> > written a lot of c++ based/swing apps don't really get what the
>> > toolkit is doing most of the time. This is made obvious by the large
>> > number of applications that all purely use the controls/components
>> > that come with the toolkit.. They've never had to branch out and
>> > really think about what drawing means with that graphics object or the
>> > performance impact one simple concept like "clipping bounds" would
>> > have on their system.
>> >
>> > Even in the only other day to day sort of case where I consistently
>> > use annotations - TestNG, they are used in a "mostly" very
>> > straightforward way. If you are writing a test class in java then
>> > chances are good that you know what "class" vs "method" means, as well
>> > as what things like "before" and "after" running a method/class might
>> > imply. This isn't a very far stretch at all...
>> >
>> > Rendering however is a totally different animal. So, if I were to
>> > choose a "pulling stuff out of my ass" way to do it I would do
>> > something like this instead:
>> >
>> > -) Define one basic annotation for rendering. @Render
>> >
>> > -) Break up the difference between the real actual "phases" of
>> > rendering as one parameter to the annotation and the parts that deal
>> > with whether to execute it before/(during?)/after as another.
>> >
>> > This has the added benefits of :
>> >
>> > -) Making people feel less frustrated because they feel like they are
>> > working with some kind of black magic. While you/I and many other
>> > people may unquestionably know exactly what rendering something means
>> > I'm convinced that the good majority of the development world really
>> > doesn't. This is fine. If we don't try and disguise it as something
>> > that "looks" like it should be natural and obvious then people will be
>> > less frustrated by it. They'll go to the documentation page that
>> > discusses what each rendering phase is and what it does/why it is used
>> > and just use them appropriately...If they ever feel like investing in
>> > figuring out what the term means in the broader sense then fine, but
>> > it won't be a requirement for learning.
>> >
>> > -) Leaving it as a set of parameters makes it much less likely that
>> > the framework will ever get into a situation where more rendering
>> > phases need to be added/taken away and peoples components start
>> > feeling awkward as they get more and more lost and overwhelmed feeling
>> > like there is a madman behind the curtain doing things to their
>> > components and they just don't understand why/how.
>> >
>> > Those are my thoughts..Again, not completely well thought out but I
>> > think there is some potential for something good to be partially taken
>> > out of it.
>> >
>> > On 12/20/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>> > > Just made a change to T5, tell me what you think:
>> > >
>> > > You can now identify render phase methods by simple method name,
>> rather
>> > than
>> > > annotation. For each render phase (SetupRender, BeginRender)
>> there's
>> a
>> > > corresponding method name (setupRender(),
>> beginRender()). Effectively,
>> > > Tapestry treats methods with the specific name exactly the same as
>> > methods
>> > > with the annotation. Thus, the common example can be rewritten as:
>> > >
>> > > package org.example.app.components;
>> > >
>> > > import org.apache.tapestry.annotations.ComponentClass;
>> > > import org.apache.tapestry.annotations.Parameter;
>> > >
>> > > @ComponentClass
>> > > public class Count
>> > > {
>> > > @Parameter
>> > > private int _start = 1;
>> > >
>> > > @Parameter(required = true)
>> > > private int _end;
>> > >
>> > > @Parameter
>> > > private int _value;
>> > >
>> > > private boolean _increment;
>> > >
>> > > void setupRender()
>> > > {
>> > > _value = _start;
>> > >
>> > > _increment = _start < _end;
>> > > }
>> > >
>> > > boolean afterRender()
>> > > {
>> > > if (_increment)
>> > > {
>> > > int newValue = _value + 1;
>> > >
>> > > if (newValue <= _end)
>> > > {
>> > > _value = newValue;
>> > > return true;
>> > > }
>> > > }
>> > > else
>> > > {
>> > > int newValue = _value - 1;
>> > >
>> > > if (newValue >= _end)
>> > > {
>> > > _value = newValue;
>> > > return true;
>> > > }
>> > > }
>> > >
>> > > return false;
>> > > }
>> > > }
>> > >
>> > > 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.
>> > >
>> > > I'm going to look into doing something for event handler methods
>> > (currenlty,
>> > > via @OnSubmit).
>> > >
>> > > --
>> > > 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: dev-unsubscribe@tapestry.apache.org
>> > For additional commands, e-mail: dev-help@tapestry.apache.org
>> >
>> >
>>
>>
>> --
>> 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
>>
>>
>
--
Andreas Andreou - andyhot@apache.org - http://andyhot.di.uoa.gr
Tapestry / Tacos developer
Open Source / J2EE Consulting
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: T5: Render phase methods by name, not annotation
Posted by D&J Gredler <dj...@gmail.com>.
So basically testability and backwards compatibility. I mourn the loss of
IDE support for refactoring, reference searching, etc, but I see your point.
Thanks for clearing things up!
On 12/21/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> D&J:
>
> POJOs go hand-in-hand with a strong testing philosophy. One of the
> problems
> with unit testing Tapestry 4 pages and components is that you often end up
> "testing" framework code you've inherited. You have to have and
> understanding of internals of Tapestry in order to test your own code.
> There's also the fragile base class problem ... backwards compatibility,
> as
> we've seen, is very hard to maintain at the same time as adding new
> features.
>
> Right now, Tapestry 5 supports a single parameter to render phase methods:
> an optional MarkupWriter. The magic is that if, in the future, we find
> that
> many render phase methods could benefit from some additional parameters,
> we
> can define access to those as well. Existing methods in existing code are
> unaffected, code that wants to make use of new features simply defines
> parameters with the newly available types.
>
> In Tapestry 5, the class enhancement hides all the interactions between
> Tapestry internal code and user application code. It can do some very
> tricky
> things and do things very efficiently. It's basically like having a
> Tapestry consultant on staff, wriiting customized code for you ... it just
> happens automatically, at runtime.
>
> Jesse:
>
> There's a few reasons for the new rendering cycle approach. One is
> efficiency by avoiding tail recursion. Second there's the concept of
> mixins; all these rendering phases represent extension points that mixins
> can plug into. By taking the flow of control out of user code, the
> framework has absolute knowledge of what's happening ... I think you ran
> into some of these issues in 4.1. What you describe might end up being a
> single method that gets invoked multiple times, is passed an Enum
> describing
> the phase, and needs a case statement in the middle ... I don't like that
> idea much.
>
> The approach also works well for base classes. I've been swinging around
> to
> the idea that every method in a base class sould be either abstract or
> final. The annotation approach allows you to specifiy a final method and
> still have it invoked at the correct phase and sequence. For me, the great
> stumbling block in extending base classes is knowing which methods need to
> be overridden, and when the super-class implementation should be invoked
> (first, last, in the middle? on tuesdays?). This is one of the
> limitations
> of inheritance, and you can see that the Tapestry 5 code base is extremly
> flat (nearly everthing extends Object, and I don't think there is an any
> object that is more than a single class away from Object).
>
> You point about a future with more rendering phases is valid, but I'm not
> sure a single-method approach has any advantage over the
> annotations-driven
> approach. Future classes will be able to take advantage of new phases one
> way or the other.
>
> In terms of tutorials and training: this latest approach (specific names)
> will work great. In tutorials and labs people just want to know what to
> type. Trust me, this is how I make my living. Once it gets in through the
> fingertips and into the brain, we can start explaining that Tapestry does
> more.
>
>
> Just re-read your paragraph and now I think I'm not getting your idea.
> Perhaps you could post a version of the Count component with annotations
> the
> way you'd like to see them?
>
> On 12/20/06, Jesse Kuhnert <jk...@gmail.com> wrote:
> >
> > I have some thoughts on this but am a little afraid to share them as I
> > know I haven't invested nearly enough time thinking about it to say
> > very strongly that I think they are right....but I guess I'll ramble
> > on anyways., heh
> >
> > I think there is one very core problem with even this style of
> > rendering, not the logic of it but in some of the black box effects it
> > might have. When I first found Tapestry I was coming from a world
> > where I hadn't touched web developed in a good 5-6 years and had been
> > living in a land concerned purely with either high end sort of
> > enterprise appservery things , desktop gui client development using
> > various native && swing gui toolkits as well as low level device
> > development/etc....When I saw your component model it was an immediate
> > and unquestioning "this is it" moment and I haven't looked back since.
> > (well I have, but only to keep myself honest and things still look
> > pretty good to me ;) )
> >
> > There are however a ~lot~ of people who don't immediately think of the
> > same thing that you might when they here the word "render". In basic
> > web development yeah, they know about IO streams and that you're
> > generally writing some crap back to the browser - but they probably
> > aren't thinking of it in the literal sense of how most rendering
> > outside of web development actually works. (which is of course
> > extremely similar to how Tapestry does it). Even people who have
> > written a lot of c++ based/swing apps don't really get what the
> > toolkit is doing most of the time. This is made obvious by the large
> > number of applications that all purely use the controls/components
> > that come with the toolkit.. They've never had to branch out and
> > really think about what drawing means with that graphics object or the
> > performance impact one simple concept like "clipping bounds" would
> > have on their system.
> >
> > Even in the only other day to day sort of case where I consistently
> > use annotations - TestNG, they are used in a "mostly" very
> > straightforward way. If you are writing a test class in java then
> > chances are good that you know what "class" vs "method" means, as well
> > as what things like "before" and "after" running a method/class might
> > imply. This isn't a very far stretch at all...
> >
> > Rendering however is a totally different animal. So, if I were to
> > choose a "pulling stuff out of my ass" way to do it I would do
> > something like this instead:
> >
> > -) Define one basic annotation for rendering. @Render
> >
> > -) Break up the difference between the real actual "phases" of
> > rendering as one parameter to the annotation and the parts that deal
> > with whether to execute it before/(during?)/after as another.
> >
> > This has the added benefits of :
> >
> > -) Making people feel less frustrated because they feel like they are
> > working with some kind of black magic. While you/I and many other
> > people may unquestionably know exactly what rendering something means
> > I'm convinced that the good majority of the development world really
> > doesn't. This is fine. If we don't try and disguise it as something
> > that "looks" like it should be natural and obvious then people will be
> > less frustrated by it. They'll go to the documentation page that
> > discusses what each rendering phase is and what it does/why it is used
> > and just use them appropriately...If they ever feel like investing in
> > figuring out what the term means in the broader sense then fine, but
> > it won't be a requirement for learning.
> >
> > -) Leaving it as a set of parameters makes it much less likely that
> > the framework will ever get into a situation where more rendering
> > phases need to be added/taken away and peoples components start
> > feeling awkward as they get more and more lost and overwhelmed feeling
> > like there is a madman behind the curtain doing things to their
> > components and they just don't understand why/how.
> >
> > Those are my thoughts..Again, not completely well thought out but I
> > think there is some potential for something good to be partially taken
> > out of it.
> >
> > On 12/20/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> > > Just made a change to T5, tell me what you think:
> > >
> > > You can now identify render phase methods by simple method name,
> rather
> > than
> > > annotation. For each render phase (SetupRender, BeginRender) there's
> a
> > > corresponding method name (setupRender(),
> beginRender()). Effectively,
> > > Tapestry treats methods with the specific name exactly the same as
> > methods
> > > with the annotation. Thus, the common example can be rewritten as:
> > >
> > > package org.example.app.components;
> > >
> > > import org.apache.tapestry.annotations.ComponentClass;
> > > import org.apache.tapestry.annotations.Parameter;
> > >
> > > @ComponentClass
> > > public class Count
> > > {
> > > @Parameter
> > > private int _start = 1;
> > >
> > > @Parameter(required = true)
> > > private int _end;
> > >
> > > @Parameter
> > > private int _value;
> > >
> > > private boolean _increment;
> > >
> > > void setupRender()
> > > {
> > > _value = _start;
> > >
> > > _increment = _start < _end;
> > > }
> > >
> > > boolean afterRender()
> > > {
> > > if (_increment)
> > > {
> > > int newValue = _value + 1;
> > >
> > > if (newValue <= _end)
> > > {
> > > _value = newValue;
> > > return true;
> > > }
> > > }
> > > else
> > > {
> > > int newValue = _value - 1;
> > >
> > > if (newValue >= _end)
> > > {
> > > _value = newValue;
> > > return true;
> > > }
> > > }
> > >
> > > return false;
> > > }
> > > }
> > >
> > > 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.
> > >
> > > I'm going to look into doing something for event handler methods
> > (currenlty,
> > > via @OnSubmit).
> > >
> > > --
> > > 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: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> --
> 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
>
>
Re: T5: Render phase methods by name, not annotation
Posted by Howard Lewis Ship <hl...@gmail.com>.
D&J:
POJOs go hand-in-hand with a strong testing philosophy. One of the problems
with unit testing Tapestry 4 pages and components is that you often end up
"testing" framework code you've inherited. You have to have and
understanding of internals of Tapestry in order to test your own code.
There's also the fragile base class problem ... backwards compatibility, as
we've seen, is very hard to maintain at the same time as adding new
features.
Right now, Tapestry 5 supports a single parameter to render phase methods:
an optional MarkupWriter. The magic is that if, in the future, we find that
many render phase methods could benefit from some additional parameters, we
can define access to those as well. Existing methods in existing code are
unaffected, code that wants to make use of new features simply defines
parameters with the newly available types.
In Tapestry 5, the class enhancement hides all the interactions between
Tapestry internal code and user application code. It can do some very tricky
things and do things very efficiently. It's basically like having a
Tapestry consultant on staff, wriiting customized code for you ... it just
happens automatically, at runtime.
Jesse:
There's a few reasons for the new rendering cycle approach. One is
efficiency by avoiding tail recursion. Second there's the concept of
mixins; all these rendering phases represent extension points that mixins
can plug into. By taking the flow of control out of user code, the
framework has absolute knowledge of what's happening ... I think you ran
into some of these issues in 4.1. What you describe might end up being a
single method that gets invoked multiple times, is passed an Enum describing
the phase, and needs a case statement in the middle ... I don't like that
idea much.
The approach also works well for base classes. I've been swinging around to
the idea that every method in a base class sould be either abstract or
final. The annotation approach allows you to specifiy a final method and
still have it invoked at the correct phase and sequence. For me, the great
stumbling block in extending base classes is knowing which methods need to
be overridden, and when the super-class implementation should be invoked
(first, last, in the middle? on tuesdays?). This is one of the limitations
of inheritance, and you can see that the Tapestry 5 code base is extremly
flat (nearly everthing extends Object, and I don't think there is an any
object that is more than a single class away from Object).
You point about a future with more rendering phases is valid, but I'm not
sure a single-method approach has any advantage over the annotations-driven
approach. Future classes will be able to take advantage of new phases one
way or the other.
In terms of tutorials and training: this latest approach (specific names)
will work great. In tutorials and labs people just want to know what to
type. Trust me, this is how I make my living. Once it gets in through the
fingertips and into the brain, we can start explaining that Tapestry does
more.
Just re-read your paragraph and now I think I'm not getting your idea.
Perhaps you could post a version of the Count component with annotations the
way you'd like to see them?
On 12/20/06, Jesse Kuhnert <jk...@gmail.com> wrote:
>
> I have some thoughts on this but am a little afraid to share them as I
> know I haven't invested nearly enough time thinking about it to say
> very strongly that I think they are right....but I guess I'll ramble
> on anyways., heh
>
> I think there is one very core problem with even this style of
> rendering, not the logic of it but in some of the black box effects it
> might have. When I first found Tapestry I was coming from a world
> where I hadn't touched web developed in a good 5-6 years and had been
> living in a land concerned purely with either high end sort of
> enterprise appservery things , desktop gui client development using
> various native && swing gui toolkits as well as low level device
> development/etc....When I saw your component model it was an immediate
> and unquestioning "this is it" moment and I haven't looked back since.
> (well I have, but only to keep myself honest and things still look
> pretty good to me ;) )
>
> There are however a ~lot~ of people who don't immediately think of the
> same thing that you might when they here the word "render". In basic
> web development yeah, they know about IO streams and that you're
> generally writing some crap back to the browser - but they probably
> aren't thinking of it in the literal sense of how most rendering
> outside of web development actually works. (which is of course
> extremely similar to how Tapestry does it). Even people who have
> written a lot of c++ based/swing apps don't really get what the
> toolkit is doing most of the time. This is made obvious by the large
> number of applications that all purely use the controls/components
> that come with the toolkit.. They've never had to branch out and
> really think about what drawing means with that graphics object or the
> performance impact one simple concept like "clipping bounds" would
> have on their system.
>
> Even in the only other day to day sort of case where I consistently
> use annotations - TestNG, they are used in a "mostly" very
> straightforward way. If you are writing a test class in java then
> chances are good that you know what "class" vs "method" means, as well
> as what things like "before" and "after" running a method/class might
> imply. This isn't a very far stretch at all...
>
> Rendering however is a totally different animal. So, if I were to
> choose a "pulling stuff out of my ass" way to do it I would do
> something like this instead:
>
> -) Define one basic annotation for rendering. @Render
>
> -) Break up the difference between the real actual "phases" of
> rendering as one parameter to the annotation and the parts that deal
> with whether to execute it before/(during?)/after as another.
>
> This has the added benefits of :
>
> -) Making people feel less frustrated because they feel like they are
> working with some kind of black magic. While you/I and many other
> people may unquestionably know exactly what rendering something means
> I'm convinced that the good majority of the development world really
> doesn't. This is fine. If we don't try and disguise it as something
> that "looks" like it should be natural and obvious then people will be
> less frustrated by it. They'll go to the documentation page that
> discusses what each rendering phase is and what it does/why it is used
> and just use them appropriately...If they ever feel like investing in
> figuring out what the term means in the broader sense then fine, but
> it won't be a requirement for learning.
>
> -) Leaving it as a set of parameters makes it much less likely that
> the framework will ever get into a situation where more rendering
> phases need to be added/taken away and peoples components start
> feeling awkward as they get more and more lost and overwhelmed feeling
> like there is a madman behind the curtain doing things to their
> components and they just don't understand why/how.
>
> Those are my thoughts..Again, not completely well thought out but I
> think there is some potential for something good to be partially taken
> out of it.
>
> On 12/20/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> > Just made a change to T5, tell me what you think:
> >
> > You can now identify render phase methods by simple method name, rather
> than
> > annotation. For each render phase (SetupRender, BeginRender) there's a
> > corresponding method name (setupRender(), beginRender()). Effectively,
> > Tapestry treats methods with the specific name exactly the same as
> methods
> > with the annotation. Thus, the common example can be rewritten as:
> >
> > package org.example.app.components;
> >
> > import org.apache.tapestry.annotations.ComponentClass;
> > import org.apache.tapestry.annotations.Parameter;
> >
> > @ComponentClass
> > public class Count
> > {
> > @Parameter
> > private int _start = 1;
> >
> > @Parameter(required = true)
> > private int _end;
> >
> > @Parameter
> > private int _value;
> >
> > private boolean _increment;
> >
> > void setupRender()
> > {
> > _value = _start;
> >
> > _increment = _start < _end;
> > }
> >
> > boolean afterRender()
> > {
> > if (_increment)
> > {
> > int newValue = _value + 1;
> >
> > if (newValue <= _end)
> > {
> > _value = newValue;
> > return true;
> > }
> > }
> > else
> > {
> > int newValue = _value - 1;
> >
> > if (newValue >= _end)
> > {
> > _value = newValue;
> > return true;
> > }
> > }
> >
> > return false;
> > }
> > }
> >
> > 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.
> >
> > I'm going to look into doing something for event handler methods
> (currenlty,
> > via @OnSubmit).
> >
> > --
> > 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
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
Re: T5: Render phase methods by name, not annotation
Posted by Jesse Kuhnert <jk...@gmail.com>.
I have some thoughts on this but am a little afraid to share them as I
know I haven't invested nearly enough time thinking about it to say
very strongly that I think they are right....but I guess I'll ramble
on anyways., heh
I think there is one very core problem with even this style of
rendering, not the logic of it but in some of the black box effects it
might have. When I first found Tapestry I was coming from a world
where I hadn't touched web developed in a good 5-6 years and had been
living in a land concerned purely with either high end sort of
enterprise appservery things , desktop gui client development using
various native && swing gui toolkits as well as low level device
development/etc....When I saw your component model it was an immediate
and unquestioning "this is it" moment and I haven't looked back since.
(well I have, but only to keep myself honest and things still look
pretty good to me ;) )
There are however a ~lot~ of people who don't immediately think of the
same thing that you might when they here the word "render". In basic
web development yeah, they know about IO streams and that you're
generally writing some crap back to the browser - but they probably
aren't thinking of it in the literal sense of how most rendering
outside of web development actually works. (which is of course
extremely similar to how Tapestry does it). Even people who have
written a lot of c++ based/swing apps don't really get what the
toolkit is doing most of the time. This is made obvious by the large
number of applications that all purely use the controls/components
that come with the toolkit.. They've never had to branch out and
really think about what drawing means with that graphics object or the
performance impact one simple concept like "clipping bounds" would
have on their system.
Even in the only other day to day sort of case where I consistently
use annotations - TestNG, they are used in a "mostly" very
straightforward way. If you are writing a test class in java then
chances are good that you know what "class" vs "method" means, as well
as what things like "before" and "after" running a method/class might
imply. This isn't a very far stretch at all...
Rendering however is a totally different animal. So, if I were to
choose a "pulling stuff out of my ass" way to do it I would do
something like this instead:
-) Define one basic annotation for rendering. @Render
-) Break up the difference between the real actual "phases" of
rendering as one parameter to the annotation and the parts that deal
with whether to execute it before/(during?)/after as another.
This has the added benefits of :
-) Making people feel less frustrated because they feel like they are
working with some kind of black magic. While you/I and many other
people may unquestionably know exactly what rendering something means
I'm convinced that the good majority of the development world really
doesn't. This is fine. If we don't try and disguise it as something
that "looks" like it should be natural and obvious then people will be
less frustrated by it. They'll go to the documentation page that
discusses what each rendering phase is and what it does/why it is used
and just use them appropriately...If they ever feel like investing in
figuring out what the term means in the broader sense then fine, but
it won't be a requirement for learning.
-) Leaving it as a set of parameters makes it much less likely that
the framework will ever get into a situation where more rendering
phases need to be added/taken away and peoples components start
feeling awkward as they get more and more lost and overwhelmed feeling
like there is a madman behind the curtain doing things to their
components and they just don't understand why/how.
Those are my thoughts..Again, not completely well thought out but I
think there is some potential for something good to be partially taken
out of it.
On 12/20/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> Just made a change to T5, tell me what you think:
>
> You can now identify render phase methods by simple method name, rather than
> annotation. For each render phase (SetupRender, BeginRender) there's a
> corresponding method name (setupRender(), beginRender()). Effectively,
> Tapestry treats methods with the specific name exactly the same as methods
> with the annotation. Thus, the common example can be rewritten as:
>
> package org.example.app.components;
>
> import org.apache.tapestry.annotations.ComponentClass;
> import org.apache.tapestry.annotations.Parameter;
>
> @ComponentClass
> public class Count
> {
> @Parameter
> private int _start = 1;
>
> @Parameter(required = true)
> private int _end;
>
> @Parameter
> private int _value;
>
> private boolean _increment;
>
> void setupRender()
> {
> _value = _start;
>
> _increment = _start < _end;
> }
>
> boolean afterRender()
> {
> if (_increment)
> {
> int newValue = _value + 1;
>
> if (newValue <= _end)
> {
> _value = newValue;
> return true;
> }
> }
> else
> {
> int newValue = _value - 1;
>
> if (newValue >= _end)
> {
> _value = newValue;
> return true;
> }
> }
>
> return false;
> }
> }
>
> 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.
>
> I'm going to look into doing something for event handler methods (currenlty,
> via @OnSubmit).
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org