Re: DatabaseXActions

[Mario Muja]

Hi Chris,
1. how does this intermediate "request attribute over request param" work in practice? I mean, how does your code / sitemap look like, when you use this feature?

2. To whom do you forward your patch for AbstractDatabaseAction? Or do you have permissions to write to the CVS tree? I ask this to find out, to whom I shall send my own improvements of the code or documentation.

Best Regards,
Mario



Chris Newland wrote:

[EMAIL PROTECTED]">

Hi Mario,

You are completely right!

I'd forgotton that the form validation action could substitute default
values for missing form parameters. In that case there is no need to add
support for nullable and default descriptor attributes in
AbstractDatabaseAction.

I'll still submit a patch to AbstractDatabaseAction that allows request
attributes to override request parameters since this allows an intermediate
action to be placed between form-validation and database action that can
manipulate the form parameters and store the updated values in attributes.

Thanks for pointing this out,

Chris

-----Original Message-----
From: Mario Muja [mailto:[EMAIL PROTECTED]]
Sent: 06 September 2001 15:24
To: [EMAIL PROTECTED]
Cc: Cocoon Dev
Subject: Re: DatabaseXActions


Hi Chris,
when I have a form validation descriptor to validate parameters, which
are later stored in database columns, then I do not like to put the same
rules into the form validation descriptor and also in the database
descriptor.

I like to have all validation rules in one descriptor. I think, the
right place for this is the form validation descriptor because then you
can validate parameters, which are not stored in a database. It think,
this is the reason, why no validation attributes like nullable and
default have been included in the database descriptor file.
So, why do you not simply use the form validation descriptor for the
Nullable and Default validations? This is, what it has been created for,
or not?

Regards, Mario


Chris Newland wrote:

Hi Mario,

I can't see how this conflicts. I would imagine that people

would be using

different descriptor files for form validation and database manipulation
wouldn't they?

A form validation descriptor is about parameter constraint

validation, the

database action descriptor is about manipulating database columns. These
seem like separate concerns to me?

imho: I would not expect a developer to use the same descriptor file for
form validation actions and database actions in their sitemap.

Perhaps I've made too big an assumption?

I'm trying to add a little more power to the database action

descriptor to

support the notion of nullable columns and default values for missing
parameters / attributes (e.g. The IE browser omits parameters

for checkboxes

that aren't ticked but I want an 'N' in my database)

Could some other people comment on this issue so I can get an idea about
whether my fixes are "a good thing" ?

Best Regards,

Chris

ps. Sorry for the duplicate posts earlier, having a major ISP

headache today

:(

-----Original Message-----
From: Mario Muja [mailto:[EMAIL PROTECTED]]
Sent: 06 September 2001 14:24
To: [EMAIL PROTECTED]
Cc: Cocoon Dev
Subject: Re: DatabaseXActions


Hi Chris,
sorry for interrupting your discussion with Andrew. You wrote:

"nullable" attribute in the AbstractDatabaseAction descriptor
"default" attribute in the AbstractDatabaseAction descriptor
Does this not conflict with the Form Validation descriptor, which also
includes nullable and default attributes?

Regards, Mario



---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>

To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]