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/>
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.I don't follow you here can you give some more details for that scenario.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.
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.
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 }
