Yeah, I guess it was an off the cuff long shot sort of response... ;)
Another thought regarding render phases was that you could also do something
like this:
@Render()
public void rendering(){}
The default "phase" value would be umm.."render"? No idea...You could then
do more by saying something like:
@Render(after=true, phase="cleanup")
public void doCleanup()
This example has questionable use...But the basic point is that a very large
amount of sometimes hard to understand logic could be broken up into simple
parameters to the annotations...This would start to lend itself nicely to
similar functionality provided by @EventListener:
@Render(after=true,component="<t5 comp ref>")
Using smart defaults again the default phase would be "render" , and it
would allow you to target a component you have a reference to (via
injection/other parameter?) ..
I've found with EventListener that these seemingly simple little parameters
can hide a lot of very complicated logic behind the scenes, but is usually
pretty easy to understand. Maybe you could still keep a few core phase type
annotations, but typing is always such a pain if you decide to add more
phases...And this method easily lets you do the before/after logic around
~any~ phase without adding more types...Something I've done in t4.1:
http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/java/org/apache/tapestry/services/ComponentRenderWorker.java?view=markup
Perhaps @RenderBody would still make sense as it's so different than @Render
of normal component stuff..
This starts to hint at the possibility of a sort of phase rendering service
that uses all of these values to plug everything together during render..Yet
another thing people can interact/extend/etc with at the service level.
(although I'm sure you have such a service already)
On 9/5/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
That's not really the direction I was originally thinking of, but I'll
give
it some thought. So, perhaps it could be that some component would
register
itself as a MarkupListener, and be told about any new elements that were
created of type "a".
I hadn't really thought of a significant deviations from how Tapestry 4
does
it: the service-providing component (say, Body or Form) identifies itself
with a Well Known Name, and service-using components (Script, TextField,
etc.) use the Well Known Name to find the component and invoke method upon
it.
To be honest, the latter scenario seems more powerful, in that the two
components often want to have a more detailed conversation.
I'll try and file this away in the "interesting ideas" category. There is
likely room for both approaches.
I'm travelling, red eye out to Boston, so I'll be out of touch for a
while.
On 9/5/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
>
> I definitely have more thoughts on this, but probably need to come up
with
> a
> more coherent reply later...
>
> The exposure of the DOM that you've done with your html/xml/etc based
> markup
> handler has definitely opened up more possibilities...I can think of
more
> than a few examples where people being able to say "when this component
is
> rendering html markup I want to be consulted before/after/during the
> addition of any <a> tags in the DOM. ".
>
> If it is performant enough to make extensible, being able to arbitrarily
> add/modify/etc content by specifying certain DOM operations (and the
> content
> conainted within) would give a huge amount of flexibility...This might
> help
> situations where you have a component with a rather complicated method
> handling the majority of rendering, and you only want to do a couple
> things
> at one specific point in the method...Using dom writes to specify where
> that
> should happen would be fairly easy :) .....This just has endless
> possibilities I think....
>
> On 9/5/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
> >
> > That's purrty ;)
> >
> > I'll take a look at this document later today and get back if any
> > immediate thoughts come up wrt different rendering schemes / etc...
> >
> > On 9/5/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
> >
> > > Things are beginning to come together. Just added an @Inject
> annotation
> > > that allows injection directly into fields. More to go on that
front
> > > (in
> > > many cases, Tapestry will be able to deduce what to invoke based on
> > > either
> > > the field name or the field type).
> > >
> > > Also, I've been writing as much documentation as I can, as I go.
> > >
> > > Here's a very important overview on component rendering:
> > >
> > > http://tapestry.apache.org/tapestry5/guide/rendering.html
> > >
> > > I haven't documented my thoughts on mixins yet, but the idea is that
> > > mixins
> > > will contribute in additional render phase methods. We may need
even
> > > more
> > > render phases to properly support this.
> > >
> > > --
> > > 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/(and a dash of TestNG), team member/developer
> >
> > Open source based consulting work centered around
> > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> >
>
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo/(and a dash of TestNG), team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.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/(and a dash of TestNG), team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
