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