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]