Again, you probably shouldn't be setting state like this, and you can create a generic hiding behavior for now that should solve most of your problems. All that is at stake here is really just convenience, not the programming model.
On the other hand, this is a very common problem so it might be worth discussing adding a generic solution to component like set/isHidden(). The implementation would be slightly tricky and would require two more flag bits, but we could detect whether isHidden was overridden in component and delegate to some kind of singleton behavior. I haven't thought this through very far, but you should feel free to open a JIRA issue for this feature request. Kirk Israel-2 wrote: > > On Fri, May 16, 2008 at 7:34 PM, Eelco Hillenius > <[EMAIL PROTECTED]> wrote: >>> If you wanted to just a cosmetic, DHTM/CSS "display: none" type of >>> visibility, is there something you can do other than >>> making a new AttributeModifier (with a custom Visibility Model kind of >>> thing) or a SimplleAttributeModifier with a CSS >>> "display:none" String there? >> >> Well, if the component isn't visible (I typically override isVisible, >> because there's typically an algorithm that determines whether the >> component is visible), no rendering is done at all, which can save >> things like database roundtrips if that component or it's children use >> that, and it also often lets you avoid having to do null checks and >> stuff in your models (e.g. you can depend on a model function only to >> be executed when another object - the one that determines whether the >> component is visible - is checked). > > I'm still not comfortable with "is it visible" being mixed up with "is > it plain gone"... > Here was my scenario, I'll tell you my error, the fix, and then I'd > love to hear if there's a better way. > > Essentially we have a form where you can select countries, and we want > to offer two different views, a flat list collection of checkboxes for > all countries, and then a series of lists broken out by continent -- > two checkgroups w/ the same underlying model. For screen realestate > reasons, the CheckGroups live in scrollable Divs, and the Checks live > in a special ListView thing. So far so good. Then each of the > Continents has a little summary part, a textual description of what's > selected (the idea is the comma separated summary is always visible > vs. the checks which might be scrolled away, and the summary can be > clever and concise and say "ALL EUROPE except France, Spain") So - and > I know this is a little bit of an anti-pattern - as I built each > Continent I added the Summary label, and then kept a member variable > list of those around, and then had the checkboxes (whether on the flat > list or the by-continent list) call a function to add the summaries to > the Ajax request target. What I didn't realize, when I made the > by-continent view not visible and the flat list visible, and then > back, the Continents actually got regenerated, with new Summary > labels, and so the List was full of stale label referenes that barfed > when I tried to update them. > > I know it's not encouraged to keep member variables of page components > around, but I couldn't think of another way of getting to them... > > > The net-net is, it seems very odd to me that "merely" switching around > visibility should invalidate object references, that the complexity in > actually USING the visibility outweighs the "efficiency for free", and > I wish I had a simple "render this, but set its CSS visibility to > hidden" switch without having to go and manually modify attributes. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > -- View this message in context: http://www.nabble.com/Wicket-Visibility-vs.-CSS-visibility-tp17285530p17287030.html Sent from the Wicket - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
