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.
