Re: wicket:enclosure and authorization

[Sebastiaan van Erk]

Just some thoughts I have on the issue...

Johan Compagner wrote:

they are not really 2 concepts, if something is not visible then it
wont be rendered or if something is not rendered then it is not
visible, so  isRenderedAllowed() is just isVisibleAllowed(), So rename
it??

isVisible() means "is visible IF the component is allowed to render"







Regards,
Sebastiaan

Note that your reasoning is not quite correct above: while it IS true that "if something is not visible then it won't be rendered", it IS NOT true that "if something is not rendered then it is not visible". The problem is that the you're confusing the name of the "visible" property with what it means, namely: If you rename the method isRenderAllowed() to isVisibleAllowed() and add the isVisibleAllowed() check to the enclosure check, that still won't change what isVisible() really means (namely, what I wrote above). Note also that RENDER is an *action*, which is why I think it's kind of strange to rename Component.RENDER to Component.VISIBLE. Personally, I think the best solution is probably to just add the isRenderAllowed() to the enclosure check and do nothing else.

On 11/1/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:

yes, but you see how we have two concepts: visible and render, where
as we really only need one, i will tweak the enclosure and add
isrenderallowed check

-igor


On 11/1/07, Johan Compagner <[EMAIL PROTECTED]> wrote:

On 11/1/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:

i mean the action should be called VISIBLE instead of RENDER and we
should also have isVisibleAllowed() just like we have
isEnabled()/isEnabledAllowed()

thats just isRenderedAllowed() thats the same thing. Just different name
rename it if you want.


makes more sense?

that way the check in enclosure is:

if (child.isvisible()&&child.isvisibleallowed()) { ...}

and thats the same as child.isVisible() && child.isRenderedAllowed()
which is the same is child.isVisibleInHierarchy() (that only also walks

the

hierarchy)

johan


-igor

On 11/1/07, Maurice Marrink <[EMAIL PROTECTED]> wrote:

On Oct 31, 2007 9:58 PM, Igor Vaynberg <[EMAIL PROTECTED]>

wrote:

there seems to be a bit of a disconnect between "render" in auth and
our general component visibility concept. perhaps it might be an
improvement to aligh auth strategy with visibility rather then
render...what do others think?

What exactly do you mean by this? Do you want isVisible to also check
permission for the render action?

Maurice

---------------------------------------------------------------------
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]

---------------------------------------------------------------------
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]

smime.p7s
Description: S/MIME Cryptographic Signature