"absent" would be an even worse name in my opinion. the component exists. it's definitely not absent. it's just not rendering something.
But in any case, it's way too late to change something that fundamental, so you may as well adjust your way of thinking about this Kirk Israel-2 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] > > > -- View this message in context: http://www.nabble.com/Wicket-Visibility-vs.-CSS-visibility-tp17285530p17293177.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]
