Many people expect that is the component is not visible also the models and the data ias not called or touched. Because there state cant be resolved correctly. Als security is depending on it, it can never be that some thing where security says it is not visible/cant render that is still renders data, this would be a major security hole.
On 5/17/08, Kirk Israel <[EMAIL PROTECTED]> 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
