cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marco Pauck <pa...@wmd.de>
Subject Re: draft final version of the esql namespace
Date Wed, 08 Nov 2000 14:04:31 GMT
Matt Sergeant wrote:
> 
> 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... :-)

OK, but I disagree... :-)
It can also be a logic issue because I may want to e.g. change the interaction
workflow with the user by providing other links to choose from.

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

That wasn't what I was suggesting.
Instead, to keep the currently available feature to easily distinguish
between the two cases "rows selected/affected" and "no rows selected/affected".

	Marco

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