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
