cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <giac...@apache.org>
Subject Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
Date Thu, 10 Nov 2005 18:50:14 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 10 Nov 2005, Sylvain Wallez wrote:

> Date: Thu, 10 Nov 2005 17:32:02 +0100
> From: Sylvain Wallez <sylvain@apache.org>
> Reply-To: dev@cocoon.apache.org
> To: dev@cocoon.apache.org
> Subject: Re: svn commit: r330598 -
>     /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacro
>     sHelper.java
> 
> 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.

Agreed.

> 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

We can also discuss whether the Form model is part of the business model 
or the View from a MVC POV.

> for discussing it first, rather than committing it silently just before the 
> release.

Ok.

>>  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.

Actually the sample given isn't the best. How about a simpler one:

The widgets in the repeater rows need to be displayed wrt some 
properties of a single object (let's say its a 'state of completness'). 
Now from MVC POV it's the viewer (template) that knows how to display 
the properties of the business model and thus needs a way to instruct 
the technology used (CForm) to respect that.

>>  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?

Actually the flow is supposed to be glue code between Controller and 
Model of MVC not actually the Viewer part.

- -- 
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDc5ZrLNdJvZjjVZARAlFtAJ9cVrX6/owAOztHns6LrQgxsjwkPwCgws/R
p6XdAyM1W1cv6ruS25iJrh8=
=kYiI
-----END PGP SIGNATURE-----

Mime
View raw message