tapestry-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Zeigler <robe...@scazdl.org>
Subject Re: render time element removal question
Date Sat, 03 Sep 2005 05:34:03 GMT
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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org


Mime
View raw message