You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Martin Man <Ma...@seznam.cz> on 2001/09/01 17:52:00 UTC
Re: Configuration attribute overriding fails for nullable?
On Fri, Aug 31, 2001 at 01:16:35PM +0100, Chris Newland wrote:
> Hi All,
>
> Parameter overriding does not appear to be working when I try to override
> the 'nullable' attribute of a Configuration parameter:
>
> <root>
>
> <parameter name="password" type="string" nullable="no" />
>
> <constraint-set name="modify">
>
> <validate name="password" nullable="yes"/>
>
> </constraint-set>
>
> </root>
>
> I've tested overriding the other attributes (min, max, max-len ...) and they
> work fine but the example above fails when the "modify" constraint-set if
> used to validate a null "password" parameter.
yes, that's exactly the behavior..., when I started coding all this validation
stuff, I was unable to find a case where overriding of nullable parameter will
be meaningful, so for the moment it does not work as you'd expect...
but, if you provide us with the example where it would be usefull I can
correct it, should be doable somewhere inside AbstractValidatorAction.java...
>
> I've verified this behaviour by adding extra debug into
> AbstractValidatorAction.
>
> >From what I can see, the construction of Configuration variables is not part
> of the Cocoon2 codebase but is in the Avalon framework package. I'll
> download the source for Avalon and see if I can find the bug but can
> somebody please SHOUT if I'm going on a wild goose chase?
>
rgds,
martin
> Thanks,
>
> Chris
>
> --
> Chris Newland
> Software Research Engineer
>
> Emorphia Ltd
> Registered in England. 4133002
> Mill House, Station Approach, Harlow Mill, Harlow, Essex, CM20 2EL, UK
>
> Email: chris.newland@emorphia.com
> Tel: +44 (0)1279 450100
> Fax: +44 (0)1279 450102
>
> Check out FIPA-OS at http://fipa-os.sourceforge.net/
>
> This message may contain information proprietary to Emorphia so any
> unauthorised disclosure, copying or distribution of its contents is strictly
> prohibited.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
--
-------------------------------------------------------------------------------
"Only dead fish swims with a stream" Malcolm Muggeridge
gpg_key_available: http://globales.cz/~mman/martin.man.gpg
gpg_key_fingerprint: 2CC0 4AF6 92DA 5CBF 5F09 7BCB 6202 7024 6E06 0223
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Configuration attribute overriding fails for nullable?
Posted by Martin Man <Ma...@seznam.cz>.
On Mon, Sep 03, 2001 at 09:55:31AM +0100, Chris Newland wrote:
> Hi Martin,
hi chris,
anyway I was thinking about it once again and realized that it might
be quite usefull to provide the functionality as you suggest, ..., therefore
updated version of AbstractValidator is in both cvs branches, BTW: I have
added the same behavior for 'default' attribute...
please, check that it works as expected :-))
regards,
martin
>
> I can see your point about not overriding nullable, its not really a
> constraint specialisation in the same way that narrowing a numerical range
> would be.
>
> The case I was thinking of was this:
>
> I would like to use the same descriptor file to validate data from different
> forms that concern a user's account details.
>
> The default case would be when creating an account, the password field must
> not be null.
>
> The overriding case is when a user modifies some of their account details
> (whilst logged in). They may or may not wish to change their password. In
> this case I would like to allow the modified details to be validated even
> when the user did not specify a new password.
>
> I guess I could send the password as a hidden form variable but that doesn't
> give me good feelings about security since I would be transmitting it to
> their browser where the page could be accessed from a cache.
>
> Its no problem for me to keep the current behaviour as I've got a workaround
> which is to use a different password variable for the account modification
> form which can be nullable.
>
> Best Regards,
>
> Chris
>
> > -----Original Message-----
> > From: Martin Man [mailto:Martin.Man@seznam.cz]
> > Sent: 01 September 2001 16:52
> > To: Chris Newland
> > Cc: Cocoon Dev
> > Subject: Re: Configuration attribute overriding fails for nullable?
> >
> >
> > On Fri, Aug 31, 2001 at 01:16:35PM +0100, Chris Newland wrote:
> > > Hi All,
> > >
> > > Parameter overriding does not appear to be working when I try
> > to override
> > > the 'nullable' attribute of a Configuration parameter:
> > >
> > > <root>
> > >
> > > <parameter name="password" type="string" nullable="no" />
> > >
> > > <constraint-set name="modify">
> > >
> > > <validate name="password" nullable="yes"/>
> > >
> > > </constraint-set>
> > >
> > > </root>
> > >
> > > I've tested overriding the other attributes (min, max, max-len
> > ...) and they
> > > work fine but the example above fails when the "modify"
> > constraint-set if
> > > used to validate a null "password" parameter.
> >
> > yes, that's exactly the behavior..., when I started coding all
> > this validation
> > stuff, I was unable to find a case where overriding of nullable
> > parameter will
> > be meaningful, so for the moment it does not work as you'd expect...
> >
> > but, if you provide us with the example where it would be usefull I can
> > correct it, should be doable somewhere inside
> > AbstractValidatorAction.java...
> >
> > >
> > > I've verified this behaviour by adding extra debug into
> > > AbstractValidatorAction.
> > >
> > > >From what I can see, the construction of Configuration
> > variables is not part
> > > of the Cocoon2 codebase but is in the Avalon framework package. I'll
> > > download the source for Avalon and see if I can find the bug but can
> > > somebody please SHOUT if I'm going on a wild goose chase?
> > >
> >
> >
> > rgds,
> > martin
> >
> >
> > > Thanks,
> > >
> > > Chris
> > >
> > > --
> > > Chris Newland
> > > Software Research Engineer
> > >
> > > Emorphia Ltd
> > > Registered in England. 4133002
> > > Mill House, Station Approach, Harlow Mill, Harlow, Essex, CM20 2EL, UK
> > >
> > > Email: chris.newland@emorphia.com
> > > Tel: +44 (0)1279 450100
> > > Fax: +44 (0)1279 450102
> > >
> > > Check out FIPA-OS at http://fipa-os.sourceforge.net/
> > >
> > > This message may contain information proprietary to Emorphia so any
> > > unauthorised disclosure, copying or distribution of its
> > contents is strictly
> > > prohibited.
> > >
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > > For additional commands, email: cocoon-dev-help@xml.apache.org
> > >
> >
> > --
> > ------------------------------------------------------------------
> > -------------
> > "Only dead fish swims with a stream"
> > Malcolm Muggeridge
> > gpg_key_available: http://globales.cz/~mman/martin.man.gpg
> > gpg_key_fingerprint: 2CC0 4AF6 92DA 5CBF 5F09 7BCB 6202 7024 6E06 0223
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> >
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
--
-------------------------------------------------------------------------------
"Only dead fish swims with a stream" Malcolm Muggeridge
gpg_key_available: http://globales.cz/~mman/martin.man.gpg
gpg_key_fingerprint: 2CC0 4AF6 92DA 5CBF 5F09 7BCB 6202 7024 6E06 0223
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Configuration attribute overriding fails for nullable?
Posted by Chris Newland <ch...@emorphia.com>.
Hi Martin,
I can see your point about not overriding nullable, its not really a
constraint specialisation in the same way that narrowing a numerical range
would be.
The case I was thinking of was this:
I would like to use the same descriptor file to validate data from different
forms that concern a user's account details.
The default case would be when creating an account, the password field must
not be null.
The overriding case is when a user modifies some of their account details
(whilst logged in). They may or may not wish to change their password. In
this case I would like to allow the modified details to be validated even
when the user did not specify a new password.
I guess I could send the password as a hidden form variable but that doesn't
give me good feelings about security since I would be transmitting it to
their browser where the page could be accessed from a cache.
Its no problem for me to keep the current behaviour as I've got a workaround
which is to use a different password variable for the account modification
form which can be nullable.
Best Regards,
Chris
> -----Original Message-----
> From: Martin Man [mailto:Martin.Man@seznam.cz]
> Sent: 01 September 2001 16:52
> To: Chris Newland
> Cc: Cocoon Dev
> Subject: Re: Configuration attribute overriding fails for nullable?
>
>
> On Fri, Aug 31, 2001 at 01:16:35PM +0100, Chris Newland wrote:
> > Hi All,
> >
> > Parameter overriding does not appear to be working when I try
> to override
> > the 'nullable' attribute of a Configuration parameter:
> >
> > <root>
> >
> > <parameter name="password" type="string" nullable="no" />
> >
> > <constraint-set name="modify">
> >
> > <validate name="password" nullable="yes"/>
> >
> > </constraint-set>
> >
> > </root>
> >
> > I've tested overriding the other attributes (min, max, max-len
> ...) and they
> > work fine but the example above fails when the "modify"
> constraint-set if
> > used to validate a null "password" parameter.
>
> yes, that's exactly the behavior..., when I started coding all
> this validation
> stuff, I was unable to find a case where overriding of nullable
> parameter will
> be meaningful, so for the moment it does not work as you'd expect...
>
> but, if you provide us with the example where it would be usefull I can
> correct it, should be doable somewhere inside
> AbstractValidatorAction.java...
>
> >
> > I've verified this behaviour by adding extra debug into
> > AbstractValidatorAction.
> >
> > >From what I can see, the construction of Configuration
> variables is not part
> > of the Cocoon2 codebase but is in the Avalon framework package. I'll
> > download the source for Avalon and see if I can find the bug but can
> > somebody please SHOUT if I'm going on a wild goose chase?
> >
>
>
> rgds,
> martin
>
>
> > Thanks,
> >
> > Chris
> >
> > --
> > Chris Newland
> > Software Research Engineer
> >
> > Emorphia Ltd
> > Registered in England. 4133002
> > Mill House, Station Approach, Harlow Mill, Harlow, Essex, CM20 2EL, UK
> >
> > Email: chris.newland@emorphia.com
> > Tel: +44 (0)1279 450100
> > Fax: +44 (0)1279 450102
> >
> > Check out FIPA-OS at http://fipa-os.sourceforge.net/
> >
> > This message may contain information proprietary to Emorphia so any
> > unauthorised disclosure, copying or distribution of its
> contents is strictly
> > prohibited.
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
>
> --
> ------------------------------------------------------------------
> -------------
> "Only dead fish swims with a stream"
> Malcolm Muggeridge
> gpg_key_available: http://globales.cz/~mman/martin.man.gpg
> gpg_key_fingerprint: 2CC0 4AF6 92DA 5CBF 5F09 7BCB 6202 7024 6E06 0223
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org