+1 for an additional flag. then we have 3 things to check: isvisible,
isrenderallowed, isthisnewflagwhatchamajjigit

i still say we should have one method that does this check on
component that is public instead of only doing the proper check in
isvisibleinhierarchy()

-igor


On Thu, Mar 27, 2008 at 12:23 PM, Johan Compagner <[EMAIL PROTECTED]> wrote:
> making isVisible final will break many things thats not really an option
>  But isVisible is just what it is.. It controls the state if the component
>  has to render itself..
>  Whats so strange about that.
>
>  Of course we could introduce yet another flag so that we have 3 of them that
>  defines if the component can be rendered or not
>
>  isVisible is more or less the user/developers property
>  isRenderedAllowed is security
>
>  so yes using those is not really nice.
>
>  johan
>
>
>  On Thu, Mar 27, 2008 at 8:16 PM, Bruno Borges <[EMAIL PROTECTED]>
>  wrote:
>
>
>
>  > Yeah Igor... I think isVisible should *not* be considered as an option to
>  > control wether a componet is going to be displayed or not. This method
>  > should only present if a component *is* visible or *is not*. This means:
>  > isVisible tells the current component's state.
>  >
>  > To fix this:
>  >
>  > - make isVisible final
>  > - introduce another method (e.g. isRenderAllowed)
>  > or
>  > - let isVisible ovewritable
>  > - introduce another method (e.g. isRendered)
>  >
>  > Both options have their advantagens and disadvantages.
>  >
>  > On Thu, Mar 27, 2008 at 2:20 PM, Igor Vaynberg <[EMAIL PROTECTED]>
>  > wrote:
>  >
>  > > well, the problem here is a bit more complicated.
>  > >
>  > > what if the user overrides isivisible. i think what we want here is
>  > > another flag, kind of like isrenderallowed, but something that we can
>  > > push...thoughts?
>  > >
>  > > -igor
>  > >
>  > >
>  > > On Thu, Mar 27, 2008 at 8:47 AM, Johan Compagner <[EMAIL PROTECTED]>
>  > > wrote:
>  > > > the problem with setVisible is that it is a version change..
>  > > >  So if we disable that quickly before changing the variable then its
>  > > fine by
>  > > >  me to change that
>  > > >  That can be default behavior by the way if you ask me
>  > > >
>  > > >  component.setVersioned(false)
>  > > >  component.doWhatYouWant()
>  > > >  component.setVersioned(true)
>  > > >
>  > > >
>  > > >  johan
>  > > >
>  > > >
>  > > >  On Thu, Mar 27, 2008 at 9:05 AM, Igor Vaynberg <
>  > [EMAIL PROTECTED]
>  > > >
>  > > >
>  > > >
>  > > > wrote:
>  > > >
>  > > >  > i guess all this nastiness stems from the facts that we resolve
>  > > >  > enclosures at render time and at that time we restrict calls to
>  > > >  > setvisible() because we consider it a hierarchy change.
>  > > >  >
>  > > >  > if we relax that at least for isvisible() calls then inside the
>  > > >  > enclosureresolver all we have to do is iterate over its direct
>  > > >  > children and call setvisible(false) on them if enclosure is hidden.
>  > > >  >
>  > > >  > -igor
>  > > >  >
>  > > >  >
>  > > >  > On Thu, Mar 27, 2008 at 12:43 AM, Igor Vaynberg <
>  > > [EMAIL PROTECTED]>
>  > > >  > wrote:
>  > > >  > > ive just attached a draft patch to WICKET-1391. its kinda hacky,
>  > so
>  > > i
>  > > >  > >  want to see if anyone can come up with a more elegant way to do
>  > > this.
>  > > >  > >
>  > > >  > >  -igor
>  > > >  > >
>  > > >  >
>  > > >
>  > >
>  >
>  >
>  >
>  > --
>  > Bruno Borges
>  > blog.brunoborges.com.br
>  > +55 1185657739
>  >
>  > "The glory of great men should always be
>  > measured by the means they have used to
>  > acquire it."
>  > - Francois de La Rochefoucauld
>  >
>

Reply via email to