Hi, On Sat, Jul 19, 2008 at 12:13 AM, David Nedrow <[EMAIL PROTECTED]> wrote: > I'd like to automatically expose additional functionality or field > visibility depending on the authorization level of the user (session). For > example, editable fields for "admin" users. > [...] > Has anyone done something similar or is there an example somewhere that I'm > overlooking?
We have an application with similar features. We had to disable and skip components instead of columns, but the principle might be relevant: We created custom components for all form field types we use (textfield, dropdown, radiochioce, etc.) The component consists of an "editable" and a "read-only" variant of the underlying control, but only one or the other is visible depending on the "enabled" flag of the composite component. (unauthorised users wouldn't be much interested in what they can not set a radiochoice field to for example. Disabled textfields are hard to copy-paste from.) The "visible" flag is obeyed too. (the markup is a bit nasty because of this: the form is a table, and the components are table rows so they can be omitted without visual glitches. Shouldn't be a problem with table rows.) We also added convenience constructors to the components, passing the "enabled" and "visible" flags, matching with convenience service methods on the logged in user meeting authorisation criteria. Here we are implicitly relying on wicket being "safe" in the sense that no client side forgery can result in the activation of a missing or disabled component. (all operations are double-checked in the service layer nonetheless.) We didn't use wicket-auth-roles because the categories were too simple at first (but then project scope drift started...) You'll have to substitute table columns for components, it already has isVisible, and you can just add isEnabled. Hope it helps! Gabor Szokoli --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
