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
