I had considered this approach and appreciate the feedback. At this point I'm trying to evaulate whether it's worth the effort to modify what Tapestry code I need to behave as I've described, or to simply wrap all the secure elements in conditionals or a component (as you have suggested). The latter seems to be a lot more work, considering I have ~200 elements. On the contrary, if I just evaluated each element's id upon render and validated access, it'd be conceptually easy to simply not render it. However, I haven't yet even peeked at any render code. Hence my solicitation for suggestions, ideas and experiences.
On 9/2/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > To be honest, personally, I don't think that approach is really going to > mix well with tapestry. As was mentioned by HLS in a recent thread, you > should consider pages at runtime as immutable. Removing elements will > prove problematic, I think. > An approach I used was to create a sort of "inRole" component. It takes > as parameters either a requisite permission name or an object for which > permission is required. It's essentially an "if" wrapper, but has the > advantage of centralizing the render-oriented permission logic to a single > component. > You could also create custom wrappers around any components. So you > could, for instance, create a "SecureTable" component which wraps a table > component, adds parameters related to permission checking, and > conditionally renders the component. Then you could use your SecureTable > just like table, and still have your dynamic behavior.... static > structure, dynamic behavior. :) > > Robert > > > I'm wondering if anyone has impemented a security model that requires > > dynamic (render-time) removal of certain HTML elements? And if so, how > > hefty > > was the work? I need to remove elements at render time based upon roles > > and > > rights and *do not* want to wrap all of the secure elements in > > conditionals. > > Rather, I'd wish to determine at render time the necessity of removing > > certain elements and simply not render them. > > > > TIA, > > -RR- > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
