cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Loritsch <blorit...@apache.org>
Subject Re: [BUG C2] act method of Database Actions always return null
Date Fri, 27 Jul 2001 18:41:29 GMT
Vadim Gritsenko wrote:
> 
> > -----Original Message-----
> > From: Berin Loritsch [mailto:bloritsch@apache.org]
> > Sent: Friday, July 27, 2001 10:59 AM
> > To: cocoon-dev@xml.apache.org
> > Subject: Re: [BUG C2] act method of Database Actions always return null
> >
> >
> > Vadim Gritsenko wrote:
> > >
> > > Berin,
> > >
> > > I think that you as author of this actions know the answer on my question:
> > >
> > > I'm thinking of returning number of updated rows in Database[Update|Delete]Action
as a result.
> > > Name of result parameter in the map would be "rows". Is it OK - should I commit
the changes?
> >
> > Sure--as long as you keep two things in mind:
> >
> > 1) Never return a map if the query failed
> > 2) The returned map has substitution values for the sitemap.  I doubt you will be
> >    selecting stylesheets based on the number of rows updated.  Perhaps it would
> >    be better to set Request attributes instead.
> 
> Makes perfect sence! Done. Return result is empty Map on success and row count as request
> attribute, "null" if nothing has been changed, and exception for all other cases.


Cool beans!

If you are up to the task, I have one more DatabaseAction that would make Cocoon
Form processing really easy.  It is a DatabaseSelectAction that uses the same
exact format as the other database actions, but creates a SQL SELECT query.
When it is run, the Action:

1) tests to see if there is a Request _parameter_ by the same name as specified in
   the configuration file.

2) If it does, it populates the Request _attribute_ by the same name with the
   Request _parameter_ value.

3) If it does not, it populates the Request _attribute_ with the value from
   the database.

4) It will return a Map on success, and a null if there was an error.  Note:
   no results is not an error case.



What this accomplishes is a process where you have a form whose values are
consistent with what the user typed in--without writing alot of custom code
for it.  I have an existing webapp that needs to be upgraded in the very near
future that does not handle this properly.  Basically it always gathers the
information from the database even if there was an error condition.  The
implications are that if you entered or changed 10 items on the form, and one
of them caused an error, they would all be set back to the original values.
With the new action we can avoid that--and if written correctly we can
even avoid calling the SQL until there is a request parameter that isn't
matched!

Any takers?

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message