I'm always a little careful about introducing new properties into
components.
What's really needed is a way to track the render stack: what
components are actively rendering.
How about this:
IRequestCycle adds methods to track a stack of rendering objects.
Add methods to IRequestCycle to push, pop and query the stack.
Change AbstractComponent.render() to push (before renderComponent() )
and pop (in the finally block) the stack.
This gives you a rich amount of information, is relatively cheap at
runtime, and doesn't introduce new properties into the base component
classes.
On 7/31/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
> 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.
>
>
--
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]
