cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Tue, 16 Nov 2004 08:32:40 GMT
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?

Sylvain

-- 
Sylvain Wallez                                  Anyware Technologies
http://www.apache.org/~sylvain           http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }


Mime
View raw message