cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <>
Subject Re: draft final version of the esql namespace
Date Wed, 08 Nov 2000 13:59:18 GMT
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.

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

- donald

View raw message