Of course there are many good counterarguments to this. There are already a lot of methods in Component, you can do this without any changes and it may be confusing to have a concept of hidden on top of the existing visible concept.
Jonathan Locke wrote: > > > 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-tp17285530p17287068.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]
