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.
