To make the example more complete you could probably throw in an annotation
parameter of "around=true" (possible all of these could be one enum with a
value of true/false/around?) which would mean the actual rendering calling
would be up to the parameter to do from that point. Obvious aop stealing
stuff I guess but it sounds good in theory :)
On 9/5/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
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
--
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
