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 Wed, 17 Nov 2004 08:52:11 GMT
Jonas Ekstedt wrote:

>On Tue, 2004-11-16 at 09:39 +0100, Sylvain Wallez wrote:
>  
>
>>Jonas Ekstedt wrote:
>>
>>    
>>
>>>On Mon, 2004-11-15 at 11:34 +0100, Daniel Fagerstrom wrote:
>>> 
>>>
>>>      
>>>
>>>>Sylvain Wallez wrote:
>>>>   
>>>>
>>>>        
>>>>
>>>>>Jonas Ekstedt wrote:
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>><snip/>
>>>>   
>>>>
>>>>        
>>>>
>>>>>>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.
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>I agree about that, ACL is definitelly not a view concern. It should be 
>>>>enforced in the business logic and supported in the form model.
>>>>   
>>>>
>>>>        
>>>>
>>>In my view there are three aspects to ACL. Taking the example of a form
>>>that can be viewed or edit:
>>>
>>>* Are we in view or edit mode (a controller concern)
>>>* Should I show a field widget or simple text (a view concern)
>>> 
>>>
>>>      
>>>
>>What's the difference with the first aspect?
>>    
>>
>
>What I meant was that the controller makes the decision about what state
>we're in (eg setting an edit flag to true or false). The view will
>contain the logic to actually implement that decision (using jx logic
>for example).
>  
>

By "implementing that decision", do you mean that it's the view's 
responsibility to render a widget according to its state? That's for 
sure, and in CForms this is implemented (and factorized) in the 
rendering stylesheets rather than in each page template.

>>>* Should I set this value (a model concern)
>>>      
>>>
>> From a from framework POV, this aspect should be "should I accept user 
>>input for this value", as the domain model shouldn't care about form 
>>handling.
>>    
>>
>
>True
>
>  
>
>>>Ideally all the controller would have to do is:
>>>if (user.role == "admin")
>>> cocoon.sendPage("page", {mode: "edit");
>>>else
>>> cocoon.sendPage("page", {mode: "view");
>>> 
>>>
>>>      
>>>
>>And what about:
>>
>>if (user.role == "admin")
>>  form.setState("disabled"); // or "output" to show only text
>>else
>>  form.setState("active");
>>
>>cocoon.sendPage("page");
>>    
>>
>
>Am I right in thinking that form.setState("active") would recursively
>activate all child widgets?
>

States are an ordered enumeration: invisible < disabled < active. The 
actual state of a widget is the strictest one between its own state and 
the state of its parent. That means that form.setState("disable") will 
disable the whole form whereas form.setState("active") will not activate 
widgets whose own state is disables. See AbstractWidget.getCombinedState().

>In that case I think it would be too coarse-
>grained. Suppose you have a list of tasks that can be viewed/edited. In
>edit mode all tasks you have been assigned will show a "Finished"
>button. In JXTemplate you could do this very easy:
>
><jx:forEach var="task" items="${tasks}">
>  <tr>
>    <td>${task.description}</td>
>    <td>
>      <jx:if test="${edit == 'true' and task.assignedTo == user.id}">
>        <button name="task.${task.id}.finished">Finished</button>
>      </jx:if>
>    </td>
>  </tr>
></jx:forEach>
>
>The model would of course also check that the user trying to finish a
>task is indeed the assigned user.
>
>In CForm I think it would be very difficult to do something like this.
>Even if using union widgets.
>

Unions won't be useful here, as we don't have structure variations, but 
a single widget whose state depends on some model and/or other widget 
values.

>You would have to resort to using flow and iterate through all tasks and enable/disable
the buttons individually.
>  
>

That can be handled automatically in the binding when the form is filled 
with task data.

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