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 <[EMAIL PROTECTED]> 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 <[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.
<snipped>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
