cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tagunov Anthony" <atagu...@nnt.ru>
Subject Re: Cocoon 1.8.1 (was: Re: generate <esql:excute-query> dynamically ?)
Date Thu, 11 Jan 2001 21:59:50 GMT
On Wed, 10 Jan 2001 21:48:28 -0500 (EST), Donald Ball wrote:

>On Thu, 11 Jan 2001, Robin Green wrote:
>
>> The other minor thing is (don't flame me, Donald, you were the one who
>> wanted to finalize the esql namespace), I think the encoding support in esql
>> should use elements instead of attributes so that we can use
>> get-nested-whatsits. But it's late.
>
>not to late imho. i didn't do the encoding stuff, it's not even mentioned
>in the schema. i'm more than willing to change it in favor of a better
>scheme. if anyone objects, i'm willing to be overruled, but otherwise i
>say we change it.
>
>- donald
>

Guys! May I come up with some more propositions?

Well, (in the order of importance)

1) as long as we have <esql:get-string column=".." encoding="windows-1251"/>, it would
be hingly reasonable
(and highly usefull!) to have  <esql:parameter encoding="windows-1251"/>. I've tested
it myself (there's my
patch somewhere there in the mailist that does it via setBytes()) and it works!

2) (semantics, not schema) is it reasonable not to have <esql:results> when <esql:no-results>
is instantiated?
e.g. is it reasonable to have <esql:results> and <esql:no-results> be mutually
exclusive? (this would simplify xslt processing
of the result)

3) guys! do you really think that having a way to catch exception somewhere around
=============
      }
      <xsl:apply-templates/>
    } finally {         /*line 278, v1.41 */
      try {
        if(!_esql_connection.connection.getAutoCommit()) {
=============
is a bad idea? What I'm speaking about is having some 
=============
 <esql:connection>
     <esql:error-results>
            <error>Can't connect to database: <esql:get-message/></error>
     </esql:error-results>
   ..
=============
at <esql:connection> level? 

Of cource, I could catch this in /*<xsp:logic>try{}cathc</xsp:logic>*/ 
but would not this make the error-handling more straightforward?

4) we're running an unreliable database and are quite limited on the licenses. 
And caching quite suits our needs.
So we have reasons to open and close jdbc connections every time the
xsp is executed.
Is it possible to 
have some tag like <esql:pool> (<esql:nopool>?) that would have the following
result:
it would accept the same values as <esql:pool> but would extract
dburl user and pass from where they are stored and open connection?
So we wouldn't have to give dburl, user and pass everywhere, just the "name" of
database configuration but still we would have NO connection pooling?

Best Regards, 
Tagunov Anthony



Mime
View raw message