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.
