cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonas Ekstedt <ekst...@ibg.uu.se>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Wed, 17 Nov 2004 05:34:28 GMT
On Tue, 2004-11-16 at 09:32 +0100, Sylvain Wallez wrote:
> Jonas Ekstedt wrote:
> 
> >On Mon, 2004-11-15 at 10:35 +0100, Sylvain Wallez wrote:
> >  
> >
> >>Jonas Ekstedt wrote:
> >>
> >>    
> >>
> >>>On Mon, 2004-11-08 at 10:49 +0100, Daniel Fagerstrom wrote:
> >>> 
> >>>
> >>>      
> >>>
> >><snip/>
> >>
> >>    
> >>
> >>>>>Another way of doing the same, which I think was the agreed upon
way to
> >>>>>do it is to populate all widgets that has a request parameter present.
> >>>>>This works out the same way with one little caveat. Some day someone
is
> >>>>>going to do
> >>>>>
> >>>>><jx:if test="${user.role == 'admin'}">
> >>>>><ft:widget id="bigDangerousButton"/>
> >>>>></jx:if>
> >>>>>
> >>>>>and will be in for a mighty surprise.
> >>>>>     
> >>>>>
> >>>>>          
> >>>>>
> >>>>I don't follow you here can you give some more details for that scenario.
> >>>>   
> >>>>
> >>>>        
> >>>>
> >>>What I meant was that in the scenario above a malicious user can add a
> >>>request parameter "bigDangerousButton" to the POST and it will be
> >>>processed by the population mechanism (firing off button events) even if
> >>>the user has role "user" in the example above. I think this would
> >>>actually be quite a common usecase having one form template rendered
> >>>differently depending on what type of user access it. The problem is
> >>>that a population mechanism without knowledge of what has been rendered
> >>>cannot make decisions about which widgets are eligible for population.
> >>> 
> >>>
> >>>      
> >>>
> >>On that particular point, it seems to me *especially dangerous* to let 
> >>the template decide what what widgets are to be displayed depending on 
> >>user roles.
> >>
> >>ACL is an application-level concern, and *must* be handled by the 
> >>controller and/or the application logic. That's what widget states 
> >>allow: by setting the "bigDangerousButton" state to invisible, you don't 
> >>even need the <jx:if>. The <ft:widget id="bigDangerousButton"/> will

> >>simply render nothing if the widget's state is invisible.
> >>    
> >>
> >
> >The problem with this approach is that normally (I would think at least)
> >widget states will be changed in a manner orthogonal to the widget
> >hierarchy. The widgets being hidden will be all over the form rather
> >than under one single fd:struct that can be switched on/off.
> >
> >Take the current project I'm working on. I have a Taxon (4 subclasses)
> >which contains a list of Specifiers (3 subclasses) which contains a list
> >of Tokens (4 subclasses). Each of the subclasses are rendered
> >differently depending on class and whether they are edited or viewed.
> >The user can also choose whether to view/edit the whole hierarchy at
> >once or only parts of it.
> >
> >To do this I use one jxmacro for each subclass. The macro renders form
> >fields if ${edit == 'true'} or text otherwise. It would be a nightmare
> >trying to do this with CForm as I would have to walk around the entire
> >widget tree setting widget states when switching between editing and
> >viewing.
> >  
> >
> 
> Looks to me this is the perfect use case for union and class widgets in 
> CForms. I had similar use-cases for an IDE-like webapp, and these 
> widgets made wonders.
> 
> Also, have you looked at the "form gui" and "swan" samples where they 
> are heavily showcased?
> 

I humbly request for permission to crawl back under a rock ;) . Looking
through the union and class samples, that seems to be exactly what I
need.

Cheers Jonas


Mime
View raw message