I'll try to find the thread information. What concerns me about the original poster's idea is the thought of "removing" the component. Rendering or not rendering the component is fine; that's "dynamic behavior". Adding or removing components at runtime violates the idea of "static structure".
The thread subject was "programmatically adding a binding to a component". Gmane: http://article.gmane.org/gmane.comp.java.tapestry.user/25209 The thread was talking specifically about component bindings, but the specific quote I was thinking of was: "The various setter methods exist for the framework, you should treat components as immutable." This includes adding and removing components to the component at runtime. Note that pages are just specialized components. Again, the fundamental issue is not rendering vs. not rendering components, but rather adding/removing the components. It sounded to me like the original poster was wanting to do the latter. The "requires role" component that you implemented sounds fine; this is the sort of approach I was advocating. Robert LOCHART,DOUGLAS E wrote: > Robert, > > I am interested in reading this HLS thread. I did a search but did not > find it. Could you possibly point me to the thread (dates, keywords to > search etc) > > I would appreciate it. > > The approach I took was to create a component (based on the Conditional > component) called RequiresRole. If the user logged in does not have the > role, the menu option/links etc are not visible. It works fine for me. > Maybe I am missing the point in "rendering of pages at runtime" but my > component is JUST LIKE Conditional so I do see what is the problem. > > thanks > > Doug > > > 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] > > > > --------------------------------------------------------------------- > 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]
