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]

Reply via email to