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]
