[ESQL]4 ideas for discussion

[Tagunov Anthony <at...@nnt.ru>]

Hello, guys!
Hello, Donald!

I've seen a pretty high traffic on the list in the last 20 minutes and desided to remind again
about questions I've been asking about esql.xsl taglib in the last mounth.

Basicly, I was asking for 4 improvements (features?) to the official ESQL:

1) there's a nice 
      }
      <xsl:apply-templates/>
    } finally {

section in the esql.xsl where actually all the db queries get expanded. This is also a place where the connecting to database
stuff comletes and starcts database interaction.
We've got a way to catch errors in execute-query (error-results).
What do you think if we do something like esql.diff (this is just a draft, maybe there's a nicer way to do this..)

Anyway the idea is to make exception while connection to database easier to handle, make this all more strainghtforward.

2) I was asking what you think of making <esql:parameter> also have some encoding attribute, or
child element? (I understand, it looks awkward to write
<esql:parameter><esql:encoding>UTF-8</esql:encoding>Bla-bla</esql:parameter>, but maybe it's not too bad after all?
Of cource <esql:parameter encoding="UTF-8"></> looks better, but..)
Anyway, if deside on how we want the encoding to get in, there's no obstacle to using setBytes in addition to setString
(is this really nicer then to recode manually and use type="Bytes"?)

3) regarding

<esql:results>
       <table border="1" style="results">
       <esql:row-results>
               <tr><td><esql:get-string.../></td></tr>
        </esql:row-results>
       </table>
  </esql:results>
  <esql:no-results>
       <talbe border="1" style="noresults">
            <tr><td>Sorry, nothing found</td></tr>
       </table>
   </esql:no-results>

example, any comments? I mean is there any sense in my idea of
stopping <esql:results> content from being instantiated when
<esql:no-results> is being instantiated?

4) Is any way for getting connections by name but without the pooling facility
available at least for Cocoon2?

(The matter is what we had under Cocoon1 was 
 getting connection by name + connection pooling
What I want is
 getting connection by name without pooling.

Is this already available for C2 framework?

My original idea was of having some special
tag for it similar to <esql:pool>, <esql:nopool> maybe :)

Best regards, gentelmen, and
please, can you comment on this? 

Does any of this make any sense?
(I have all these things introduced in esql.xsl
used for our projects here, but maybe there's something rational in
this to tell to the public?)

Re: [ESQL]4 ideas for discussion

[Matt Sergeant <ma...@sergeant.org>]

On Fri, 26 Jan 2001, Tagunov Anthony wrote:

> On Thu, 25 Jan 2001 18:52:13 -0500 (EST), Donald Ball wrote:
>
> >On Wed, 24 Jan 2001, Tagunov Anthony wrote:
> >
> >> I've seen a pretty high traffic on the list in the last 20 minutes and
> >> desided to remind again about questions I've been asking about
> >> esql.xsl taglib in the last mounth.
> >>
> >> Basicly, I was asking for 4 improvements (features?) to the official ESQL:
> >>
> >> 1) there's a nice
> >>       }
> >>       <xsl:apply-templates/>
> >>     } finally {
> >>
> >> section in the esql.xsl where actually all the db queries get
> >> expanded. This is also a place where the connecting to database stuff
> >> comletes and starcts database interaction. We've got a way to catch
> >> errors in execute-query (error-results). What do you think if we do
> >> something like esql.diff (this is just a draft, maybe there's a nicer
> >> way to do this..)
> >
> >um, what are you suggesting here?
>
> well, my suggestion is to have some <esql:error-connection> in<esql:connection>
> and instatiate it's contents in case Exception is throw from the code performing connection to the
> database. Speaking in tersms of esql.xsl this is what i have drafted in esql.diff (see the attachment).
> Of cource, I mean that if <error-connection> is instantiated the exception does not propaged up the stack.
>
> Thus we have a way to catch connection exceptoin (<esql:connection><esql:error-connection>) and
> a way to catch exception in query execution (<esql:execute-connection><esql:error-results>)

I think we should remove exception handling from esql altogether, and
create a new exception taglib:

<except:try>
...
<except:catch>
 <except:get-type/>
 <except:to-string/>
 <except:backtrace/>
 <except:throw/>
</except:catch>
</except:try>

I don't think it should be too fancy about catching any particular type of
exception, because they will obviously vary from language to language.

Thoughts?

-- 
<Matt/>

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

Re: [ESQL]4 ideas for discussion

[Tagunov Anthony <at...@nnt.ru>]

On Thu, 25 Jan 2001 18:52:13 -0500 (EST), Donald Ball wrote:

>On Wed, 24 Jan 2001, Tagunov Anthony wrote:
>
>> I've seen a pretty high traffic on the list in the last 20 minutes and
>> desided to remind again about questions I've been asking about
>> esql.xsl taglib in the last mounth.
>>
>> Basicly, I was asking for 4 improvements (features?) to the official ESQL:
>>
>> 1) there's a nice
>>       }
>>       <xsl:apply-templates/>
>>     } finally {
>>
>> section in the esql.xsl where actually all the db queries get
>> expanded. This is also a place where the connecting to database stuff
>> comletes and starcts database interaction. We've got a way to catch
>> errors in execute-query (error-results). What do you think if we do
>> something like esql.diff (this is just a draft, maybe there's a nicer
>> way to do this..)
>
>um, what are you suggesting here?

well, my suggestion is to have some <esql:error-connection> in<esql:connection>
and instatiate it's contents in case Exception is throw from the code performing connection to the
database. Speaking in tersms of esql.xsl this is what i have drafted in esql.diff (see the attachment).
Of cource, I mean that if <error-connection> is instantiated the exception does not propaged up the stack.

Thus we have a way to catch connection exceptoin (<esql:connection><esql:error-connection>) and
a way to catch exception in query execution (<esql:execute-connection><esql:error-results>)

>
>> 2) I was asking what you think of making <esql:parameter> also have some encoding attribute, or
>> child element? (I understand, it looks awkward to write
>> <esql:parameter><esql:encoding>UTF-8</esql:encoding>Bla-bla</esql:parameter>, but maybe it's not too bad after all?
>> Of cource <esql:parameter encoding="UTF-8"></> looks better, but..)
>> Anyway, if deside on how we want the encoding to get in, there's no obstacle to using setBytes in addition to setString
>> (is this really nicer then to recode manually and use type="Bytes"?)
>
>i think encoding conversion stuff belongs in another namespace and
>logicsheet. it's not germane to sql per se.
>

