You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Sebastiaan van Erk <se...@sebster.com> on 2007/10/31 21:18:23 UTC
wicket:enclosure and authorization
Hi,
I have a main menu with an admin link which only renders when the user
has the "ADMIN" role (MainMenu.java):
final BookmarkablePageLink adminLink = new
BookmarkablePageLink("adminLink", AdminHomePage.class);
MetaDataRoleAuthorizationStrategy.authorize(adminLink, RENDER, "ADMIN");
add(adminLink);
In my MainMenu.html I have:
<wicket:enclosure id="adminLink">
<li>
<a wicket:id="adminLink">Administratie</a>
</li>
</wicket:enclosure>
I was hoping that when the admin link is not rendered due to the user
not having the proper role, that the <li></li> would also not be
rendered, however, it does not seem to work this way...
Is this not the way I'm supposed to do this? Or should this work?
Otherwise, what is the right way to go about this?
Thanks in advance,
Sebastiaan
Re: wicket:enclosure and authorization
Posted by Sebastiaan van Erk <se...@sebster.com>.
Johan Compagner wrote:
> i think sebastian is over his jira quota for today.
hehe :-) sorry 'bout that!
BTW, nice localizer... it even localizes my name! ;-)
Regards,
Sebastiaan
>
>
> On Nov 9, 2007 2:47 PM, Martijn Dashorst <ma...@gmail.com> wrote:
>
>> Go ahead!
>>
>> On 11/9/07, Sebastiaan van Erk <se...@sebster.com> wrote:
>>> It seems a JIRA issue was not made for this discussion. I wouldn't want
>>> this to be forgotten about, so should I create one?
>>>
>>> Regards,
>>> Sebastiaan
>>>
>>> Igor Vaynberg 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?
>>>>
>>>> -igor
>>>>
>>>>
>>>> On 10/31/07, Sebastiaan van Erk <se...@sebster.com> wrote:
>>>>> Hi,
>>>>>
>>>>> OK, figured it might be something like this!
>>>>> Thanks for the fast reply. :-)
>>>>>
>>>>> Regards,
>>>>> Sebastiaan
>>>>>
>>>>> Igor Vaynberg wrote:
>>>>>> enclosures work on the visibility level, not render level. since
>> your
>>>>>> adminlink is visible, but its rendering is aborted the enclosure
>> still
>>>>>> shows the content.
>>>>>>
>>>>>> to do this you have to put the link into a webmarkupcontainer, and
>>>>>> authorize that container instead of a link.
>>>>>>
>>>>>> -igor
>>>>>>
>>>>>>
>>>>>> On 10/31/07, Sebastiaan van Erk <se...@sebster.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have a main menu with an admin link which only renders when the
>> user
>>>>>>> has the "ADMIN" role (MainMenu.java):
>>>>>>>
>>>>>>> final BookmarkablePageLink adminLink = new
>>>>>>> BookmarkablePageLink("adminLink", AdminHomePage.class);
>>>>>>> MetaDataRoleAuthorizationStrategy.authorize(adminLink, RENDER,
>> "ADMIN");
>>>>>>> add(adminLink);
>>>>>>>
>>>>>>> In my MainMenu.html I have:
>>>>>>>
>>>>>>> <wicket:enclosure id="adminLink">
>>>>>>> <li>
>>>>>>> <a wicket:id="adminLink">Administratie</a>
>>>>>>> </li>
>>>>>>> </wicket:enclosure>
>>>>>>>
>>>>>>> I was hoping that when the admin link is not rendered due to the
>> user
>>>>>>> not having the proper role, that the <li></li> would also not be
>>>>>>> rendered, however, it does not seem to work this way...
>>>>>>>
>>>>>>> Is this not the way I'm supposed to do this? Or should this work?
>>>>>>> Otherwise, what is the right way to go about this?
>>>>>>>
>>>>>>> Thanks in advance,
>>>>>>> Sebastiaan
>>>>>>>
>>>>>>>
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>
>>
>> --
>> Buy Wicket in Action: http://manning.com/dashorst
>> Apache Wicket 1.3.0-beta4 is released
>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta4/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
Re: wicket:enclosure and authorization
Posted by Johan Compagner <jc...@gmail.com>.
i think sebastian is over his jira quota for today.
On Nov 9, 2007 2:47 PM, Martijn Dashorst <ma...@gmail.com> wrote:
> Go ahead!
>
> On 11/9/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> > It seems a JIRA issue was not made for this discussion. I wouldn't want
> > this to be forgotten about, so should I create one?
> >
> > Regards,
> > Sebastiaan
> >
> > Igor Vaynberg 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?
> > >
> > > -igor
> > >
> > >
> > > On 10/31/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> > >> Hi,
> > >>
> > >> OK, figured it might be something like this!
> > >> Thanks for the fast reply. :-)
> > >>
> > >> Regards,
> > >> Sebastiaan
> > >>
> > >> Igor Vaynberg wrote:
> > >>> enclosures work on the visibility level, not render level. since
> your
> > >>> adminlink is visible, but its rendering is aborted the enclosure
> still
> > >>> shows the content.
> > >>>
> > >>> to do this you have to put the link into a webmarkupcontainer, and
> > >>> authorize that container instead of a link.
> > >>>
> > >>> -igor
> > >>>
> > >>>
> > >>> On 10/31/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> > >>>> Hi,
> > >>>>
> > >>>> I have a main menu with an admin link which only renders when the
> user
> > >>>> has the "ADMIN" role (MainMenu.java):
> > >>>>
> > >>>> final BookmarkablePageLink adminLink = new
> > >>>> BookmarkablePageLink("adminLink", AdminHomePage.class);
> > >>>> MetaDataRoleAuthorizationStrategy.authorize(adminLink, RENDER,
> "ADMIN");
> > >>>> add(adminLink);
> > >>>>
> > >>>> In my MainMenu.html I have:
> > >>>>
> > >>>> <wicket:enclosure id="adminLink">
> > >>>> <li>
> > >>>> <a wicket:id="adminLink">Administratie</a>
> > >>>> </li>
> > >>>> </wicket:enclosure>
> > >>>>
> > >>>> I was hoping that when the admin link is not rendered due to the
> user
> > >>>> not having the proper role, that the <li></li> would also not be
> > >>>> rendered, however, it does not seem to work this way...
> > >>>>
> > >>>> Is this not the way I'm supposed to do this? Or should this work?
> > >>>> Otherwise, what is the right way to go about this?
> > >>>>
> > >>>> Thanks in advance,
> > >>>> Sebastiaan
> > >>>>
> > >>>>
> > >>>
> ---------------------------------------------------------------------
> > >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > >>> For additional commands, e-mail: users-help@wicket.apache.org
> > >>>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> >
> >
>
>
> --
> Buy Wicket in Action: http://manning.com/dashorst
> Apache Wicket 1.3.0-beta4 is released
> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta4/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: wicket:enclosure and authorization
Posted by Martijn Dashorst <ma...@gmail.com>.
Go ahead!
On 11/9/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> It seems a JIRA issue was not made for this discussion. I wouldn't want
> this to be forgotten about, so should I create one?
>
> Regards,
> Sebastiaan
>
> Igor Vaynberg 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?
> >
> > -igor
> >
> >
> > On 10/31/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> >> Hi,
> >>
> >> OK, figured it might be something like this!
> >> Thanks for the fast reply. :-)
> >>
> >> Regards,
> >> Sebastiaan
> >>
> >> Igor Vaynberg wrote:
> >>> enclosures work on the visibility level, not render level. since your
> >>> adminlink is visible, but its rendering is aborted the enclosure still
> >>> shows the content.
> >>>
> >>> to do this you have to put the link into a webmarkupcontainer, and
> >>> authorize that container instead of a link.
> >>>
> >>> -igor
> >>>
> >>>
> >>> On 10/31/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> >>>> Hi,
> >>>>
> >>>> I have a main menu with an admin link which only renders when the user
> >>>> has the "ADMIN" role (MainMenu.java):
> >>>>
> >>>> final BookmarkablePageLink adminLink = new
> >>>> BookmarkablePageLink("adminLink", AdminHomePage.class);
> >>>> MetaDataRoleAuthorizationStrategy.authorize(adminLink, RENDER, "ADMIN");
> >>>> add(adminLink);
> >>>>
> >>>> In my MainMenu.html I have:
> >>>>
> >>>> <wicket:enclosure id="adminLink">
> >>>> <li>
> >>>> <a wicket:id="adminLink">Administratie</a>
> >>>> </li>
> >>>> </wicket:enclosure>
> >>>>
> >>>> I was hoping that when the admin link is not rendered due to the user
> >>>> not having the proper role, that the <li></li> would also not be
> >>>> rendered, however, it does not seem to work this way...
> >>>>
> >>>> Is this not the way I'm supposed to do this? Or should this work?
> >>>> Otherwise, what is the right way to go about this?
> >>>>
> >>>> Thanks in advance,
> >>>> Sebastiaan
> >>>>
> >>>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> >>> For additional commands, e-mail: users-help@wicket.apache.org
> >>>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta4/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket:enclosure and authorization
Posted by Sebastiaan van Erk <se...@sebster.com>.
It seems a JIRA issue was not made for this discussion. I wouldn't want
this to be forgotten about, so should I create one?
Regards,
Sebastiaan
Igor Vaynberg 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?
>
> -igor
>
>
> On 10/31/07, Sebastiaan van Erk <se...@sebster.com> wrote:
>> Hi,
>>
>> OK, figured it might be something like this!
>> Thanks for the fast reply. :-)
>>
>> Regards,
>> Sebastiaan
>>
>> Igor Vaynberg wrote:
>>> enclosures work on the visibility level, not render level. since your
>>> adminlink is visible, but its rendering is aborted the enclosure still
>>> shows the content.
>>>
>>> to do this you have to put the link into a webmarkupcontainer, and
>>> authorize that container instead of a link.
>>>
>>> -igor
>>>
>>>
>>> On 10/31/07, Sebastiaan van Erk <se...@sebster.com> wrote:
>>>> Hi,
>>>>
>>>> I have a main menu with an admin link which only renders when the user
>>>> has the "ADMIN" role (MainMenu.java):
>>>>
>>>> final BookmarkablePageLink adminLink = new
>>>> BookmarkablePageLink("adminLink", AdminHomePage.class);
>>>> MetaDataRoleAuthorizationStrategy.authorize(adminLink, RENDER, "ADMIN");
>>>> add(adminLink);
>>>>
>>>> In my MainMenu.html I have:
>>>>
>>>> <wicket:enclosure id="adminLink">
>>>> <li>
>>>> <a wicket:id="adminLink">Administratie</a>
>>>> </li>
>>>> </wicket:enclosure>
>>>>
>>>> I was hoping that when the admin link is not rendered due to the user
>>>> not having the proper role, that the <li></li> would also not be
>>>> rendered, however, it does not seem to work this way...
>>>>
>>>> Is this not the way I'm supposed to do this? Or should this work?
>>>> Otherwise, what is the right way to go about this?
>>>>
>>>> Thanks in advance,
>>>> Sebastiaan
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: wicket:enclosure and authorization
Posted by Eelco Hillenius <ee...@gmail.com>.
On 10/31/07, Igor Vaynberg <ig...@gmail.com> 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?
Yeah.
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket:enclosure and authorization
Posted by Igor Vaynberg <ig...@gmail.com>.
yes, but we encourage our users to write COMPONENTS. so if i want my
component to do something different when it is not enabled i have to
do isEnabled()==false||isEnabledAllowed()==false to check for when the
component is disabled.
and my point was that a lot of our users prob forget the
isenabledallowed() check
-igor
On 11/4/07, Johan Compagner <jc...@gmail.com> wrote:
> But we as the framework don't forget it !
> If a developer overwrites isVisible() now
> then no mather what the developers returns if isRenderedAllowed() returns
> false then it won't be rendered.
>
> johan
>
>
> On 11/2/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > security is bypassed anyways because most component writers will
> > forget to do the double check. so neither solution is good.
> >
> > -igor
> >
> >
> > On 11/2/07, Johan Compagner <jc...@gmail.com> wrote:
> > > >
> > > >
> > > > for visibility it is currently: isVisible()&&isRenderAllowed() which
> > > > makes little sense to me because i have to deal with two concepts:
> > > > visibility and rendering. from my point of view as a user i dont care
> > > > to know about rendering, i just want to plop my components down and
> > > > tweak their visibility.
> > >
> > >
> > > so just introduce an extra final method on component that does just that
> > > check.
> > >
> > >
> > > when we first introduced this i argued to make isenabled() and
> > > > isvisible() include the is*allowed() checks, but i didnt win that one
> > > > back then...but thats another thread.
> > >
> > >
> > > no i still think thats a bad idea, because then isEnabled and isVisible
> > > must be both final i guess
> > > because then with simple isVisible override by some developer the
> > security
> > > is by passed.
> > >
> > > johan
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket:enclosure and authorization
Posted by Johan Compagner <jc...@gmail.com>.
But we as the framework don't forget it !
If a developer overwrites isVisible() now
then no mather what the developers returns if isRenderedAllowed() returns
false then it won't be rendered.
johan
On 11/2/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> security is bypassed anyways because most component writers will
> forget to do the double check. so neither solution is good.
>
> -igor
>
>
> On 11/2/07, Johan Compagner <jc...@gmail.com> wrote:
> > >
> > >
> > > for visibility it is currently: isVisible()&&isRenderAllowed() which
> > > makes little sense to me because i have to deal with two concepts:
> > > visibility and rendering. from my point of view as a user i dont care
> > > to know about rendering, i just want to plop my components down and
> > > tweak their visibility.
> >
> >
> > so just introduce an extra final method on component that does just that
> > check.
> >
> >
> > when we first introduced this i argued to make isenabled() and
> > > isvisible() include the is*allowed() checks, but i didnt win that one
> > > back then...but thats another thread.
> >
> >
> > no i still think thats a bad idea, because then isEnabled and isVisible
> > must be both final i guess
> > because then with simple isVisible override by some developer the
> security
> > is by passed.
> >
> > johan
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: wicket:enclosure and authorization
Posted by Igor Vaynberg <ig...@gmail.com>.
security is bypassed anyways because most component writers will
forget to do the double check. so neither solution is good.
-igor
On 11/2/07, Johan Compagner <jc...@gmail.com> wrote:
> >
> >
> > for visibility it is currently: isVisible()&&isRenderAllowed() which
> > makes little sense to me because i have to deal with two concepts:
> > visibility and rendering. from my point of view as a user i dont care
> > to know about rendering, i just want to plop my components down and
> > tweak their visibility.
>
>
> so just introduce an extra final method on component that does just that
> check.
>
>
> when we first introduced this i argued to make isenabled() and
> > isvisible() include the is*allowed() checks, but i didnt win that one
> > back then...but thats another thread.
>
>
> no i still think thats a bad idea, because then isEnabled and isVisible
> must be both final i guess
> because then with simple isVisible override by some developer the security
> is by passed.
>
> johan
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket:enclosure and authorization
Posted by Johan Compagner <jc...@gmail.com>.
>
>
> for visibility it is currently: isVisible()&&isRenderAllowed() which
> makes little sense to me because i have to deal with two concepts:
> visibility and rendering. from my point of view as a user i dont care
> to know about rendering, i just want to plop my components down and
> tweak their visibility.
so just introduce an extra final method on component that does just that
check.
when we first introduced this i argued to make isenabled() and
> isvisible() include the is*allowed() checks, but i didnt win that one
> back then...but thats another thread.
no i still think thats a bad idea, because then isEnabled and isVisible
must be both final i guess
because then with simple isVisible override by some developer the security
is by passed.
johan
Re: wicket:enclosure and authorization
Posted by Igor Vaynberg <ig...@gmail.com>.
this is how enabled works:
the actual outcome of whether something will end up being enabled or
not is the combination of isEnabled()&&isEnabledAllowed()
for visibility it is currently: isVisible()&&isRenderAllowed() which
makes little sense to me because i have to deal with two concepts:
visibility and rendering. from my point of view as a user i dont care
to know about rendering, i just want to plop my components down and
tweak their visibility.
when we first introduced this i argued to make isenabled() and
isvisible() include the is*allowed() checks, but i didnt win that one
back then...but thats another thread.
-igor
On 11/2/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> Johan Compagner wrote:
> >> 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:
> >>
> >> isVisible() means "is visible IF the component is allowed to render"
> >
> >
> > But the problem is that that line above is not true...
> > isVisible() only checks the visible property, it doesn't check if it is also
> > allowed to render.
>
> That's what I'm saying! I'm saying "isVisible()" does not really mean
> what the word "visible" means! That is, "visible" means I can see it
> (in ordinary English), but isVisible() means something else, namely what
> I wrote above (precisely BECAUSE it does not check isRenderAllowed())!
>
> In wicket if something isVisible() then it will be rendered, but if
> something is not rendered, you CANNOT conclude that isVisible().
> Therefore, there ARE 2 different concepts!
>
> But that's pretty much what you're saying in the rest of the mail, so I
> think we're agreeing... :-)
>
> Regards,
> Sebastiaan
>
> > we have such a method that does both thats isVisibleInHierarchy()
> > that checks everything. isVisible()/isRenderedAllowed() and all the parents
> > if they are both that.
> >
> > what is true in wicket is that:
> > Component not rendered then isVisible() or isRenderedAllowed() returned
> > false;
> >
> > (ofcourse you have 1 exception to this rule and the component doesn't has
> > markup at all, but thats another beast)
> >
> > johan
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket:enclosure and authorization
Posted by Igor Vaynberg <ig...@gmail.com>.
this will make it hugely inconsistent with how isenabled()
isenabledallowed() works.
-igor
On 11/2/07, Johan Compagner <jc...@gmail.com> wrote:
> By the way, Component.RENDER doesn't have to be renamed for me either.
> Maybe add one extra method to component:
>
> isVisibleAllowed() that checks both properties: isRenderedAllowed and
> isVisible()
> and that method is again called for every component in the hierachy in
> isVisibleInHiearchy()
>
> i think thats more clear.
>
> johan
>
>
>
> On 11/2/07, Johan Compagner <jc...@gmail.com> wrote:
> >
> > 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:
> > >
> > > isVisible() means "is visible IF the component is allowed to render"
> >
> >
> > But the problem is that that line above is not true...
> > isVisible() only checks the visible property, it doesn't check if it is
> > also allowed to render.
> >
> > we have such a method that does both thats isVisibleInHierarchy()
> > that checks everything. isVisible()/isRenderedAllowed() and all the
> > parents if they are both that.
> >
> > what is true in wicket is that:
> > Component not rendered then isVisible() or isRenderedAllowed() returned
> > false;
> >
> > (ofcourse you have 1 exception to this rule and the component doesn't has
> > markup at all, but thats another beast)
> >
> > johan
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket:enclosure and authorization
Posted by Sebastiaan van Erk <se...@sebster.com>.
Johan Compagner wrote:
>> 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:
>>
>> isVisible() means "is visible IF the component is allowed to render"
>
>
> But the problem is that that line above is not true...
> isVisible() only checks the visible property, it doesn't check if it is also
> allowed to render.
That's what I'm saying! I'm saying "isVisible()" does not really mean
what the word "visible" means! That is, "visible" means I can see it
(in ordinary English), but isVisible() means something else, namely what
I wrote above (precisely BECAUSE it does not check isRenderAllowed())!
In wicket if something isVisible() then it will be rendered, but if
something is not rendered, you CANNOT conclude that isVisible().
Therefore, there ARE 2 different concepts!
But that's pretty much what you're saying in the rest of the mail, so I
think we're agreeing... :-)
Regards,
Sebastiaan
> we have such a method that does both thats isVisibleInHierarchy()
> that checks everything. isVisible()/isRenderedAllowed() and all the parents
> if they are both that.
>
> what is true in wicket is that:
> Component not rendered then isVisible() or isRenderedAllowed() returned
> false;
>
> (ofcourse you have 1 exception to this rule and the component doesn't has
> markup at all, but thats another beast)
>
> johan
>
Re: wicket:enclosure and authorization
Posted by Johan Compagner <jc...@gmail.com>.
By the way, Component.RENDER doesn't have to be renamed for me either.
Maybe add one extra method to component:
isVisibleAllowed() that checks both properties: isRenderedAllowed and
isVisible()
and that method is again called for every component in the hierachy in
isVisibleInHiearchy()
i think thats more clear.
johan
On 11/2/07, Johan Compagner <jc...@gmail.com> wrote:
>
> 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:
> >
> > isVisible() means "is visible IF the component is allowed to render"
>
>
> But the problem is that that line above is not true...
> isVisible() only checks the visible property, it doesn't check if it is
> also allowed to render.
>
> we have such a method that does both thats isVisibleInHierarchy()
> that checks everything. isVisible()/isRenderedAllowed() and all the
> parents if they are both that.
>
> what is true in wicket is that:
> Component not rendered then isVisible() or isRenderedAllowed() returned
> false;
>
> (ofcourse you have 1 exception to this rule and the component doesn't has
> markup at all, but thats another beast)
>
> johan
>
>
Re: wicket:enclosure and authorization
Posted by Johan Compagner <jc...@gmail.com>.
>
> 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:
>
> isVisible() means "is visible IF the component is allowed to render"
But the problem is that that line above is not true...
isVisible() only checks the visible property, it doesn't check if it is also
allowed to render.
we have such a method that does both thats isVisibleInHierarchy()
that checks everything. isVisible()/isRenderedAllowed() and all the parents
if they are both that.
what is true in wicket is that:
Component not rendered then isVisible() or isRenderedAllowed() returned
false;
(ofcourse you have 1 exception to this rule and the component doesn't has
markup at all, but thats another beast)
johan
Re: wicket:enclosure and authorization
Posted by Sebastiaan van Erk <se...@sebster.com>.
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??
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:
isVisible() means "is visible IF the component is allowed to render"
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.
Regards,
Sebastiaan
> On 11/1/07, Igor Vaynberg <ig...@gmail.com> 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 <jc...@gmail.com> wrote:
>>> On 11/1/07, Igor Vaynberg <ig...@gmail.com> 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 <ma...@gmail.com> wrote:
>>>>> On Oct 31, 2007 9:58 PM, Igor Vaynberg <ig...@gmail.com>
>> 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: users-unsubscribe@wicket.apache.org
>>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>>>> For additional commands, e-mail: users-help@wicket.apache.org
>>>>
>>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: wicket:enclosure and authorization
Posted by Matej Knopp <ma...@gmail.com>.
I think this should wait after 1.3. And I'm not the one who's usually
hesitating what it comes to breaking stuff :)
-Matej
On 11/2/07, Eelco Hillenius <ee...@gmail.com> wrote:
> On 11/1/07, Igor Vaynberg <ig...@gmail.com> wrote:
> > if we rename it then we should also rename Component.RENDER action to
> > Component.VISIBLE
>
> Do you really think it is worth it renaming this late in the game?
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket:enclosure and authorization
Posted by Eelco Hillenius <ee...@gmail.com>.
On 11/1/07, Igor Vaynberg <ig...@gmail.com> wrote:
> if we rename it then we should also rename Component.RENDER action to
> Component.VISIBLE
Do you really think it is worth it renaming this late in the game?
Eelco
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket:enclosure and authorization
Posted by Maurice Marrink <ma...@gmail.com>.
On Nov 2, 2007 3:26 AM, Igor Vaynberg <ig...@gmail.com> wrote:
> if we rename it then we should also rename Component.RENDER action to
> Component.VISIBLE
Perhaps something for after 1.3 is released?
Maurice
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket:enclosure and authorization
Posted by Igor Vaynberg <ig...@gmail.com>.
if we rename it then we should also rename Component.RENDER action to
Component.VISIBLE
-igor
On 11/1/07, Johan Compagner <jc...@gmail.com> 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??
>
> On 11/1/07, Igor Vaynberg <ig...@gmail.com> 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 <jc...@gmail.com> wrote:
> > > On 11/1/07, Igor Vaynberg <ig...@gmail.com> 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 <ma...@gmail.com> wrote:
> > > > > On Oct 31, 2007 9:58 PM, Igor Vaynberg <ig...@gmail.com>
> > 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: users-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > > >
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket:enclosure and authorization
Posted by Johan Compagner <jc...@gmail.com>.
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??
On 11/1/07, Igor Vaynberg <ig...@gmail.com> 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 <jc...@gmail.com> wrote:
> > On 11/1/07, Igor Vaynberg <ig...@gmail.com> 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 <ma...@gmail.com> wrote:
> > > > On Oct 31, 2007 9:58 PM, Igor Vaynberg <ig...@gmail.com>
> 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: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket:enclosure and authorization
Posted by Igor Vaynberg <ig...@gmail.com>.
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 <jc...@gmail.com> wrote:
> On 11/1/07, Igor Vaynberg <ig...@gmail.com> 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 <ma...@gmail.com> wrote:
> > > On Oct 31, 2007 9:58 PM, Igor Vaynberg <ig...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket:enclosure and authorization
Posted by Johan Compagner <jc...@gmail.com>.
On 11/1/07, Igor Vaynberg <ig...@gmail.com> 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 <ma...@gmail.com> wrote:
> > On Oct 31, 2007 9:58 PM, Igor Vaynberg <ig...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: wicket:enclosure and authorization
Posted by Igor Vaynberg <ig...@gmail.com>.
i mean the action should be called VISIBLE instead of RENDER and we
should also have isVisibleAllowed() just like we have
isEnabled()/isEnabledAllowed()
makes more sense?
that way the check in enclosure is:
if (child.isvisible()&&child.isvisibleallowed()) { ...}
-igor
On 11/1/07, Maurice Marrink <ma...@gmail.com> wrote:
> On Oct 31, 2007 9:58 PM, Igor Vaynberg <ig...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket:enclosure and authorization
Posted by Matej Knopp <ma...@gmail.com>.
I'd say more like the enclosure should check is the component will
render rather than a simple isVisible check.
-Matej
On 11/1/07, Maurice Marrink <ma...@gmail.com> wrote:
> On Oct 31, 2007 9:58 PM, Igor Vaynberg <ig...@gmail.com> 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: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket:enclosure and authorization
Posted by Maurice Marrink <ma...@gmail.com>.
On Oct 31, 2007 9:58 PM, Igor Vaynberg <ig...@gmail.com> 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: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket:enclosure and authorization
Posted by Johan Compagner <jc...@gmail.com>.
stupid extra linefeeds or carriage returns...
How can you get rid of them when copy pasting.
On 11/1/07, Johan Compagner <jc...@gmail.com> wrote:
>
> so now it calls isVisible?
> so just call isVisibleInHierarchy()
>
> so instead of this:
> *
>
> else
> **if* (childComponent != *null*)
>
> {
>
> // Delegate to child component
>
> setVisible(
> childComponent.isVisible());
>
> }
>
> do this:
> *
>
> else
> **if* (childComponent != *null*)
>
> {
>
> // Delegate to child component
>
>
>
> setVisible(
> childComponent.*isVisibleInHierarchy*());
>
> }
> johan
>
>
>
> On 10/31/07, Igor Vaynberg <ig...@gmail.com> 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?
> >
> > -igor
> >
> >
> > On 10/31/07, Sebastiaan van Erk <sebster@sebster.com > wrote:
> > > Hi,
> > >
> > > OK, figured it might be something like this!
> > > Thanks for the fast reply. :-)
> > >
> > > Regards,
> > > Sebastiaan
> > >
> > > Igor Vaynberg wrote:
> > > > enclosures work on the visibility level, not render level. since
> > your
> > > > adminlink is visible, but its rendering is aborted the enclosure
> > still
> > > > shows the content.
> > > >
> > > > to do this you have to put the link into a webmarkupcontainer, and
> > > > authorize that container instead of a link.
> > > >
> > > > -igor
> > > >
> > > >
> > > > On 10/31/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> > > >> Hi,
> > > >>
> > > >> I have a main menu with an admin link which only renders when the
> > user
> > > >> has the "ADMIN" role (MainMenu.java):
> > > >>
> > > >> final BookmarkablePageLink adminLink = new
> > > >> BookmarkablePageLink("adminLink", AdminHomePage.class);
> > > >> MetaDataRoleAuthorizationStrategy.authorize(adminLink, RENDER,
> > "ADMIN");
> > > >> add(adminLink);
> > > >>
> > > >> In my MainMenu.html I have:
> > > >>
> > > >> <wicket:enclosure id="adminLink">
> > > >> <li>
> > > >> <a wicket:id="adminLink">Administratie</a>
> > > >> </li>
> > > >> </wicket:enclosure>
> > > >>
> > > >> I was hoping that when the admin link is not rendered due to the
> > user
> > > >> not having the proper role, that the <li></li> would also not be
> > > >> rendered, however, it does not seem to work this way...
> > > >>
> > > >> Is this not the way I'm supposed to do this? Or should this work?
> > > >> Otherwise, what is the right way to go about this?
> > > >>
> > > >> Thanks in advance,
> > > >> Sebastiaan
> > > >>
> > > >>
> > > >
> > > >
> > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
Re: wicket:enclosure and authorization
Posted by Johan Compagner <jc...@gmail.com>.
so now it calls isVisible?
so just call isVisibleInHierarchy()
so instead of this:
*
else* *if* (childComponent != *null*)
{
// Delegate to child component
setVisible(childComponent.isVisible());
}
do this:
*
else* *if* (childComponent != *null*)
{
// Delegate to child component
setVisible(childComponent.*isVisibleInHierarchy*());
}
johan
On 10/31/07, Igor Vaynberg <ig...@gmail.com> 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?
>
> -igor
>
>
> On 10/31/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> > Hi,
> >
> > OK, figured it might be something like this!
> > Thanks for the fast reply. :-)
> >
> > Regards,
> > Sebastiaan
> >
> > Igor Vaynberg wrote:
> > > enclosures work on the visibility level, not render level. since your
> > > adminlink is visible, but its rendering is aborted the enclosure still
> > > shows the content.
> > >
> > > to do this you have to put the link into a webmarkupcontainer, and
> > > authorize that container instead of a link.
> > >
> > > -igor
> > >
> > >
> > > On 10/31/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> > >> Hi,
> > >>
> > >> I have a main menu with an admin link which only renders when the
> user
> > >> has the "ADMIN" role (MainMenu.java):
> > >>
> > >> final BookmarkablePageLink adminLink = new
> > >> BookmarkablePageLink("adminLink", AdminHomePage.class);
> > >> MetaDataRoleAuthorizationStrategy.authorize(adminLink, RENDER,
> "ADMIN");
> > >> add(adminLink);
> > >>
> > >> In my MainMenu.html I have:
> > >>
> > >> <wicket:enclosure id="adminLink">
> > >> <li>
> > >> <a wicket:id="adminLink">Administratie</a>
> > >> </li>
> > >> </wicket:enclosure>
> > >>
> > >> I was hoping that when the admin link is not rendered due to the user
> > >> not having the proper role, that the <li></li> would also not be
> > >> rendered, however, it does not seem to work this way...
> > >>
> > >> Is this not the way I'm supposed to do this? Or should this work?
> > >> Otherwise, what is the right way to go about this?
> > >>
> > >> Thanks in advance,
> > >> Sebastiaan
> > >>
> > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
Re: wicket:enclosure and authorization
Posted by Igor Vaynberg <ig...@gmail.com>.
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?
-igor
On 10/31/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> Hi,
>
> OK, figured it might be something like this!
> Thanks for the fast reply. :-)
>
> Regards,
> Sebastiaan
>
> Igor Vaynberg wrote:
> > enclosures work on the visibility level, not render level. since your
> > adminlink is visible, but its rendering is aborted the enclosure still
> > shows the content.
> >
> > to do this you have to put the link into a webmarkupcontainer, and
> > authorize that container instead of a link.
> >
> > -igor
> >
> >
> > On 10/31/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> >> Hi,
> >>
> >> I have a main menu with an admin link which only renders when the user
> >> has the "ADMIN" role (MainMenu.java):
> >>
> >> final BookmarkablePageLink adminLink = new
> >> BookmarkablePageLink("adminLink", AdminHomePage.class);
> >> MetaDataRoleAuthorizationStrategy.authorize(adminLink, RENDER, "ADMIN");
> >> add(adminLink);
> >>
> >> In my MainMenu.html I have:
> >>
> >> <wicket:enclosure id="adminLink">
> >> <li>
> >> <a wicket:id="adminLink">Administratie</a>
> >> </li>
> >> </wicket:enclosure>
> >>
> >> I was hoping that when the admin link is not rendered due to the user
> >> not having the proper role, that the <li></li> would also not be
> >> rendered, however, it does not seem to work this way...
> >>
> >> Is this not the way I'm supposed to do this? Or should this work?
> >> Otherwise, what is the right way to go about this?
> >>
> >> Thanks in advance,
> >> Sebastiaan
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket:enclosure and authorization
Posted by Sebastiaan van Erk <se...@sebster.com>.
Hi,
OK, figured it might be something like this!
Thanks for the fast reply. :-)
Regards,
Sebastiaan
Igor Vaynberg wrote:
> enclosures work on the visibility level, not render level. since your
> adminlink is visible, but its rendering is aborted the enclosure still
> shows the content.
>
> to do this you have to put the link into a webmarkupcontainer, and
> authorize that container instead of a link.
>
> -igor
>
>
> On 10/31/07, Sebastiaan van Erk <se...@sebster.com> wrote:
>> Hi,
>>
>> I have a main menu with an admin link which only renders when the user
>> has the "ADMIN" role (MainMenu.java):
>>
>> final BookmarkablePageLink adminLink = new
>> BookmarkablePageLink("adminLink", AdminHomePage.class);
>> MetaDataRoleAuthorizationStrategy.authorize(adminLink, RENDER, "ADMIN");
>> add(adminLink);
>>
>> In my MainMenu.html I have:
>>
>> <wicket:enclosure id="adminLink">
>> <li>
>> <a wicket:id="adminLink">Administratie</a>
>> </li>
>> </wicket:enclosure>
>>
>> I was hoping that when the admin link is not rendered due to the user
>> not having the proper role, that the <li></li> would also not be
>> rendered, however, it does not seem to work this way...
>>
>> Is this not the way I'm supposed to do this? Or should this work?
>> Otherwise, what is the right way to go about this?
>>
>> Thanks in advance,
>> Sebastiaan
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
Re: wicket:enclosure and authorization
Posted by Igor Vaynberg <ig...@gmail.com>.
enclosures work on the visibility level, not render level. since your
adminlink is visible, but its rendering is aborted the enclosure still
shows the content.
to do this you have to put the link into a webmarkupcontainer, and
authorize that container instead of a link.
-igor
On 10/31/07, Sebastiaan van Erk <se...@sebster.com> wrote:
> Hi,
>
> I have a main menu with an admin link which only renders when the user
> has the "ADMIN" role (MainMenu.java):
>
> final BookmarkablePageLink adminLink = new
> BookmarkablePageLink("adminLink", AdminHomePage.class);
> MetaDataRoleAuthorizationStrategy.authorize(adminLink, RENDER, "ADMIN");
> add(adminLink);
>
> In my MainMenu.html I have:
>
> <wicket:enclosure id="adminLink">
> <li>
> <a wicket:id="adminLink">Administratie</a>
> </li>
> </wicket:enclosure>
>
> I was hoping that when the admin link is not rendered due to the user
> not having the proper role, that the <li></li> would also not be
> rendered, however, it does not seem to work this way...
>
> Is this not the way I'm supposed to do this? Or should this work?
> Otherwise, what is the right way to go about this?
>
> Thanks in advance,
> Sebastiaan
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org