cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Reinhard Poetz <reinh...@apache.org>
Subject Re: [RT] Attribute Rendering and CForms Convertors
Date Tue, 16 Nov 2004 07:18:03 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.

I have to admit that I don't understand your usecase completly but rendering 
form fields depending on an editable value and rendering them depending on the 
type should be done using stylesheets (XSLT) and not in an XML template. 
Templates and the FormsTransformer only generate data in a particular structure 
and don't contain layout information but only hints for the stylesheets (e.g. 
the information if a widget is editable or not). They don't know how to render 
the form e.g. that a non-editable form field should be displayed as plain text.

-- 
Reinhard

Mime
View raw message