cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vadim Gritsenko" <vgritse...@hns.com>
Subject RE: [BUG C2] act method of Database Actions always return null
Date Fri, 27 Jul 2001 20:19:25 GMT
I assume that SELECT should be build with <key>s used in WHERE clause?

Vadim

> -----Original Message-----
> From: Berin Loritsch [mailto:bloritsch@apache.org]
> Sent: Friday, July 27, 2001 2:41 PM
> To: cocoon-dev@xml.apache.org
> Subject: Re: [BUG C2] act method of Database Actions always return null
> 
> 
> 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
> 

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


Mime
View raw message