cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sergeant <m...@sergeant.org>
Subject Re: draft final version of the esql namespace
Date Wed, 08 Nov 2000 14:02:46 GMT
On Wed, 8 Nov 2000, Donald Ball wrote:

> On Wed, 8 Nov 2000, Matt Sergeant wrote:
> 
> > > well, no. but yes. matt had argued against inclusion of the no-results
> > > element as he felt it cluttered up the namespace for no good reason. after
> > > some thinking, i came to agree with him. if you're looking to do styling
> > > based on an empty resultset, you can check to see if the row-results
> > > section has been instantiated ever, right? note results and row-results
> > > are distinct - results is instanted whenever a resultset is returned, even
> > > an empty one, while row-results is instantiated once per row.
> > 
> > Right, its a content vs presentation thing sort of... You want to present
> > the fact that there are no rows - put it in your stylesheet. At least
> > thats how I see it... :-)
> 
> to be fair, afaik marco was looking to execute some _logic_ when no
> results were found, not do some styling. however, i think he can still do
> so with the methodology i described.

Right... You should be able to go if(<esql:row-count> == 0) { ... } (or
whatever the Java parlance is), right?

> > > > Why was the design decision made to have different elements for query
> > > > and update? Why not simply have something like 'results' and 'no-results'
> > > > for everything, i.e. queries, updates, inserts, and - oh, I forgot -
> > > > deletes?
> > > 
> > > hopefully i've made it clear. basically, it comes down to this - the esql
> > > logicsheet has no idea what kind of SQL it's executing when it sends it to
> > > the server - it could be a select, an insert, an update, a delete, a
> > > stored procedure, a non-standard SQL operation, whatever. it just knows
> > > that it's supposed to send SQL to the server and instantiate the proper
> > > results element depending on the results of the operation. sound
> > > reasonable?
> > 
> > I think thats the point being made here - why do we need two different
> > ways of executing SQL - one for query operations and one for edit
> > operations?
> 
> it's not two different ways of executing SQL, it's two different results
> templates being instantiated - one in the case of a _set_ of rows being
> returned, one in the case of a _number_ of rows being returned. bear in
> mind, the esql logicsheet has _no_ idea what sort of SQL it's executing,
> the only information it's got to go on is the type of results that are
> returned. isn't there something similar in the perl DBI world?

No, DBI is agnostic about that. Every kind of statement preparation
returns a statement handle, which you then execute, and finally fetch
results from. Any sort of update will simply not return any rows (but set
the rows property for the number of rows updated). Thats where I'm coming
from... Maybe esql is similar and I haven't looked close enough...

-- 
<Matt/>

    /||    ** Director and CTO **
   //||    **  AxKit.com Ltd   **  ** XML Application Serving **
  // ||    ** http://axkit.org **  ** XSLT, XPathScript, XSP  **
 // \\| // **     Personal Web Site: http://sergeant.org/     **
     \\//
     //\\
    //  \\


Mime
View raw message