A nice idea!

>> 3) regarding
>>
>> <esql:results>
>>        <table border="1" style="results">
>>        <esql:row-results>
>>                <tr><td><esql:get-string.../></td></tr>
>>         </esql:row-results>
>>        </table>
>>   </esql:results>
>>   <esql:no-results>
>>        <talbe border="1" style="noresults">
>>             <tr><td>Sorry, nothing found</td></tr>
>>        </table>
>>    </esql:no-results>
>>
>> example, any comments? I mean is there any sense in my idea of
>> stopping <esql:results> content from being instantiated when
>> <esql:no-results> is being instantiated?
>
>the results section is instantiated whenever a query gives you a
>resultset, regardless of the number of rows it may or may not have. we
>can't know how many rows it has until we start iterating through the
>resultset. the no-results section is there for user convenience. i'm
>willing to consider changing this behavior tho.
>

Please, how do you think it should be changed? Does it look anything
similar to what I had in my mind (I had an idea of having 
<esql:result>
<esql:no-results>
<esql:error-results>
strictly exclusive (only one of them being generated) ?

>
>> 4) Is any way for getting connections by name but without the pooling
>> facility available at least for Cocoon2?
>>
>> (The matter is what we had under Cocoon1 was
>>  getting connection by name + connection pooling
>> What I want is
>>  getting connection by name without pooling.
>>
>> Is this already available for C2 framework?
>
>dunno, ask berin.
>
>- donald
>

Re: [ESQL]4 ideas for discussion

[Donald Ball <ba...@webslingerZ.com>]

On Wed, 24 Jan 2001, Tagunov Anthony wrote:

> I've seen a pretty high traffic on the list in the last 20 minutes and
> desided to remind again about questions I've been asking about
> esql.xsl taglib in the last mounth.
>
> Basicly, I was asking for 4 improvements (features?) to the official ESQL:
>
> 1) there's a nice
>       }
>       <xsl:apply-templates/>
>     } finally {
>
> section in the esql.xsl where actually all the db queries get
> expanded. This is also a place where the connecting to database stuff
> comletes and starcts database interaction. We've got a way to catch
> errors in execute-query (error-results). What do you think if we do
> something like esql.diff (this is just a draft, maybe there's a nicer
> way to do this..)

um, what are you suggesting here?

> 2) I was asking what you think of making <esql:parameter> also have some encoding attribute, or
> child element? (I understand, it looks awkward to write
> <esql:parameter><esql:encoding>UTF-8</esql:encoding>Bla-bla</esql:parameter>, but maybe it's not too bad after all?
> Of cource <esql:parameter encoding="UTF-8"></> looks better, but..)
> Anyway, if deside on how we want the encoding to get in, there's no obstacle to using setBytes in addition to setString
> (is this really nicer then to recode manually and use type="Bytes"?)

i think encoding conversion stuff belongs in another namespace and
logicsheet. it's not germane to sql per se.

> 3) regarding
>
> <esql:results>
>        <table border="1" style="results">
>        <esql:row-results>
>                <tr><td><esql:get-string.../></td></tr>
>         </esql:row-results>
>        </table>
>   </esql:results>
>   <esql:no-results>
>        <talbe border="1" style="noresults">
>             <tr><td>Sorry, nothing found</td></tr>
>        </table>
>    </esql:no-results>
>
> example, any comments? I mean is there any sense in my idea of
> stopping <esql:results> content from being instantiated when
> <esql:no-results> is being instantiated?

the results section is instantiated whenever a query gives you a
resultset, regardless of the number of rows it may or may not have. we
can't know how many rows it has until we start iterating through the
resultset. the no-results section is there for user convenience. i'm
willing to consider changing this behavior tho.

> 4) Is any way for getting connections by name but without the pooling
> facility available at least for Cocoon2?
>
> (The matter is what we had under Cocoon1 was
>  getting connection by name + connection pooling
> What I want is
>  getting connection by name without pooling.
>
> Is this already available for C2 framework?

dunno, ask berin.

- donald