I'm always a little careful about introducing new properties into components.
What's really needed is a way to track the render stack: what components are actively rendering. How about this: IRequestCycle adds methods to track a stack of rendering objects. Add methods to IRequestCycle to push, pop and query the stack. Change AbstractComponent.render() to push (before renderComponent() ) and pop (in the finally block) the stack. This gives you a rich amount of information, is relatively cheap at runtime, and doesn't introduce new properties into the base component classes. On 7/31/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
Oh. That could be done, but I had originally thought that method felt a little overly verbose for these things. With the current form people sometimes need to define an @Any component to encapsulate blocks to be updated, but there are plenty of scenerios where they could just as easily specify an existing component as the "block" to update. I still think having to use special block components makes the API feel less "sexy"/intuitive to me, but if you really think so I can give it a try. On 7/31/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > I was hoping that you wouldn't need the parent property if you require > the use of an AjaxBlock for this purpose. I suspect it may take a > little bit of retooling inside the partial rendering code. > > On 7/31/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > That sounds perfectly reasonable to me. To summarize my > interpretations: > > > > -) Rename get/set Parent to something more descriptive of what it's > doing, > > like encloser. > > > > -) Create and test some form of Block component that can properly handle > the > > encloser semantics to ensure the logic works for all (known) use cases. > > > > On 7/31/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > > > > > So, parent would be "encloser". > > > > > > This works, to a point, but is limited in that if the body of the > > > component being partially rendered renders a Block, the components in > > > the Block will not be "enclosed" by the target component. > > > > > > Could you have a special AjaxBlock compoonent that fills in this edge > > > case? > > > > > > Tapestry 1.0 had the notion of maintaining a stack of rendering > > > components. That idea will likely resurface, in another form, in T5. > > > > > > On 7/31/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > > > It makes me nervous too. (another reason to want T5) > > > > > > > > My basic problem is that container doesn't return what I want. (in > the > > > way > > > > that I'm doing it) For instance, suppose I had the following html > > > snippet: > > > > > > > > <div jwcid="[EMAIL PROTECTED]"> > > > > <span jwcid="@If" condition="ognl:fooTrue()"> > > > > Some textual content > > > > <span jwcid="@Script" scriptPath="Sample.script" /> > > > > </span> > > > > </div> > > > > > > > > In my "ajax" logic someone might say that they want the component > with > > > id > > > > "any" to be updated (have its IMarkupWriter content captured and > sent > > > back > > > > to browser via XHR, but nothing else) in a request. > > > > > > > > The most intuitive thing to do (which is what tacos tries/attempted > to > > > do ) > > > > in this situation is to not only update the content of the "any" > > > component, > > > > but also any component it contains. > > > > > > > > Now my logic is such that I look at each component render > individually. > > > When > > > > I get to the embedded Script component referenced above I need to > check > > > and > > > > see if it should get a valid IMarkupWriter. Calling getContainer() > will > > > > return the Page/Body in this instance, not the "any" component. > > > > > > > > This makes sense when dealing with ognl/template semantics, but not > in > > > the > > > > sense of knowing who contains you in the context of html blocks. > > > > > > > > The most obvious thing to do was set a temporary "parent" when > adding an > > > > IRender to a components Body. > > > > > > > > I didn't want these methods exposed to the public IComponent API, > but > > > don't > > > > currently know of a better way to do it. (that doesn't involve > javassist > > > > enhancements) > > > > > > > > What are your thoughts in the context of what I just went over? Is > it a > > > > matter of whether or not we want this kind of logic exposed to the > > > public > > > > API's or just the logic itself in general? > > > > > > > > On 7/31/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote: > > > > > > > > > > This makes me nervous. I don't understand how parent would be > > > > > different from container (and existing, rigid, structural > property). > > > > > > > > > > > > > > > On 7/31/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > > > > > I've run into a situation with @Script where I need to be able > to > > > limit > > > > > > script output in dynamic responses. The only problem with > @Script > > > > > templates > > > > > > (for this scenerio) is that the render logic doesn't really > happen > > > in > > > > > the > > > > > > same way that component renders work. > > > > > > > > > > > > Right now if I pass a valid writer to one component any IRender > body > > > > > > instances it contains will automatically have their content > output > > > as > > > > > well. > > > > > > (as is the preferred case for my usage) > > > > > > > > > > > > There is no IWriter to look at (as far as having context to a > parent > > > > > > component) by the time we're at the point of actually writing > some > > > of > > > > > the > > > > > > javascript output. > > > > > > > > > > > > The best solution I've come up with is adding two methods to > > > IComponent. > > > > > > setParent(IComponent)/getParent(). This allows me to walk up the > > > current > > > > > > heirarchy and determine if the component (Script component in > this > > > > > instance) > > > > > > is contained by a component that ~has~ been requested to have > its > > > > > content > > > > > > dynamically updated. > > > > > > > > > > > > I can't find any scenerio in the current codebase where this > would > > > be an > > > > > > issue, but then again I don't know all the various ways people > do > > > things > > > > > > with Tapestry so don't understand the potential problems this > might > > > > > create. > > > > > > > > > > > > I might commit the change now (unless someone replies back > > > soon-ish), > > > > > but > > > > > > will of course revert the change if requested. > > > > > > > > > > > > -- > > > > > > Jesse Kuhnert > > > > > > Tacos/Tapestry, team member/developer > > > > > > > > > > > > Open source based consulting work centered around > > > > > > dojo/tapestry/tacos/hivemind. > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > 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 > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > -- > > > > Jesse Kuhnert > > > > Tacos/Tapestry, team member/developer > > > > > > > > Open source based consulting work centered around > > > > dojo/tapestry/tacos/hivemind. > > > > > > > > > > > > > > > > > -- > > > 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 > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Jesse Kuhnert > > Tacos/Tapestry, team member/developer > > > > Open source based consulting work centered around > > dojo/tapestry/tacos/hivemind. > > > > > > > -- > 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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Jesse Kuhnert Tacos/Tapestry, team member/developer Open source based consulting work centered around dojo/tapestry/tacos/hivemind.
-- 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
