Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/ org/apache/cocoon/forms/generation/JXMacrosHelper.java
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
-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, [EMAIL PROTECTED] wrote:
Date: Thu, 03 Nov 2005 18:17:42 -
From: [EMAIL PROTECTED]
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=330598view=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=330598r1=330597r2=330598view=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
Hi!
I actually like this for exactly the reason Giacomo pointed out. The thing I am
always afraid of is vulnerability to malicious requests, which this actually
prevents.
This is in itself not a template (i.e. rendering) option but changes the model
on the fly, which can be considered as a view of the model, so I would think
it does belong into the template.
Alternatively, you can of course take care of this in your flowscript which
calls the template pipeline in the first place, but then you have to know the
correct ID of the widget, which can be rather hard, especially if you use
libraries or some other way to generate forms.
So, in general, +1 for this change.
max
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf
Of Giacomo Pati
Sent: Thursday, November 10, 2005 13:36
To: dev@cocoon.apache.org
Subject: Re: svn commit: r330598 -
/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/genera
tion/JXMac
rosHelper.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, [EMAIL PROTECTED] wrote:
Date: Thu, 03 Nov 2005 18:17:42 -
From: [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: cvs@cocoon.apache.org
Subject: svn commit: r330598 -
/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/genera
tion/JXMacro
sHelper.java
Author: sylvain
Date: Thu Nov 3 10:17:39 2005
New Revision: 330598
URL: http://svn.apache.org/viewcvs?rev=330598view=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/generat
ion/JXMacrosHelper.java
Modified:
cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generat
ion/JXMacrosHelper.java
URL:
http://svn.apache.org/viewcvs/cocoon/blocks/forms/trunk/java/o
rg/apache/cocoon/forms/generation/JXMacrosHelper.java?rev=330598r1=330597r2=330598view=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
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 WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
Max Pfingsthorn wrote: Hi! I actually like this for exactly the reason Giacomo pointed out. The thing I am always afraid of is vulnerability to malicious requests, which this actually prevents. This is in itself not a template (i.e. rendering) option but changes the model on the fly, which can be considered as a view of the model, so I would think it does belong into the template. Alternatively, you can of course take care of this in your flowscript which calls the template pipeline in the first place, but then you have to know the correct ID of the widget, which can be rather hard, especially if you use libraries or some other way to generate forms. I totally agree with your concern of malicious requests, and that was actually one of the motivations behind widget states. Now, as said in my previous post, I consider this a business logic concern that has nothing to do in the template. Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
-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: 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
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
Sylvain Wallez wrote: I totally agree with your concern of malicious requests, and that was actually one of the motivations behind widget states. Now, as said in my previous post, I consider this a business logic concern that has nothing to do in the template. +1 Best Regards, Antonio Gallardo. Sylvain
Re: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
-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 [EMAIL PROTECTED] 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-
