cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
Date Thu, 10 Nov 2005 16:32:02 GMT
Giacomo Pati wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Ok, lets discuss this :-) maybe there are other ways to do it.

To make things clear: I reverted the change, as we were (supposedly :-) 
) very close to the release, and this seemed to me a significant change 
that needed to be discussed.

The point is that this change introduced the ability for the view to 
change the state of the model, which violates the principles of MVC. 
Hence the need for discussing it first, rather than committing it 
silently just before the release.

> The use case to this is:
>
> a) Suppose you have a repeater showing some informations.
> b) Suppose the users viewing that information can have different role.
>
> Now, depending on the role the user has
>
>   1) he may not see some of the rows (which would be filtered out before
>      passing it to the template of course)
>   2) he may see some of the row (output state)
>   3) he may even edit some of the rows (input state)
>
> How would you accomplish this in a repeater without enabling the 
> template to change the state in the repeater according to the role of 
> the viewing user (which is passed down the pipeline)?

Role management is not a concern of the view, but of either the 
controller or the business logic, that should set the correct widget 
state before displaying the form. Otherwise, you end up with mixing page 
layout and authorization logic in the view, which IMO isn't good.

> Using widgets per role is very ugly (I've tried that) and may 
> complicate validation of not displayed widgets in a row.

Sure.

> Any suggestion would be welcome otherwise I'd like to have that change 
> going into the repository (this or the following release).

Setting widget states in the flowscript: doesn't it fit your need?

> IIRC there is no place other than the template to handle the repeater 
> model content associated to a widget.

Sorry, I don't follow you here: you can access the full form model from 
the flowscript. Did I missed something?

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message