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 20:23:29 GMT
Vadim Gritsenko wrote:
> 
> I assume that SELECT should be build with <key>s used in WHERE clause?

Absolutely.  We do want to get the propper record from the DB.

> 
> 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

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


Mime
View raw message