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]

Reply via email to