You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Jesse Kuhnert <jk...@gmail.com> on 2006/07/31 18:29:40 UTC
changes to abstract component (mostly for Howard)
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.
Re: changes to abstract component (mostly for Howard)
Posted by "karthik.nar" <ka...@gmail.com>.
Hi Robert,
We are looking at implementing the exact same thing for our security
concerns.
Can you please, please, please share your code?!!!
Much obliged,
Karthik.
Robert Binna-2 wrote:
>
> That's exactly what I have implemented.
>
> For that case I implemented an EnhancementWorker that overrides the
> RenderComponent method and adds a stack that tracks the whole rendering
> process.
> The stack is stored in the RequestCycle.
>
> I used it for sofisticated security decisions during rendering. The
> security adds declarative security based on method bindings, with the
> benefit that you can develop pages like you are used to and adding
> security constraints later on.
>
> But my problem is that I render twice. First time to get the
> RenderingHierarchy and doing security based decisions (eg. removing
> components that are not allowed for the current user/context) and the
> second time to render the output.
>
> Because the FormSupport is not aware of my mechanism some hidden fields
> are rendered twice. Has anyone an idea how I can get arround it?
>
> @Howard @Jessie: I would like to contribute my security code
>
> Kind regards,
> Robert
>
>
--
View this message in context: http://www.nabble.com/changes-to-abstract-component-%28mostly-for-Howard%29-tf2028605.html#a7316790
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: changes to abstract component (mostly for Howard)
Posted by Jesse Kuhnert <jk...@gmail.com>.
Hi Robert,
Finally noticed your reply now that I dug up this message to remember what
Howards thoughts were on this.
We love contributions ! I'm not sure how you want to go about it, but I'm
thinking this is a definite contrib sort of thing. We'd probably also want
to see if there is any cross-over relevance to what you are doing and the
ever popular acegi .
Either way I'm about to check in the render stack via IRequestCycle changes
in a little while. (Once I fix the unit tests.)
On 8/1/06, Robert Binna <r....@synedra.com> wrote:
>
> That's exactly what I have implemented.
>
> For that case I implemented an EnhancementWorker that overrides the
> RenderComponent method and adds a stack that tracks the whole rendering
> process.
> The stack is stored in the RequestCycle.
>
> I used it for sofisticated security decisions during rendering. The
> security adds declarative security based on method bindings, with the
> benefit that you can develop pages like you are used to and adding
> security constraints later on.
>
> But my problem is that I render twice. First time to get the
> RenderingHierarchy and doing security based decisions (eg. removing
> components that are not allowed for the current user/context) and the
> second time to render the output.
>
> Because the FormSupport is not aware of my mechanism some hidden fields
> are rendered twice. Has anyone an idea how I can get arround it?
>
> @Howard @Jessie: I would like to contribute my security code
>
> Kind regards,
> Robert
>
>
>
> My Problem is that
>
> Jesse Kuhnert schrieb:
>
> > Ok, I like that solution :) Much better than what I came up with. heh
> >
> > I noticed a side effect of your proposed method would also start to
> > pave the
> > way towards making direct (or as much direct as possible) component
> > renders
> > possible.
> >
> > On 7/31/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> >
> >>
> >> 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 <jk...@gmail.com> 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 <hl...@gmail.com> 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 <jk...@gmail.com> 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 <hl...@gmail.com> 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 <jk...@gmail.com> 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="any@Any">
> >> > > > > > <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 <hl...@gmail.com> 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 <jk...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> >> > > > > > > For additional commands, e-mail:
> >> dev-help@tapestry.apache.org
> >> > > > > > >
> >> > > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > --
> >> > > > > > 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: dev-unsubscribe@tapestry.apache.org
> >> > > > > For additional commands, e-mail: dev-help@tapestry.apache.org
> >> > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > 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: dev-unsubscribe@tapestry.apache.org
> >> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> >> > >
> >> > >
> >> >
> >> >
> >> > --
> >> > 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: dev-unsubscribe@tapestry.apache.org
> >> For additional commands, e-mail: dev-help@tapestry.apache.org
> >>
> >>
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
Re: changes to abstract component (mostly for Howard)
Posted by Robert Binna <r....@synedra.com>.
That's exactly what I have implemented.
For that case I implemented an EnhancementWorker that overrides the
RenderComponent method and adds a stack that tracks the whole rendering
process.
The stack is stored in the RequestCycle.
I used it for sofisticated security decisions during rendering. The
security adds declarative security based on method bindings, with the
benefit that you can develop pages like you are used to and adding
security constraints later on.
But my problem is that I render twice. First time to get the
RenderingHierarchy and doing security based decisions (eg. removing
components that are not allowed for the current user/context) and the
second time to render the output.
Because the FormSupport is not aware of my mechanism some hidden fields
are rendered twice. Has anyone an idea how I can get arround it?
@Howard @Jessie: I would like to contribute my security code
Kind regards,
Robert
My Problem is that
Jesse Kuhnert schrieb:
> Ok, I like that solution :) Much better than what I came up with. heh
>
> I noticed a side effect of your proposed method would also start to
> pave the
> way towards making direct (or as much direct as possible) component
> renders
> possible.
>
> On 7/31/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>
>>
>> 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 <jk...@gmail.com> 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 <hl...@gmail.com> 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 <jk...@gmail.com> 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 <hl...@gmail.com> 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 <jk...@gmail.com> 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="any@Any">
>> > > > > > <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 <hl...@gmail.com> 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 <jk...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
>> > > > > > > For additional commands, e-mail:
>> dev-help@tapestry.apache.org
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > 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: dev-unsubscribe@tapestry.apache.org
>> > > > > For additional commands, e-mail: dev-help@tapestry.apache.org
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > 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: dev-unsubscribe@tapestry.apache.org
>> > > For additional commands, e-mail: dev-help@tapestry.apache.org
>> > >
>> > >
>> >
>> >
>> > --
>> > 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: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: changes to abstract component (mostly for Howard)
Posted by Jesse Kuhnert <jk...@gmail.com>.
Ok, I like that solution :) Much better than what I came up with. heh
I noticed a side effect of your proposed method would also start to pave the
way towards making direct (or as much direct as possible) component renders
possible.
On 7/31/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> 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 <jk...@gmail.com> 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 <hl...@gmail.com> 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 <jk...@gmail.com> 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 <hl...@gmail.com> 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 <jk...@gmail.com> 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="any@Any">
> > > > > > <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 <hl...@gmail.com> 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 <jk...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> > > > > > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 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: dev-unsubscribe@tapestry.apache.org
> > > > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > 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: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> >
> > --
> > 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
Re: changes to abstract component (mostly for Howard)
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <jk...@gmail.com> 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 <hl...@gmail.com> 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 <jk...@gmail.com> 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 <hl...@gmail.com> 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 <jk...@gmail.com> 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="any@Any">
> > > > > <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 <hl...@gmail.com> 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 <jk...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> > > > > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > 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: dev-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > 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: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: changes to abstract component (mostly for Howard)
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <hl...@gmail.com> 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 <jk...@gmail.com> 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 <hl...@gmail.com> 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 <jk...@gmail.com> 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="any@Any">
> > > > <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 <hl...@gmail.com> 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 <jk...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> > > > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > 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: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> >
> > --
> > 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
Re: changes to abstract component (mostly for Howard)
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <jk...@gmail.com> 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 <hl...@gmail.com> 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 <jk...@gmail.com> 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="any@Any">
> > > <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 <hl...@gmail.com> 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 <jk...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> > > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > 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: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: changes to abstract component (mostly for Howard)
Posted by Jesse Kuhnert <jk...@gmail.com>.
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 <hl...@gmail.com> 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 <jk...@gmail.com> 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="any@Any">
> > <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 <hl...@gmail.com> 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 <jk...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: dev-help@tapestry.apache.org
> > >
> > >
> >
> >
> > --
> > 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
Re: changes to abstract component (mostly for Howard)
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <jk...@gmail.com> 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="any@Any">
> <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 <hl...@gmail.com> 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 <jk...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: dev-help@tapestry.apache.org
> >
> >
>
>
> --
> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: changes to abstract component (mostly for Howard)
Posted by Jesse Kuhnert <jk...@gmail.com>.
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="any@Any">
<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 <hl...@gmail.com> 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 <jk...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
--
Jesse Kuhnert
Tacos/Tapestry, team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
Re: changes to abstract component (mostly for Howard)
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <jk...@gmail.com> 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: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: changes to abstract component (mostly for Howard)
Posted by Robert Binna <r....@synedra.com>.
Yes there seems to be an overlap, but as far as I have seen there is no
mechanism for conditionally setting parts of the invisble according to
security rules
or do I get it wrong?
For the case that this is not implemented I sugest, a small base part
that can be used by any security framework (but not only by security
frameworks)). This would also
allow tapestry-acegi to add a small handler for the @Secured annotations
and the gui could be more dynamic to the permissions of a user.
For deciding how large the overlaps are I will have to take a closer
look at ACEGI.
Robert
D&J Gredler schrieb:
> I don't know what overlap there is, if any, but you guys may want to make
> sure you check out James' tapestry-acegi project (
> http://www.carmanconsulting.com/tapestry-acegi/) to make sure there's no
> reinventing of the wheel going on.
>
> On 11/13/06, Robert Binna <r....@synedra.com> wrote:
>>
>> Hi.
>>
>> My original mail, is a bit older and the solution with the request
>> cycle, like you did it, seems to fit perfectly.
>> According to rendering twice, I had to drop this idea because of too
>> many dangerous sideffects, like you said.
>> At the moment I solved it with specifing a dependent component
>> explicitly, but hopefully with tapestry 5
>> and dom support this should be no problem?
>>
>> According to security code: Is it of interest to move some basics of it
>> inside of tapestry 4.1 together with an advanced prop
>> Binding that make it easy to add own Handlers to react on Annotations on
>> accessors/mutators/listenerMethods (via hivemind)?
>> And then the security framework itself could be opened as a seperate
>> project like bean-form, or inside of tapestry depending on what is
>> preferred? Any suggestions are welcome.
>>
>> @Kathik for sure I want to share it, I can tell you more on wednesday
>> when I am back at office, and I have checked
>> the details.
>>
>> kind regards,
>> Robert
>>
>>
>> Jesse Kuhnert schrieb:
>> > Was this really sent 6 hours ago? Maybe gmail had a hiccup.
>> >
>> > I think the end resolution on this one was to use a render stack
>> within
>> > IRequestCycle (as per your suggestion).
>> >
>> > On 11/13/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>> >>
>> >> This has been suggested in the past and I think it is dangerous.
>> >>
>> >> I would rather that the Script component left a token inside the
>> >> IRequestCycle (as an attribute) that the IScript instance could check
>> >> for.
>> >>
>> >> On 7/31/06, Jesse Kuhnert <jk...@gmail.com> 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.
>> >> <snipped>
>> >>
>> >
>> >
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: dev-help@tapestry.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: changes to abstract component (mostly for Howard)
Posted by D&J Gredler <dj...@gmail.com>.
I don't know what overlap there is, if any, but you guys may want to make
sure you check out James' tapestry-acegi project (
http://www.carmanconsulting.com/tapestry-acegi/) to make sure there's no
reinventing of the wheel going on.
On 11/13/06, Robert Binna <r....@synedra.com> wrote:
>
> Hi.
>
> My original mail, is a bit older and the solution with the request
> cycle, like you did it, seems to fit perfectly.
> According to rendering twice, I had to drop this idea because of too
> many dangerous sideffects, like you said.
> At the moment I solved it with specifing a dependent component
> explicitly, but hopefully with tapestry 5
> and dom support this should be no problem?
>
> According to security code: Is it of interest to move some basics of it
> inside of tapestry 4.1 together with an advanced prop
> Binding that make it easy to add own Handlers to react on Annotations on
> accessors/mutators/listenerMethods (via hivemind)?
> And then the security framework itself could be opened as a seperate
> project like bean-form, or inside of tapestry depending on what is
> preferred? Any suggestions are welcome.
>
> @Kathik for sure I want to share it, I can tell you more on wednesday
> when I am back at office, and I have checked
> the details.
>
> kind regards,
> Robert
>
>
> Jesse Kuhnert schrieb:
> > Was this really sent 6 hours ago? Maybe gmail had a hiccup.
> >
> > I think the end resolution on this one was to use a render stack within
> > IRequestCycle (as per your suggestion).
> >
> > On 11/13/06, Howard Lewis Ship <hl...@gmail.com> wrote:
> >>
> >> This has been suggested in the past and I think it is dangerous.
> >>
> >> I would rather that the Script component left a token inside the
> >> IRequestCycle (as an attribute) that the IScript instance could check
> >> for.
> >>
> >> On 7/31/06, Jesse Kuhnert <jk...@gmail.com> 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.
> >> <snipped>
> >>
> >
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
>
Re: changes to abstract component (mostly for Howard)
Posted by Robert Binna <r....@synedra.com>.
Hi.
My original mail, is a bit older and the solution with the request
cycle, like you did it, seems to fit perfectly.
According to rendering twice, I had to drop this idea because of too
many dangerous sideffects, like you said.
At the moment I solved it with specifing a dependent component
explicitly, but hopefully with tapestry 5
and dom support this should be no problem?
According to security code: Is it of interest to move some basics of it
inside of tapestry 4.1 together with an advanced prop
Binding that make it easy to add own Handlers to react on Annotations on
accessors/mutators/listenerMethods (via hivemind)?
And then the security framework itself could be opened as a seperate
project like bean-form, or inside of tapestry depending on what is
preferred? Any suggestions are welcome.
@Kathik for sure I want to share it, I can tell you more on wednesday
when I am back at office, and I have checked
the details.
kind regards,
Robert
Jesse Kuhnert schrieb:
> Was this really sent 6 hours ago? Maybe gmail had a hiccup.
>
> I think the end resolution on this one was to use a render stack within
> IRequestCycle (as per your suggestion).
>
> On 11/13/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>>
>> This has been suggested in the past and I think it is dangerous.
>>
>> I would rather that the Script component left a token inside the
>> IRequestCycle (as an attribute) that the IScript instance could check
>> for.
>>
>> On 7/31/06, Jesse Kuhnert <jk...@gmail.com> 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.
>> <snipped>
>>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: changes to abstract component (mostly for Howard)
Posted by Jesse Kuhnert <jk...@gmail.com>.
Was this really sent 6 hours ago? Maybe gmail had a hiccup.
I think the end resolution on this one was to use a render stack within
IRequestCycle (as per your suggestion).
On 11/13/06, Howard Lewis Ship <hl...@gmail.com> wrote:
>
> This has been suggested in the past and I think it is dangerous.
>
> I would rather that the Script component left a token inside the
> IRequestCycle (as an attribute) that the IScript instance could check for.
>
> On 7/31/06, Jesse Kuhnert <jk...@gmail.com> 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.
> <snipped>
>
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
Re: changes to abstract component (mostly for Howard)
Posted by Howard Lewis Ship <hl...@gmail.com>.
This has been suggested in the past and I think it is dangerous.
I would rather that the Script component left a token inside the
IRequestCycle (as an attribute) that the IScript instance could check for.
On 7/31/06, Jesse Kuhnert <jk...@gmail.com> 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