I think everybody is missing the point that listview was intended to refresh itself entirely (all the items) on each render not just after a hide/show cycle. The reason for this is that you always want an up-to-date list. If you don't want this this behavior you can use setReuseItems(true);
Or am i missing something? Maurice On Sat, May 17, 2008 at 2:28 PM, Kirk Israel <[EMAIL PROTECTED]> wrote: > On Sat, May 17, 2008 at 2:46 AM, Johan Compagner <[EMAIL PROTECTED]> wrote: >> 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. > > Still seems a little odd to me. "We're adding a component, but we're > counting on it not to do anything. Because it's not visible. So it's > not really there. But we put it there anyway!" > >> 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. > > OK, this is the first time I've started to hear a reasonable > explanations as to why visibility = absence might be useful -- to me > it seemed like a pain, with a fair chunk of boilerplate > (.setOutputMarkupId(true); and .setOutputMarkupPlaceholderTag(true);) > to get things to work correctly, and then unreliability as > expectations of a component being ready to go (and not redrawn) aren't > met. > > Part of it is, my main wicket experience hasn't depended on visibility > as "security"; the main app I've been working on doesn't have like a > "superuser" mode, permissions are mostly handled at the API layer and > everyone gets about the same view of every screen. (And if I *did* > have more user role based components on a single screen, I'd probably > consider using a base class, with one subclass being the functional > version for people with rights to see it, and one as a placeholder for > those who don't.) > > Instead, we usually use visibility as cosmetic, something that can be > collapsed in order to avoid visual clutter, and then expanded for a > richer view. > > (I guess it's another angle where my CGI and not app history trips up > a deep understanding of Wicket's; I'm used to a View as being a super > thin thing, client side only, whereas I guess Wicket spreads a > view-ish layer between HTML and Java, so options like "security > through visibility" make more sense, since much of that is being done > on the trusted server not the untrusted client.) > > Still, yeah, I'd vouch for a "isHidden" type implementation, and more > stressing how "isVisibile()" causes things not to added. (Heck, I'd > like to see "isVisible()" changed to "isAbsent()" to really drive home > the point ;-) > > --------------------------------------------------------------------- > 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]
