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 10:35:35 GMT
On Wed, 8 Nov 2000, Donald Ball wrote:

> On Tue, 7 Nov 2000, Marco Pauck wrote:
> 
> > Donald Ball wrote:
> > > after much discussion and cogitation, i submit the following pseudoschema
> > > as the proposed final skeleton of the esql namespace:
> > [...]
> > > 3. if a query returns a resultset, the children of the results element, if
> > > any, are instantiated and the children of the results element's
> > > row-results child are instantiated for each row in the resultset.
> > 
> > What if the query returns an empty resultset?
> > Will <esql:no-results> still be available?
> > If not, that would mean that we have to move conditional logic from the
> > xsp page, where it is now, to the stylesheet which would be quite ugly!
> > We made heavy use of this feature!
> 
> 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... :-)

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

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