by the way, don't forget that behaviors are reusable components too. there can be advantages to encapsulating your hiding/showing logic in a behavior. this can actually lead to less of this manual manipulation you're talking about than the solution you seem to want. and because the logic is encapsulated, it can work like a mix-in work where components don't need to be aware of how they are being hidden and shown. this kind of decoupling can actually be a big advantage for many problems over a simple set/isHidden approach, which ties the component's visibility to logic embedded in the component. i would step back and think about how you might use behaviors here before jumping to conclusions.
Jonathan Locke wrote: > > 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-tp17285530p17287367.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]
