-----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 <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
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-----
