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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
>> > Oh. That could be done, but I had originally thought that method
>> felt a
>> > little overly verbose for these things.
>> >
>> > With the current form people sometimes need to define an @Any
>> component
>> to
>> > encapsulate blocks to be updated, but there are plenty of scenerios
>> where
>> > they could just as easily specify an existing component as the
"block"
>> to
>> > update.
>> >
>> > I still think having to use special block components makes the API
>> feel
>> less
>> > "sexy"/intuitive to me, but if you really think so I can give it a
>> try.
>> >
>> > On 7/31/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
>> > >
>> > > I was hoping that you wouldn't need the parent property if you
>> require
>> > > the use of an AjaxBlock for this purpose. I suspect it may take a
>> > > little bit of retooling inside the partial rendering code.
>> > >
>> > > On 7/31/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
>> > > > That sounds perfectly reasonable to me. To summarize my
>> > > interpretations:
>> > > >
>> > > > -) Rename get/set Parent to something more descriptive of what
>> it's
>> > > doing,
>> > > > like encloser.
>> > > >
>> > > > -) Create and test some form of Block component that can properly
>> handle
>> > > the
>> > > > encloser semantics to ensure the logic works for all (known) use
>> cases.
>> > > >
>> > > > On 7/31/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
>> > > > >
>> > > > > So, parent would be "encloser".
>> > > > >
>> > > > > This works, to a point, but is limited in that if the body of
>> the
>> > > > > component being partially rendered renders a Block, the
>> components
>> in
>> > > > > the Block will not be "enclosed" by the target component.
>> > > > >
>> > > > > Could you have a special AjaxBlock compoonent that fills in
this
>> edge
>> > > > > case?
>> > > > >
>> > > > > Tapestry 1.0 had the notion of maintaining a stack of rendering
>> > > > > components. That idea will likely resurface, in another form,
in
>> T5.
>> > > > >
>> > > > > On 7/31/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
>> > > > > > It makes me nervous too. (another reason to want T5)
>> > > > > >
>> > > > > > My basic problem is that container doesn't return what I
want.
>> (in
>> > > the
>> > > > > way
>> > > > > > that I'm doing it) For instance, suppose I had the following
>> html
>> > > > > snippet:
>> > > > > >
>> > > > > > <div jwcid="[EMAIL PROTECTED]">
>> > > > > > <span jwcid="@If" condition="ognl:fooTrue()">
>> > > > > > Some textual content
>> > > > > > <span jwcid="@Script" scriptPath="Sample.script" />
>> > > > > > </span>
>> > > > > > </div>
>> > > > > >
>> > > > > > In my "ajax" logic someone might say that they want the
>> component
>> > > with
>> > > > > id
>> > > > > > "any" to be updated (have its IMarkupWriter content
>> captured and
>> > > sent
>> > > > > back
>> > > > > > to browser via XHR, but nothing else) in a request.
>> > > > > >
>> > > > > > The most intuitive thing to do (which is what tacos
>> tries/attempted
>> > > to
>> > > > > do )
>> > > > > > in this situation is to not only update the content of the
>> "any"
>> > > > > component,
>> > > > > > but also any component it contains.
>> > > > > >
>> > > > > > Now my logic is such that I look at each component render
>> > > individually.
>> > > > > When
>> > > > > > I get to the embedded Script component referenced above I
need
>> to
>> > > check
>> > > > > and
>> > > > > > see if it should get a valid IMarkupWriter. Calling
>> getContainer()
>> > > will
>> > > > > > return the Page/Body in this instance, not the "any"
>> component.
>> > > > > >
>> > > > > > This makes sense when dealing with ognl/template semantics,
>> but
>> not
>> > > in
>> > > > > the
>> > > > > > sense of knowing who contains you in the context of html
>> blocks.
>> > > > > >
>> > > > > > The most obvious thing to do was set a temporary "parent"
when
>> > > adding an
>> > > > > > IRender to a components Body.
>> > > > > >
>> > > > > > I didn't want these methods exposed to the public IComponent
>> API,
>> > > but
>> > > > > don't
>> > > > > > currently know of a better way to do it. (that doesn't
involve
>> > > javassist
>> > > > > > enhancements)
>> > > > > >
>> > > > > > What are your thoughts in the context of what I just went
>> over?
>> Is
>> > > it a
>> > > > > > matter of whether or not we want this kind of logic exposed
to
>> the
>> > > > > public
>> > > > > > API's or just the logic itself in general?
>> > > > > >
>> > > > > > On 7/31/06, Howard Lewis Ship <[EMAIL PROTECTED]> wrote:
>> > > > > > >
>> > > > > > > This makes me nervous. I don't understand how parent
>> would be
>> > > > > > > different from container (and existing, rigid, structural
>> > > property).
>> > > > > > >
>> > > > > > >
>> > > > > > > On 7/31/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
>> > > > > > > > I've run into a situation with @Script where I need to be
>> able
>> > > to
>> > > > > limit
>> > > > > > > > script output in dynamic responses. The only problem
with
>> > > @Script
>> > > > > > > templates
>> > > > > > > > (for this scenerio) is that the render logic doesn't
>> really
>> > > happen
>> > > > > in
>> > > > > > > the
>> > > > > > > > same way that component renders work.
>> > > > > > > >
>> > > > > > > > Right now if I pass a valid writer to one component any
>> IRender
>> > > body
>> > > > > > > > instances it contains will automatically have their
>> content
>> > > output
>> > > > > as
>> > > > > > > well.
>> > > > > > > > (as is the preferred case for my usage)
>> > > > > > > >
>> > > > > > > > There is no IWriter to look at (as far as having
>> context to
>> a
>> > > parent
>> > > > > > > > component) by the time we're at the point of actually
>> writing
>> > > some
>> > > > > of
>> > > > > > > the
>> > > > > > > > javascript output.
>> > > > > > > >
>> > > > > > > > The best solution I've come up with is adding two
>> methods to
>> > > > > IComponent.
>> > > > > > > > setParent(IComponent)/getParent(). This allows me to
>> walk up
>> the
>> > > > > current
>> > > > > > > > heirarchy and determine if the component (Script
component
>> in
>> > > this
>> > > > > > > instance)
>> > > > > > > > is contained by a component that ~has~ been requested to
>> have
>> > > its
>> > > > > > > content
>> > > > > > > > dynamically updated.
>> > > > > > > >
>> > > > > > > > I can't find any scenerio in the current codebase where
>> this
>> > > would
>> > > > > be an
>> > > > > > > > issue, but then again I don't know all the various ways
>> people
>> > > do
>> > > > > things
>> > > > > > > > with Tapestry so don't understand the potential problems
>> this
>> > > might
>> > > > > > > create.
>> > > > > > > >
>> > > > > > > > I might commit the change now (unless someone replies
back
>> > > > > soon-ish),
>> > > > > > > but
>> > > > > > > > will of course revert the change if requested.
>> > > > > > > >
>> > > > > > > > --
>> > > > > > > > Jesse Kuhnert
>> > > > > > > > Tacos/Tapestry, team member/developer
>> > > > > > > >
>> > > > > > > > Open source based consulting work centered around
>> > > > > > > > dojo/tapestry/tacos/hivemind.
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Howard M. Lewis Ship
>> > > > > > > TWD Consulting, Inc.
>> > > > > > > Independent J2EE / Open-Source Java Consultant
>> > > > > > > Creator and PMC Chair, Apache Tapestry
>> > > > > > > Creator, Apache HiveMind
>> > > > > > >
>> > > > > > > Professional Tapestry training, mentoring, support
>> > > > > > > and project work. http://howardlewisship.com
>> > > > > > >
>> > > > > > >
>> > >
>> ---------------------------------------------------------------------
>> > > > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > > > > > > For additional commands, e-mail:
>> [EMAIL PROTECTED]
>> > > > > > >
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Jesse Kuhnert
>> > > > > > Tacos/Tapestry, team member/developer
>> > > > > >
>> > > > > > Open source based consulting work centered around
>> > > > > > dojo/tapestry/tacos/hivemind.
>> > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Howard M. Lewis Ship
>> > > > > TWD Consulting, Inc.
>> > > > > Independent J2EE / Open-Source Java Consultant
>> > > > > Creator and PMC Chair, Apache Tapestry
>> > > > > Creator, Apache HiveMind
>> > > > >
>> > > > > Professional Tapestry training, mentoring, support
>> > > > > and project work. http://howardlewisship.com
>> > > > >
>> > > > >
>> ---------------------------------------------------------------------
>> > > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > > > > For additional commands, e-mail: [EMAIL PROTECTED]
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > Jesse Kuhnert
>> > > > Tacos/Tapestry, team member/developer
>> > > >
>> > > > Open source based consulting work centered around
>> > > > dojo/tapestry/tacos/hivemind.
>> > > >
>> > > >
>> > >
>> > >
>> > > --
>> > > Howard M. Lewis Ship
>> > > TWD Consulting, Inc.
>> > > Independent J2EE / Open-Source Java Consultant
>> > > Creator and PMC Chair, Apache Tapestry
>> > > Creator, Apache HiveMind
>> > >
>> > > Professional Tapestry training, mentoring, support
>> > > and project work. http://howardlewisship.com
>> > >
>> > >
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
>> > > For additional commands, e-mail: [EMAIL PROTECTED]
>> > >
>> > >
>> >
>> >
>> > --
>> > Jesse Kuhnert
>> > Tacos/Tapestry, team member/developer
>> >
>> > Open source based consulting work centered around
>> > dojo/tapestry/tacos/hivemind.
>> >
>> >
>>
>>
>> --
>> Howard M. Lewis Ship
>> TWD Consulting, Inc.
>> Independent J2EE / Open-Source Java Consultant
>> Creator and PMC Chair, Apache Tapestry
>> Creator, Apache HiveMind
>>
>> Professional Tapestry training, mentoring, support
>> and project work. http://howardlewisship.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Jesse Kuhnert
Tapestry/Dojo/(and a dash of TestNG), team member/developer
Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.
