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 <[EMAIL PROTECTED]> wrote:
Go ahead!
On 11/9/07, Sebastiaan van Erk <
i think sebastian is over his jira quota for today.
On Nov 9, 2007 2:47 PM, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
> Go ahead!
>
> On 11/9/07, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote:
> > It seems a JIRA issue was not made for this discussion. I wouldn't want
> > this to be forgotten
Go ahead!
On 11/9/07, Sebastiaan van Erk <[EMAIL PROTECTED]> 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
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 b
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
isenabled
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 <[EMAIL PROTECTED]> wrote:
>
> security is bypassed anyways because most
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 <[EMAIL PROTECTED]> wrote:
> >
> >
> > for visibility it is currently: isVisible()&&isRenderAllowed() which
> > makes little sense to me
>
>
> 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
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:
visibili
this will make it hugely inconsistent with how isenabled()
isenabledallowed() works.
-igor
On 11/2/07, Johan Compagner <[EMAIL PROTECTED]> 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
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 lin
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 th
>
> 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
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 reason
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 <[EMAIL PROTECTED]> wrote:
> On 11/1/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> > if we rename it then we should also rename Component.RENDER
On Nov 2, 2007 3:26 AM, Igor Vaynberg <[EMAIL PROTECTED]> 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,
On 11/1/07, Igor Vaynberg <[EMAIL PROTECTED]> 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 unsub
if we rename it then we should also rename Component.RENDER action to
Component.VISIBLE
-igor
On 11/1/07, Johan Compagner <[EMAIL PROTECTED]> 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,
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 <[EMAIL PROTECTED]> wrote:
> yes, but you see how we have two co
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
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
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 Marr
stupid extra linefeeds or carriage returns...
How can you get rid of them when copy pasting.
On 11/1/07, Johan Compagner <[EMAIL PROTECTED]> wrote:
>
> so now it calls isVisible?
> so just call isVisibleInHierarchy()
>
> so instead of this:
> *
>
> else
> **if* (childComponent != *null*)
>
> {
>
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
setVis
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 <[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 "re
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 thin
On 10/31/07, 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?
Yeah.
E
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 <[EMAIL PROTECTED]> wrote:
> H
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 y
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, Sebas
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");
a
31 matches
Mail list logo
