You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Giacomo Pati <gi...@apache.org> on 2005/11/10 13:36:17 UTC
Re: svn commit: r330598 -
/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ok, lets discuss this :-) maybe there are other ways to do it.
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)?
Using widgets per role is very ugly (I've tried that) and may complicate
validation of not displayed widgets in a row.
Any suggestion would be welcome otherwise I'd like to have that change
going into the repository (this or the following release).
IIRC there is no place other than the template to handle the repeater
model content associated to a widget.
Thanks and ciao
Giacomo
On Thu, 3 Nov 2005, sylvain@apache.org wrote:
> Date: Thu, 03 Nov 2005 18:17:42 -0000
> From: sylvain@apache.org
> Reply-To: dev@cocoon.apache.org
> To: cvs@cocoon.apache.org
> Subject: svn commit: r330598 -
> /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacro
> sHelper.java
>
> Author: sylvain
> Date: Thu Nov 3 10:17:39 2005
> New Revision: 330598
>
> URL: http://svn.apache.org/viewcvs?rev=330598&view=rev
> Log:
> Reverting r328311: allowing the template to change the widget is a fundamental change that must be discussed prior to be included in a release
>
> Modified:
> cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
>
> Modified: cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
> URL: http://svn.apache.org/viewcvs/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java?rev=330598&r1=330597&r2=330598&view=diff
> ==============================================================================
> --- cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java (original)
> +++ cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java Thu Nov 3 10:17:39 2005
> @@ -287,10 +287,6 @@
> */
> public void generateWidget(Widget widget, Map arguments) throws SAXException {
> // Needs to be buffered
> - String state = (String)arguments.get("state");
> - if (state != null) {
> - widget.setState(WidgetState.stateForName(state));
> - }
> RootBufferingPipe pipe = new RootBufferingPipe(this.cocoonConsumer, arguments);
> this.pipeStack.push(pipe);
> widget.generateSaxFragment(pipe, this.locale);
>
>
>
- --
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)
iD8DBQFDcz7KLNdJvZjjVZARAk35AJoDUnrsJHorEvSl4/Itmu2qM+SZbgCgh2Xe
fmH48PeQmNUoOAGYg2QTKXo=
=Cbm2
-----END PGP SIGNATURE-----
Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
Posted by Jörg Heinicke <Jo...@gmx.de>.
> On Thu, 10 Nov 2005, Joerg Heinicke wrote:
>
>>> 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.
>>
>> Sorry, but I absolutely don't follow you here. MVC is for decoupling
>> model, view and controller, i.e. to have as few as possible dependencies
>> between the three aspects. There are three you need: the controller
>> changing the model, the controller selecting the view and the view
>> accessing the properties of the model. But the latter one must be a
>> read-only process, otherwise the view does not only depend on the model,
>> but also the model on the view, as the view would not be
>> interchangeable.
>
> I thought I've said eactly this: The View knows how to display the
> Model (where do you read in my mail that the View changes the Model?)
You didn't write that directly. I guess the difference is just if "editable
or not" is a property of the model or the view.
>> In your sample a property of the model (viewable or not, editable or
>> not) shall be changed by the view, what is plain wrong IMO. It is the
>> task of the controller to take care of it.
That (editable = property of the model) is what I wanted to express with
this paragraph.
Jörg
--
Highspeed-Freiheit. Bei GMX supergünstig, z.B. GMX DSL_Cityflat,
DSL-Flatrate für nur 4,99 Euro/Monat* http://www.gmx.net/de/go/dsl
Re: svn commit: r330598 -
/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
Posted by Giacomo Pati <gi...@apache.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Thu, 10 Nov 2005, Joerg Heinicke wrote:
> Date: Thu, 10 Nov 2005 23:59:14 +0100
> From: Joerg Heinicke <jo...@gmx.de>
> 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
>
> On 10.11.2005 19:50, Giacomo Pati wrote:
>
>> 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.
>
> Sorry, but I absolutely don't follow you here. MVC is for decoupling model,
> view and controller, i.e. to have as few as possible dependencies between the
> three aspects. There are three you need: the controller changing the model,
> the controller selecting the view and the view accessing the properties of
> the model. But the latter one must be a read-only process, otherwise the view
> does not only depend on the model, but also the model on the view, as the
> view would not be interchangeable.
I thought I've said eactly this: The View knows how to display the
Model (where do you read in my mail that the View changes the Model?)
>
> In your sample a property of the model (viewable or not, editable or not)
> shall be changed by the view, what is plain wrong IMO. It is the task of the
> controller to take care of it.
>
>> Actually the flow is supposed to be glue code between Controller and Model
>> of MVC not actually the Viewer part.
>
> Isn't flow supposed to be *the* controller (or at least part of it)?
Yes, part of the Conroller
>
> Jörg
>
>
- --
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)
iD8DBQFDdDUdLNdJvZjjVZARAu9NAJ9njBkLdk5Y4GS/WoAt8F8Af2IK2ACgqqpf
KXtdMhnyQ9aNJ3b8BnCi+aw=
=+74W
-----END PGP SIGNATURE-----
Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
Posted by Joerg Heinicke <jo...@gmx.de>.
On 10.11.2005 19:50, Giacomo Pati wrote:
> 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.
Sorry, but I absolutely don't follow you here. MVC is for decoupling
model, view and controller, i.e. to have as few as possible dependencies
between the three aspects. There are three you need: the controller
changing the model, the controller selecting the view and the view
accessing the properties of the model. But the latter one must be a
read-only process, otherwise the view does not only depend on the model,
but also the model on the view, as the view would not be interchangeable.
In your sample a property of the model (viewable or not, editable or
not) shall be changed by the view, what is plain wrong IMO. It is the
task of the controller to take care of it.
> Actually the flow is supposed to be glue code between Controller and
> Model of MVC not actually the Viewer part.
Isn't flow supposed to be *the* controller (or at least part of it)?
Jörg
Re: svn commit: r330598 -
/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
Posted by Giacomo Pati <gi...@apache.org>.
-----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 <sy...@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-----
Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
Posted by Sylvain Wallez <sy...@apache.org>.
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