cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Max Pfingsthorn" <m.pfingsth...@hippo.nl>
Subject RE: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
Date Thu, 10 Nov 2005 12:51:51 GMT
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: giacomo@lapgp.otego.com 
> [mailto:giacomo@lapgp.otego.com]On 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, 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/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=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/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=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-----

Mime
View raw message