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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
