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]
