You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Donald Ball <ba...@webslingerZ.com> on 2000/11/06 20:09:11 UTC
draft final version of the esql namespace
after much discussion and cogitation, i submit the following pseudoschema
as the proposed final skeleton of the esql namespace:
<esql:connection>
<esql:driver>org.postgresql.Driver</esql:driver>
<esql:dburl>jdbc:postgresql://localhost/test</esql:dburl>
<esql:username>test</esql:username>
<esql:password>test</esql:password>
<esql:execute-query>
<esql:query>select id,name from department_table</esql:query>
<esql:results>
<header>header info</header>
<esql:row-results>
<id><esql:get-int column="id"/></id>
<name><esql:get-string column="name"/></name>
</esql:row-results>
<footer>footer info</footer>
</esql:results>
<esql:update-results>
there were <esql:get-updated-rows/> rows updated
</esql:update-results>
<esql:error-results>
the query failed for some reason: <esql:get-message/>
</esql:error-results>
</esql:execute-query>
</esql:connection>
conformant implementations shall work as follows:
1. connections are opened at the start connection element tag and closed
at the end connection element tag.
2. multiple queries may be executed in the same connection
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.
4. if a query returns a number of rows, the children of the update-results
element are instantiated.
5. if a query results in a sql error and an error-results element exists,
its children are instantiated and the processor will attempt to
continue.
6. the execute-query and connection elements may appear underneath the
results, row-results, update-results, or connection elements.
comments and suggestions are welcome. if everything thinks this is okay,
i'll flesh out the namespace with all of the extras (max-rows, get-xml,
etc.) begin writing a formal schema for this and bring the c1 and c2
implementations into line with the specification.
- donald
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 7 Nov 2000, Nicola Ken Barozzi wrote:
> I thought that maybe different "taglibs" per SQL command could have
> been better, but the SQL is a string you cannot control, and people
> might end putting INSERT in a SELECT execution tag! :-P
i think you've got a good argument there, it's just not in line with what
i needed. i think you could write such a logicsheet as a wrapper around
the esql logicsheet if you wanted to, tho.
- donald
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 7 Nov 2000, Nicola Ken Barozzi wrote:
> I thought that maybe different "taglibs" per SQL command could have
> been better, but the SQL is a string you cannot control, and people
> might end putting INSERT in a SELECT execution tag! :-P
i think you've got a good argument there, it's just not in line with what
i needed. i think you could write such a logicsheet as a wrapper around
the esql logicsheet if you wanted to, tho.
- donald
Re: draft final version of the esql namespace
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
From: "Donald Ball" <ba...@webslingerZ.com>
> after much discussion and cogitation, i submit the following pseudoschema
> as the proposed final skeleton of the esql namespace:
>
> <esql:connection>
> <esql:driver>org.postgresql.Driver</esql:driver>
> <esql:dburl>jdbc:postgresql://localhost/test</esql:dburl>
> <esql:username>test</esql:username>
> <esql:password>test</esql:password>
> <esql:execute-query>
> <esql:query>select id,name from department_table</esql:query>
> <esql:results>
> <header>header info</header>
> <esql:row-results>
> <id><esql:get-int column="id"/></id>
> <name><esql:get-string column="name"/></name>
> </esql:row-results>
> <footer>footer info</footer>
> </esql:results>
> <esql:update-results>
> there were <esql:get-updated-rows/> rows updated
> </esql:update-results>
> <esql:error-results>
> the query failed for some reason: <esql:get-message/>
> </esql:error-results>
> </esql:execute-query>
> </esql:connection>
>
> conformant implementations shall work as follows:
>
> 1. connections are opened at the start connection element tag and closed
> at the end connection element tag.
>
> 2. multiple queries may be executed in the same connection
>
> 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.
>
> 4. if a query returns a number of rows, the children of the update-results
> element are instantiated.
>
> 5. if a query results in a sql error and an error-results element exists,
> its children are instantiated and the processor will attempt to
> continue.
>
> 6. the execute-query and connection elements may appear underneath the
> results, row-results, update-results, or connection elements.
>
> comments and suggestions are welcome. if everything thinks this is okay,
> i'll flesh out the namespace with all of the extras (max-rows, get-xml,
> etc.) begin writing a formal schema for this and bring the c1 and c2
> implementations into line with the specification.
I think it's really cool :-)
I thought that maybe different "taglibs" per SQL command could have
been better, but the SQL is a string you cannot control, and people
might end putting INSERT in a SELECT execution tag! :-P
Well, this is also elegant I think.
The tags are in this order:
1-definitions
2-input (query)
3-output(results)
4-info on execution
5-errors
and output has:
3-1-output-begin
3-2-3x-output-cycle(with nestings)
3-3-output-end
I like it! :-)
IMHO it is important that all tags are to be "active" and usable with
every SQL command; the reasons are above.
Good! :-)
nicola_ken
Re: draft final version of the esql namespace
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
From: "Donald Ball" <ba...@webslingerZ.com>
> after much discussion and cogitation, i submit the following pseudoschema
> as the proposed final skeleton of the esql namespace:
>
> <esql:connection>
> <esql:driver>org.postgresql.Driver</esql:driver>
> <esql:dburl>jdbc:postgresql://localhost/test</esql:dburl>
> <esql:username>test</esql:username>
> <esql:password>test</esql:password>
> <esql:execute-query>
> <esql:query>select id,name from department_table</esql:query>
> <esql:results>
> <header>header info</header>
> <esql:row-results>
> <id><esql:get-int column="id"/></id>
> <name><esql:get-string column="name"/></name>
> </esql:row-results>
> <footer>footer info</footer>
> </esql:results>
> <esql:update-results>
> there were <esql:get-updated-rows/> rows updated
> </esql:update-results>
> <esql:error-results>
> the query failed for some reason: <esql:get-message/>
> </esql:error-results>
> </esql:execute-query>
> </esql:connection>
>
> conformant implementations shall work as follows:
>
> 1. connections are opened at the start connection element tag and closed
> at the end connection element tag.
>
> 2. multiple queries may be executed in the same connection
>
> 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.
>
> 4. if a query returns a number of rows, the children of the update-results
> element are instantiated.
>
> 5. if a query results in a sql error and an error-results element exists,
> its children are instantiated and the processor will attempt to
> continue.
>
> 6. the execute-query and connection elements may appear underneath the
> results, row-results, update-results, or connection elements.
>
> comments and suggestions are welcome. if everything thinks this is okay,
> i'll flesh out the namespace with all of the extras (max-rows, get-xml,
> etc.) begin writing a formal schema for this and bring the c1 and c2
> implementations into line with the specification.
I think it's really cool :-)
I thought that maybe different "taglibs" per SQL command could have
been better, but the SQL is a string you cannot control, and people
might end putting INSERT in a SELECT execution tag! :-P
Well, this is also elegant I think.
The tags are in this order:
1-definitions
2-input (query)
3-output(results)
4-info on execution
5-errors
and output has:
3-1-output-begin
3-2-3x-output-cycle(with nestings)
3-3-output-end
I like it! :-)
IMHO it is important that all tags are to be "active" and usable with
every SQL command; the reasons are above.
Good! :-)
nicola_ken
Re: draft final version of the esql namespace
Posted by Herbert Hotz <he...@symmetrix.ch>.
Donald Ball wrote:
> On Wed, 8 Nov 2000, Ulrich Mayring wrote:
>
> > Donald Ball wrote:
> > >
> > > if you're configuring the connection parameters dynamically, you shouldn't
> > > be trying to use connection pooling imho.
> >
> > Ok and why not?
>
> mainly, it just doesn't make sense to me, to pool something that's
> dynamic. however, i'll play along for the moment and ask you the same
> questions i asked in another post. what data would an xsp page have to
> provide to create a new connection pool, and what data would an xsp page
> have to provide to check out a connection from that pool?
>
> i think it's possible to work something out here, though it may not be in
> the scope of the esql namespace per se - the pool maintenance namespace
> could be completely distinct. but we'll see.
>
> - donald
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
Hello esql folks,
As a provider we host many websites from different customers. We want
to offer also appliction services to our customers. So it seems very
natural, that a customer wants to use 'his' databases - even if they
are used by a common (Cocconn :-) application running on one of our
own servers.
Conclusion:
We certainly want to have the possibility to dynamically assign
connection pools. We don't like to have dirver, user, passwort, a.s.o.
hardcoded in the xml pages and even worse in the generated java sources.
If I imagine, that I have first to generate an xml file by some means,
just to make things dynamic, than pipe that xml file through cocoon,
which is compiling the generated source, to finally get the required
database connectivity - I do not feel too comfortable.
So, design esql that way, that it's tomorrow use will not be limited.
Thanks for listening & kind regards
Herbert
--
+----------------------+-------------------------------------------+
| Herbert Hotz | Voice: +41 1 381 8880 |
| Symmetrix AG | Fax: +41 1 381 2127 |
| Muehle Tiefenbrunnen | GSM-SMS: +41 79 402 5704 |
| Seefeldstrasse 231 | URL: http://www.symmetrix.ch/ |
| CH-8008 Zurich | E-Mail: mailto:herbert.hotz@symmetrix.ch |
+----------------------+-------------------------------------------+
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 8 Nov 2000, Peter Verhage wrote:
> Donald Ball wrote:
> > mainly, it just doesn't make sense to me, to pool something that's
> > dynamic. however, i'll play along for the moment and ask you the same
> > questions i asked in another post. what data would an xsp page have to
> > provide to create a new connection pool, and what data would an xsp page
> > have to provide to check out a connection from that pool?
> >
> > i think it's possible to work something out here, though it may not be in
> > the scope of the esql namespace per se - the pool maintenance namespace
> > could be completely distinct. but we'll see.
>
> What if you host different websites, for different companies, which data
> is in different databases...
you declare multiple connection pools in the cocoon.properties or
cocoon.xconf file.
- donald
Re: draft final version of the esql namespace
Posted by Peter Verhage <pe...@ibuildings.nl>.
Donald Ball wrote:
> mainly, it just doesn't make sense to me, to pool something that's
> dynamic. however, i'll play along for the moment and ask you the same
> questions i asked in another post. what data would an xsp page have to
> provide to create a new connection pool, and what data would an xsp page
> have to provide to check out a connection from that pool?
>
> i think it's possible to work something out here, though it may not be in
> the scope of the esql namespace per se - the pool maintenance namespace
> could be completely distinct. but we'll see.
What if you host different websites, for different companies, which data
is in different databases...
--
Peter Verhage <pe...@ibuildings.nl>
ibuildings.nl BV - information technology
http://www.ibuildings.nl - 0118 41 50 54
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 8 Nov 2000, Ulrich Mayring wrote:
> Donald Ball wrote:
> >
> > if you're configuring the connection parameters dynamically, you shouldn't
> > be trying to use connection pooling imho.
>
> Ok and why not?
mainly, it just doesn't make sense to me, to pool something that's
dynamic. however, i'll play along for the moment and ask you the same
questions i asked in another post. what data would an xsp page have to
provide to create a new connection pool, and what data would an xsp page
have to provide to check out a connection from that pool?
i think it's possible to work something out here, though it may not be in
the scope of the esql namespace per se - the pool maintenance namespace
could be completely distinct. but we'll see.
- donald
Re: draft final version of the esql namespace
Posted by Ulrich Mayring <ul...@denic.de>.
Donald Ball wrote:
>
> if you're configuring the connection parameters dynamically, you shouldn't
> be trying to use connection pooling imho.
Ok and why not?
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 7 Nov 2000, Ulrich Mayring wrote:
> Paul Russell wrote:
> >
> > Meta +1 from me. The only thing that occours to me is what
> > if someone wants to use two connections at once? Can we dismiss
> > this as something that people really should avoid anyway?
> > (I don't really like the thought of people running what should
> > be subqueries by using nested executes anyway, to be honest,
> > so I don't think it's a major loss). Thoughts?
>
> What we definitely need is a way to use the connection pooling
> dynamically. By that I mean that username, db url, password etc. can be
> specified dynamically, i.e. not written in clear text in
> cocoon.properties.
if you're configuring the connection parameters dynamically, you shouldn't
be trying to use connection pooling imho.
- donald
Re: draft final version of the esql namespace
Posted by Ulrich Mayring <ul...@denic.de>.
Marcus Crafter wrote:
>
> On Tue, 7 Nov 2000, Ulrich Mayring wrote:
>
> > What we definitely need is a way to use the connection pooling
> > dynamically. By that I mean that username, db url, password etc. can be
> > specified dynamically, i.e. not written in clear text in
> > cocoon.properties.
>
> How do you suggest doing this ? Where would the dburl/password/etc come
> from in a dynamic context, and where would it be specified ?
This should be left to the user. In my case I'd have the user type his
name and password into a web form. I designed the auth taglib for
exactly this purpose.
> If there was a xml pool syntax. ie:
>
> <esql:pool>
> <esql:pooldbname>...</esql:pooldbname>
> ...
> </esql:pool>
>
> this could be done dynamically using xsp or xsl, but where does the
> above get specified ? ie. per file basis, per connection basis (!).
Something like this is what I'm looking for. The SQL processor and
taglib allow me to specify connections information myself - only the
connection pool can't do this, it always refers to cocoon.properties and
I can't use XSP there ;-)
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: draft final version of the esql namespace
Posted by Ulrich Mayring <ul...@denic.de>.
Paul Russell wrote:
>
> Surely if we index into the pools using the dburl, username and
> password (or hashes thereof), there's no problem. If you ask
> for a connection to a certain database and you have the right
> username and password, you get that connection. If you ask for
> a connection to the same database with a different username and
> password, you'll get a different connection pool containing
> connections with different authentication credentials. Am I
> missing something?
I think I haven't understood any of what you said, but probably I am
just too naive and think that pools and connections can be treated the
same way ;-)
Currently the situation with connection pools is that username/password
are written in clear-text in cocoon.properties, right? And you have to
define one pool for every combination of db url, username and password,
right?
This issue doesn't exist with the SQL processor and the SQL taglib,
which are not pool-based, but connection-based. With the SQL processor I
write something like this:
<query connection-name="foo">
<password><xsp:expr>get_username()</xsp:expr></password>
...
</query>
This allows me to supply the password parameter dynamically, e.g.
reading it from the user input. So it is not stored anywhere in
clear-text anymore. I think in the SQL taglib the syntax is different,
but the scheme much the same.
My idea of how the connection pool should work is that it should work
like my auth taglib. Of course this is pretty self-serving, but I just
don't have a better idea. Here is what the auth taglib does:
1) The user authenticates successfully and a session is started. The
login page contains a specific tag, which states that the page belongs
to a named set of XML pages. Let's say this set is called "mypages".
This string is put into the session object as authentication ID.
2) The user calls up a page, which states that it belongs to the set
"mypages". The auth taglib sees that tag and checks if "mypages" is
equal to the authentication ID from the session object. If that is the
case, then the page's content is processed, if not, the user is taken
back to the login page.
The good thing is that during step 1) not only the authentication ID,
but any arbitrary data can be put into the session object. For example
the username/password that the user typed in. If the user performs
connection-based db queries on subsequent pages belonging to the
"mypages" set, then username/password can be read out from the session
object and put dynamically into the query statement like shown above.
So, only authenticated users can perform the db queries, because only
after successful authentication are username/password put into the
session object. But at the same time I don't have to write
username/password in clear-text into the db query's connection tag, I
just write something like get_username() or, in the case of the auth
taglib, I write <auth:var name="username"/>.
The same method as in steps 1) and 2) above could be used for the
connection pool. It could have a name, say "mypool". This string is put
into the session object. On subsequent pages, where the pool is used by
referring to its name, the given name is compared to the string in the
session object. I'll happily implement a sample showing this technique
with the auth taglib.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: draft final version of the esql namespace
Posted by Paul Russell <pa...@luminas.co.uk>.
On Thu, Nov 09, 2000 at 10:10:14AM +0000, Ulrich Mayring wrote:
> This is a shortcoming of the current design. You can guess a name or
> look it up in cocoon.properties. But if you designed a pool such that
> password and username have to be supplied dynamically, this problem goes
> away.
Surely if we index into the pools using the dburl, username and
password (or hashes thereof), there's no problem. If you ask
for a connection to a certain database and you have the right
username and password, you get that connection. If you ask for
a connection to the same database with a different username and
password, you'll get a different connection pool containing
connections with different authentication credentials. Am I
missing something?
Paul
--
Paul Russell <pa...@luminas.co.uk>
Technical Director, http://www.luminas.co.uk
Luminas Ltd.
Re: draft final version of the esql namespace
Posted by Uli Mayring <ul...@denic.de>.
On Thu, 9 Nov 2000, Donald Ball wrote:
> i look forward to seeing what y'all come up with. :)
Donald, you are evil ;-)
But, of course, you are right. It's pretty hard for me to come up with a
better idea than the one I sketched in another posting and that is
modelled after the auth taglib I did. This is not because the auth taglib
is so brilliant, but because I don't know cocoon well enough to really be
useful in proposing design changes.
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Thu, 9 Nov 2000, Ulrich Mayring wrote:
> Donald Ball wrote:
> >
> > okay, so what happens if two xsp pages choose the same pool name?
>
> Then they both access the same pool - is this a problem?
if they're both trying to create a new named pool? yes, that is a big
problem.
> > or what
> > happens if a malicious xsp page attempts to get a connection from a
> > privileged pool by guessing its name?
>
> This is a shortcoming of the current design. You can guess a name or
> look it up in cocoon.properties. But if you designed a pool such that
> password and username have to be supplied dynamically, this problem goes
> away.
i look forward to seeing what y'all come up with. :)
- donald
Re: draft final version of the esql namespace
Posted by Ulrich Mayring <ul...@denic.de>.
Donald Ball wrote:
>
> okay, so what happens if two xsp pages choose the same pool name?
Then they both access the same pool - is this a problem?
> or what
> happens if a malicious xsp page attempts to get a connection from a
> privileged pool by guessing its name?
This is a shortcoming of the current design. You can guess a name or
look it up in cocoon.properties. But if you designed a pool such that
password and username have to be supplied dynamically, this problem goes
away.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: draft final version of the esql namespace
Posted by David Halsted <ha...@tcimet.net>.
> okay, so what happens if two xsp pages choose the same pool name? or what
> happens if a malicious xsp page attempts to get a connection from a
> privileged pool by guessing its name? i think there's a whole slew of
> issues here to address that i'd rather not get into yet. i think i'm going
> to make the executive decision (ha!) that connection pool creation
> semantics are outside of the esql namespace, at least right now. esql
> pages may retrieve connections from a named pool, possibly by
> authenticating themselves with a password. the mechanism by which pools
> are declared, created, and/or managed is (for now) outside the scope of
> the esql specification.
>
> i encourage those of y'all who are interested in connection pooling,
> dynamic or otherwise, to get together and figure out these issues - what
> the backend should be (avalon, turbine, whatever), how to create pools
> (static and/or dynamic), etc. for the time being, i'll keep using the
> turbine pool, but i have no objections to switching the backends if y'all
> pick something else.
>
> cool with everyone?
>
> - donald
Fair enough on all counts, as far as I'm concerned. I'll keep thinking
about it. It's not as pressing an issue for me as it seems to be for some
other folks, but I'd be glad to be involved in working on a pooling solution
if others are interested in doing something more immediately. Thanks for
taking the time to work this one through a little, Donald.
Dave Halsted
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 8 Nov 2000, David Halsted wrote:
> > hmm. then what information does an xsp page have to provide in order to
> > create a new connection pool? by the same token, what information does an
> > xsp page have to provide in order to check out a pooled connection?
> >
> > - donald
>
> I haven't really thought this through carefully, but perhaps -- the usual
> logon information (driver, URL, etc) plus minimum and maximum pool size and
> timeout to create a pool, plus a pool name so you can get connections from
> it. In a perfect world, perhaps you would be able to specify how much
> information would be required to get a connection, so that some pools would
> let you get a connection simply by providing the correct pool name, while
> others would need to know a user name and logon. Or something like that.
okay, so what happens if two xsp pages choose the same pool name? or what
happens if a malicious xsp page attempts to get a connection from a
privileged pool by guessing its name? i think there's a whole slew of
issues here to address that i'd rather not get into yet. i think i'm going
to make the executive decision (ha!) that connection pool creation
semantics are outside of the esql namespace, at least right now. esql
pages may retrieve connections from a named pool, possibly by
authenticating themselves with a password. the mechanism by which pools
are declared, created, and/or managed is (for now) outside the scope of
the esql specification.
i encourage those of y'all who are interested in connection pooling,
dynamic or otherwise, to get together and figure out these issues - what
the backend should be (avalon, turbine, whatever), how to create pools
(static and/or dynamic), etc. for the time being, i'll keep using the
turbine pool, but i have no objections to switching the backends if y'all
pick something else.
cool with everyone?
- donald
Re: Cocoon Graphing Capability
Posted by Ulrich Mayring <ul...@denic.de>.
Ross Burton wrote:
>
> Cocoon 2 has SVG support built in - it can generate an image file from a
> SVG. Also search IBM's DeveloperWorks web site, they have an example of
> generating graphs from XML data.
Are you duplicating efforts with the fop group? Where does the SVG in
cocoon2 come from?
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: Cocoon Graphing Capability
Posted by Ross Burton <ro...@lineone.net>.
On Thu, 9 Nov 2000, Ulrich Mayring wrote:
> Jamie Mascherino wrote:
> >
> > Has anyone ever used Cocoon to do graphing? I need to plot a series of x
> > and y axis from different functions. Does Cocoon have any such
> > capabilities? I know graphing is possible with HTML, but has anyone had much
> > experience.
>
> Look at SVG support in fop - however, I don't know if the newer fop
> versions work with cocoon and I think the fop version supplied with
> cocoon doesn't do much SVG.
Cocoon 2 has SVG support built in - it can generate an image file from a
SVG. Also search IBM's DeveloperWorks web site, they have an example of
generating graphs from XML data.
Ross Burton
Re: Cocoon Graphing Capability
Posted by Ulrich Mayring <ul...@denic.de>.
Jamie Mascherino wrote:
>
> Has anyone ever used Cocoon to do graphing? I need to plot a series of x
> and y axis from different functions. Does Cocoon have any such
> capabilities? I know graphing is possible with HTML, but has anyone had much
> experience.
Look at SVG support in fop - however, I don't know if the newer fop
versions work with cocoon and I think the fop version supplied with
cocoon doesn't do much SVG.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
RE: Cocoon Graphing Capability
Posted by Simon Wilks <si...@enterprisefusion.com>.
Hi Jamie,
How about using an XML graphics format: SVG
More info under: http://www.w3.org/Graphics/SVG/Overview.htm8 or for another
angle look at:
http://www.sun.com/smi/Press/sunflash/2000-08/sunflash.20000802.1.html
Here's an extract from the W3C page:
What is it
SVG is a language for describing two-dimensional graphics in XML. SVG allows
for three types of graphic objects: vector graphic shapes (e.g., paths
consisting of straight lines and curves), images and text. Graphical objects
can be grouped, styled, transformed and composited into previously rendered
objects. Text can be in any XML namespace suitable to the appplication,
which enhances searchability and accessibility of the SVG graphics. The
feature set includes nested transformations, clipping paths, alpha masks,
filter effects, template objects and extensibility.
SVG drawings can be dynamic and interactive. The Document Object Model (DOM)
for SVG, which includes the full XML DOM, allows for straightforward and
efficient vector graphics animation via scripting. A rich set of event
handlers such as onmouseover and onclick can be assigned to any SVG
graphical object. Because of its compatibility and leveraging of other Web
standards, features like scripting can be done on SVG elements and other XML
elements from different namespaces simultaneously within the same Web page.
Hope it helps,
Simon.
-----Ursprungliche Nachricht-----
Von: Jamie Mascherino [mailto:jmascherino@learnframe.com]
Gesendet: Donnerstag, 9. November 2000 01:19
An: cocoon-users@xml.apache.org
Betreff: Cocoon Graphing Capability
Has anyone ever used Cocoon to do graphing? I need to plot a series of x
and y axis from different functions. Does Cocoon have any such
capabilities? I know graphing is possible with HTML, but has anyone had much
experience.
Thanks!
Jamie L. Mascherino
Learnframe, Inc.
Salt Lake City, Utah
jmascherino@learnframe.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
For additional commands, e-mail: cocoon-users-help@xml.apache.org
Cocoon Graphing Capability
Posted by Jamie Mascherino <jm...@learnframe.com>.
Has anyone ever used Cocoon to do graphing? I need to plot a series of x
and y axis from different functions. Does Cocoon have any such
capabilities? I know graphing is possible with HTML, but has anyone had much
experience.
Thanks!
Jamie L. Mascherino
Learnframe, Inc.
Salt Lake City, Utah
jmascherino@learnframe.com
Re: draft final version of the esql namespace
Posted by Uli Mayring <ul...@denic.de>.
On Wed, 8 Nov 2000, David Halsted wrote:
> The thing is, it'd be nice to be able to have it both ways -- hold
> persistent information about pools you want to keep around in a conf file
> somewhere and have those get created at init, and have these "dynamic" pools
> wandering around as well, with the ability to create them, get connections
> from them and destroy them on an as-needed basis. Is something like that
> possible?
It would be pretty cool, then you could design apps, where the users have
to log in first and then can use a connection pool. This is currently not
possible, unless you want to have a pool definition for each possible user
in your cocoon.properties.
Ulrich
--
Ulrich Mayring
DENIC eG, Softwareentwicklung
Re: draft final version of the esql namespace
Posted by David Halsted <ha...@tcimet.net>.
> hmm. then what information does an xsp page have to provide in order to
> create a new connection pool? by the same token, what information does an
> xsp page have to provide in order to check out a pooled connection?
>
> - donald
I haven't really thought this through carefully, but perhaps -- the usual
logon information (driver, URL, etc) plus minimum and maximum pool size and
timeout to create a pool, plus a pool name so you can get connections from
it. In a perfect world, perhaps you would be able to specify how much
information would be required to get a connection, so that some pools would
let you get a connection simply by providing the correct pool name, while
others would need to know a user name and logon. Or something like that.
The thing is, it'd be nice to be able to have it both ways -- hold
persistent information about pools you want to keep around in a conf file
somewhere and have those get created at init, and have these "dynamic" pools
wandering around as well, with the ability to create them, get connections
from them and destroy them on an as-needed basis. Is something like that
possible?
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 8 Nov 2000, David Halsted wrote:
> > i'd prefer for the pools to be declared outside of the esql namespace -
> > outside of the xsp pages entirely. cocoon.xconf would be the logical
> > place, or sitemap.xconf. i don't think it makes sense for connection pool
> > parameters to be specified dynamically.
> >
> > - donald
>
> It might be handy for some things, though. I'm building a Web app for a
> client now that will be installed on machines by their customers, so I can't
> know in advance how the customers will want to manage database connections.
> In the future it might be nice to make pooling an option for them, and
> having the ability to set the parameters in the pools dynamically would give
> me more flexibility in creating connection management schemes,
> administrative structures and user interfaces.
hmm. then what information does an xsp page have to provide in order to
create a new connection pool? by the same token, what information does an
xsp page have to provide in order to check out a pooled connection?
- donald
Re: draft final version of the esql namespace
Posted by David Halsted <ha...@tcimet.net>.
> i'd prefer for the pools to be declared outside of the esql namespace -
> outside of the xsp pages entirely. cocoon.xconf would be the logical
> place, or sitemap.xconf. i don't think it makes sense for connection pool
> parameters to be specified dynamically.
>
> - donald
It might be handy for some things, though. I'm building a Web app for a
client now that will be installed on machines by their customers, so I can't
know in advance how the customers will want to manage database connections.
In the future it might be nice to make pooling an option for them, and
having the ability to set the parameters in the pools dynamically would give
me more flexibility in creating connection management schemes,
administrative structures and user interfaces.
Dave Halsted
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 7 Nov 2000, Marcus Crafter wrote:
> On Tue, 7 Nov 2000, Ulrich Mayring wrote:
>
> > What we definitely need is a way to use the connection pooling
> > dynamically. By that I mean that username, db url, password etc. can be
> > specified dynamically, i.e. not written in clear text in
> > cocoon.properties.
>
> How do you suggest doing this ? Where would the dburl/password/etc come
> from in a dynamic context, and where would it be specified ?
>
> If there was a xml pool syntax. ie:
>
> <esql:pool>
> <esql:pooldbname>...</esql:pooldbname>
> ...
> </esql:pool>
>
> this could be done dynamically using xsp or xsl, but where does the
> above get specified ? ie. per file basis, per connection basis (!).
i'd prefer for the pools to be declared outside of the esql namespace -
outside of the xsp pages entirely. cocoon.xconf would be the logical
place, or sitemap.xconf. i don't think it makes sense for connection pool
parameters to be specified dynamically.
- donald
Re: draft final version of the esql namespace
Posted by Marcus Crafter <cr...@dresdnerbank.de>.
On Tue, 7 Nov 2000, Ulrich Mayring wrote:
> What we definitely need is a way to use the connection pooling
> dynamically. By that I mean that username, db url, password etc. can be
> specified dynamically, i.e. not written in clear text in
> cocoon.properties.
How do you suggest doing this ? Where would the dburl/password/etc come
from in a dynamic context, and where would it be specified ?
If there was a xml pool syntax. ie:
<esql:pool>
<esql:pooldbname>...</esql:pooldbname>
...
</esql:pool>
this could be done dynamically using xsp or xsl, but where does the
above get specified ? ie. per file basis, per connection basis (!).
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&: After Hours : +49 69 49086750
Re: draft final version of the esql namespace
Posted by Ulrich Mayring <ul...@denic.de>.
Paul Russell wrote:
>
> Meta +1 from me. The only thing that occours to me is what
> if someone wants to use two connections at once? Can we dismiss
> this as something that people really should avoid anyway?
> (I don't really like the thought of people running what should
> be subqueries by using nested executes anyway, to be honest,
> so I don't think it's a major loss). Thoughts?
What we definitely need is a way to use the connection pooling
dynamically. By that I mean that username, db url, password etc. can be
specified dynamically, i.e. not written in clear text in
cocoon.properties.
Ulrich
--
Ulrich Mayring
DENIC eG, Systementwicklung
Re: draft final version of the esql namespace
Posted by Marcus Crafter <cr...@dresdnerbank.de>.
Hi Donald,
On Mon, 6 Nov 2000, Donald Ball wrote:
> On Mon, 6 Nov 2000, David Halsted wrote:
>
> > Also (I hope I haven't missed an earlier part of the discussion, or
> > something that's in the proposal) what about connection pooling? I don't
> > see immediately how this will handle that?
>
> replace <esql:driver>, et. al. with <esql:pool> to select a connection
> pool by name from whatever mechanism is provided by the esql processor.
> that doesn't really affect the structure of the namespace, which is why i
> omitted it here for simplicity.
How would we like the pool to be configured (min/max/grow size, host,
driver, etc). Where should all this be defined.
For the Cocoon 1 folks I presume cocoon.properties is the obvious
choice. For Cocoon 2 however, where do you think (cocoon.xconf, sitemap
?) is best.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&: After Hours : +49 69 49086750
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 6 Nov 2000, David Halsted wrote:
> Also (I hope I haven't missed an earlier part of the discussion, or
> something that's in the proposal) what about connection pooling? I don't
> see immediately how this will handle that?
replace <esql:driver>, et. al. with <esql:pool> to select a connection
pool by name from whatever mechanism is provided by the esql processor.
that doesn't really affect the structure of the namespace, which is why i
omitted it here for simplicity.
- donald
Re: draft final version of the esql namespace
Posted by David Halsted <ha...@tcimet.net>.
Also (I hope I haven't missed an earlier part of the discussion, or
something that's in the proposal) what about connection pooling? I don't
see immediately how this will handle that?
Dave Halsted
----- Original Message -----
From: Donald Ball <ba...@webslingerZ.com>
To: <co...@xml.apache.org>
Cc: <ma...@sergeant.org>
Sent: Monday, November 06, 2000 7:33 PM
Subject: Re: draft final version of the esql namespace
> On Mon, 6 Nov 2000, Paul Russell wrote:
>
> > > <esql:connection>
> > > <esql:driver>org.postgresql.Driver</esql:driver>
> > > <esql:dburl>jdbc:postgresql://localhost/test</esql:dburl>
> > > <esql:username>test</esql:username>
> > > <esql:password>test</esql:password>
> > > <esql:execute-query>
> > > <esql:query>select id,name from department_table</esql:query>
> > > <esql:results>
> > > <header>header info</header>
> > > <esql:row-results>
> > > <id><esql:get-int column="id"/></id>
> > > <name><esql:get-string column="name"/></name>
> > > </esql:row-results>
> > > <footer>footer info</footer>
> > > </esql:results>
> > > <esql:update-results>
> > > there were <esql:get-updated-rows/> rows updated
> > > </esql:update-results>
> > > <esql:error-results>
> > > the query failed for some reason: <esql:get-message/>
> > > </esql:error-results>
> > > </esql:execute-query>
> > > </esql:connection>
> >
> > Meta +1 from me. The only thing that occours to me is what
> > if someone wants to use two connections at once? Can we dismiss
> > this as something that people really should avoid anyway?
> > (I don't really like the thought of people running what should
> > be subqueries by using nested executes anyway, to be honest,
> > so I don't think it's a major loss). Thoughts?
>
> it's allowed by the current rules:
>
> <esql:connection>
> <esql:driver>org.postgresql.Driver</esql:driver>
> <esql:dburl>jdbc:postgresql://localhost/test</esql:dburl>
> <esql:username>test</esql:username>
> <esql:password>test</esql:password>
> <esql:execute-query>
> <esql:query>select id,name from department_table</esql:query>
> <esql:results>
> <esql:row-results>
> <id><esql:get-int column="id"/></id>
> <name><esql:get-string column="name"/></name>
> <employees>
> <esql:connection>
> <esql:driver>org.postgresql.Driver</esql:driver>
> <esql:dburl>jdbc:postgresql://localhost/employees</esql:dburl>
> <esql:username>employees</esql:username>
> <esql:password>employees</esql:password>
> <esql:execute-query>
> ...
> </esql:execute-query>
> </esql:connection>
> </esql:connection>
> </esql:row-results>
> </esql:results>
> </esql:execute-query>
> </esql:connection>
>
> a similar configuration actually works with the current c1 and c2
> logicsheets. i don't especially like it, and boy, it makes the code more
> complex, but i think it's more or less mandatory.
>
> - donald
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 6 Nov 2000, Paul Russell wrote:
> > <esql:connection>
> > <esql:driver>org.postgresql.Driver</esql:driver>
> > <esql:dburl>jdbc:postgresql://localhost/test</esql:dburl>
> > <esql:username>test</esql:username>
> > <esql:password>test</esql:password>
> > <esql:execute-query>
> > <esql:query>select id,name from department_table</esql:query>
> > <esql:results>
> > <header>header info</header>
> > <esql:row-results>
> > <id><esql:get-int column="id"/></id>
> > <name><esql:get-string column="name"/></name>
> > </esql:row-results>
> > <footer>footer info</footer>
> > </esql:results>
> > <esql:update-results>
> > there were <esql:get-updated-rows/> rows updated
> > </esql:update-results>
> > <esql:error-results>
> > the query failed for some reason: <esql:get-message/>
> > </esql:error-results>
> > </esql:execute-query>
> > </esql:connection>
>
> Meta +1 from me. The only thing that occours to me is what
> if someone wants to use two connections at once? Can we dismiss
> this as something that people really should avoid anyway?
> (I don't really like the thought of people running what should
> be subqueries by using nested executes anyway, to be honest,
> so I don't think it's a major loss). Thoughts?
it's allowed by the current rules:
<esql:connection>
<esql:driver>org.postgresql.Driver</esql:driver>
<esql:dburl>jdbc:postgresql://localhost/test</esql:dburl>
<esql:username>test</esql:username>
<esql:password>test</esql:password>
<esql:execute-query>
<esql:query>select id,name from department_table</esql:query>
<esql:results>
<esql:row-results>
<id><esql:get-int column="id"/></id>
<name><esql:get-string column="name"/></name>
<employees>
<esql:connection>
<esql:driver>org.postgresql.Driver</esql:driver>
<esql:dburl>jdbc:postgresql://localhost/employees</esql:dburl>
<esql:username>employees</esql:username>
<esql:password>employees</esql:password>
<esql:execute-query>
...
</esql:execute-query>
</esql:connection>
</esql:connection>
</esql:row-results>
</esql:results>
</esql:execute-query>
</esql:connection>
a similar configuration actually works with the current c1 and c2
logicsheets. i don't especially like it, and boy, it makes the code more
complex, but i think it's more or less mandatory.
- donald
Re: draft final version of the esql namespace
Posted by Paul Russell <pa...@luminas.co.uk>.
On Mon, Nov 06, 2000 at 02:09:11PM -0500, Donald Ball wrote:
> after much discussion and cogitation, i submit the following pseudoschema
> as the proposed final skeleton of the esql namespace:
>
> <esql:connection>
> <esql:driver>org.postgresql.Driver</esql:driver>
> <esql:dburl>jdbc:postgresql://localhost/test</esql:dburl>
> <esql:username>test</esql:username>
> <esql:password>test</esql:password>
> <esql:execute-query>
> <esql:query>select id,name from department_table</esql:query>
> <esql:results>
> <header>header info</header>
> <esql:row-results>
> <id><esql:get-int column="id"/></id>
> <name><esql:get-string column="name"/></name>
> </esql:row-results>
> <footer>footer info</footer>
> </esql:results>
> <esql:update-results>
> there were <esql:get-updated-rows/> rows updated
> </esql:update-results>
> <esql:error-results>
> the query failed for some reason: <esql:get-message/>
> </esql:error-results>
> </esql:execute-query>
> </esql:connection>
Meta +1 from me. The only thing that occours to me is what
if someone wants to use two connections at once? Can we dismiss
this as something that people really should avoid anyway?
(I don't really like the thought of people running what should
be subqueries by using nested executes anyway, to be honest,
so I don't think it's a major loss). Thoughts?
Paul
--
Paul Russell <pa...@luminas.co.uk>
Technical Director, http://www.luminas.co.uk
Luminas Ltd.
Re: draft final version of the esql namespace
Posted by Marcus Crafter <cr...@dresdnerbank.de>.
On Wed, 8 Nov 2000, Donald Ball wrote:
> On Wed, 8 Nov 2000, Marco Pauck wrote:
>
> > OK, it's *possible* this way but IMHO *ugly*!
> >
> > With the current version of esql you can simply write:
> >
> > <esql:execute-query>
> > <esql:query>select whatever from whereever</esql:query>
> > <esql:results>
> > <p>The following matches were found ...</p>
> > </esql:results>
> > <esql:no-results>
> > <p>Sorry, no matches were found.</p>
> > </esql:no-results>
> > </esql:execute-query>
> >
> > Using the new esql with the proposed changes this would become:
> >
> > <esql:execute-query>
> > <esql:query>select whatever from whereever</esql:query>
> > <esql:results>
> > <xsp:logic>
> > if (<esql:get-row-count/>!=0) {
> > <p>The following matches were found ...</p>
> > }
> > else {
> > <p>Sorry, no matches were found.</p>
> > }
> > </xsp:logic>
> > </esql:results>
> > </esql:execute-query>
> >
> > IMHO, the later version with the interspersed Java code is a step
> > backwards ...
>
> you don't have to do this with java code. you can do this styling in the
> stylesheet. that is to say, in your xslt pass after this (which you're
> very likely to be doing) you can check to see if any of the row-results
> elements have been instantiated and generate the appropriate message based
> on their presence or absence. however, that _is_ sort of contrary to the
> point of the esql logicsheet (allowing you to generate complex xml results
> from sql queries without having to resort to xslt after the fact)...
>
> does anyone else have an opinion here?
Well, I like the readability of the first example. It looks clean,
and is easier for a non-programmer to interpret, and even though
having the no-results tag available doesn't force anyone to use it -
I must say I agree with what donald is saying here.
One of the huge benefits of using xml/xsl/cocoon is that you can
separate your logic from your presentation, in fine grain steps.
Embedding html inside sql based markup IMHO is ignoring the power
cocoon gives us.
Doing the check for results in a stylesheet does mean a little extra
work, but it puts all of your presentation code or whatever code you're
writing at that stage of the pipeline into one module (in this case
file), and not over multiple. For maintenance I see this as being a
big plus.
Just my 2c. :-)
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&: After Hours : +49 69 49086750
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 8 Nov 2000, Marco Pauck wrote:
> OK, it's *possible* this way but IMHO *ugly*!
>
> With the current version of esql you can simply write:
>
> <esql:execute-query>
> <esql:query>select whatever from whereever</esql:query>
> <esql:results>
> <p>The following matches were found ...</p>
> </esql:results>
> <esql:no-results>
> <p>Sorry, no matches were found.</p>
> </esql:no-results>
> </esql:execute-query>
>
> Using the new esql with the proposed changes this would become:
>
> <esql:execute-query>
> <esql:query>select whatever from whereever</esql:query>
> <esql:results>
> <xsp:logic>
> if (<esql:get-row-count/>!=0) {
> <p>The following matches were found ...</p>
> }
> else {
> <p>Sorry, no matches were found.</p>
> }
> </xsp:logic>
> </esql:results>
> </esql:execute-query>
>
> IMHO, the later version with the interspersed Java code is a step
> backwards ...
you don't have to do this with java code. you can do this styling in the
stylesheet. that is to say, in your xslt pass after this (which you're
very likely to be doing) you can check to see if any of the row-results
elements have been instantiated and generate the appropriate message based
on their presence or absence. however, that _is_ sort of contrary to the
point of the esql logicsheet (allowing you to generate complex xml results
from sql queries without having to resort to xslt after the fact)...
does anyone else have an opinion here?
- donald
Re: draft final version of the esql namespace
Posted by Marco Pauck <pa...@wmd.de>.
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.
>
> if you're looking to perform an xsp action based on an empty row set, you
> could check the esql:get-row-count element in the results footer:
>
> <esql:results>
> <my:results>
> <my:header>woo hoo</my:header>
> <esql:row-results>
> <my:value><esql:get-string column="1"/></my:value>
> </esql:row-results>
> <my:footer>hoo woo</my:footer>
> <xsp:logic>
> if (<esql:get-row-count/>==0) {
> // my action occurs here
> }
> </xsp:logic>
> </my:results>
> </esql:results>
>
> is there a situation you can describe which is possible with no-results
> which is not possible without it, using the methods i've described?
OK, it's *possible* this way but IMHO *ugly*!
With the current version of esql you can simply write:
<esql:execute-query>
<esql:query>select whatever from whereever</esql:query>
<esql:results>
<p>The following matches were found ...</p>
</esql:results>
<esql:no-results>
<p>Sorry, no matches were found.</p>
</esql:no-results>
</esql:execute-query>
Using the new esql with the proposed changes this would become:
<esql:execute-query>
<esql:query>select whatever from whereever</esql:query>
<esql:results>
<xsp:logic>
if (<esql:get-row-count/>!=0) {
<p>The following matches were found ...</p>
}
else {
<p>Sorry, no matches were found.</p>
}
</xsp:logic>
</esql:results>
</esql:execute-query>
IMHO, the later version with the interspersed Java code is a step backwards ...
> > > 4. if a query returns a number of rows, the children of the update-results
> > > element are instantiated.
> >
> > I guess you mean "if an update affects a number of rows", right?
>
> no, i mean if a query returns a number of rows. straight from the JDBC API
> - statement provides a method called getUpdateCount, which returns the
> number of rows updated (read: inserted, modified, deleted, whatever) by
> the query.
OK.
> > And what about inserts?
> > Right now (well, 1.22) neither <esql:results> nor <esql:no-results>
> > are instantiated, so there's no way to find out if the insert was
> > successful and how many rows were affected!
>
> right. obvious failing in that version of the logicsheet.
OK, as I understand, with <esql:get-updated-rows/> this will now
be possible.
> > When working with MySQL, this gets even worse as an insert attempt
> > of data that violates a unique key constraint doesn't result in an
> > sql error (as with e.g. Oracle) but simply returns a "0 rows affected".
> > So, how about a <esql:insert-results>?
>
> there's no need to clutter up the namespace with extraneous results
> elements. the JDBC API provides two types of results from queries -
> resultsets, and update counts. (some weird queries can return multiple
> resultsets and/or update counts, but we're sort of ignoring them
> still.) three result types if you count SQLExceptions. so i'm providing
> three results elements to be instantiated for each of the three cases.
OK.
> > But now the real problem: ;-)
> > In both cases, update as well as insert, it would be very helpful to
> > have separate elements for the cases "some rows affected" and "no rows
> > affected" as it is (or was) the case for queries (see discussion above).
>
> again, like in no-results above, you can put in your own xsp:expr or
> xsp:logic to switch on esql:get-update-count.
True, but ... s.a.
> > 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?
Yes, thanks for the comprehensive elaboration.
> - donald
Marco
Re: draft final version of the esql namespace
Posted by Matt Sergeant <ma...@sergeant.org>.
One more thing...
What about converting the character set that the data comes back in? Or
does JDBC do that automatically for you? (DBI doesn't, FWIW).
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 8 Nov 2000, Marco Pauck wrote:
> > having cogitated
> > for a bit, i'm leaning back towards no-results, but i'd like to hear from
> > other users.
>
> <putting-my-hand-on-the-colt-under-my-coat>
> I'm pretty sure there will be no other opinions, RIGHT?!
> </putting-my-hand-on-the-colt-under-my-coat>
>
> > can't wait to stop discussing and start coding. :)
>
> C'mon, don't wait, hurry up! ;-)
well, see, that's what i did, what, four times already? i figured this
time i'd try to, well, _design_ it first. radical idea, i know... :)
- donald
Re: draft final version of the esql namespace
Posted by Marco Pauck <pa...@wmd.de>.
Donald Ball wrote:
>
> On Wed, 8 Nov 2000, Matt Sergeant wrote:
>
> > On Wed, 8 Nov 2000, Marco Pauck wrote:
> >
> > > > 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.
> >
> > Having seen your example, I see both sides now :)
> >
> > Its a fine line between bloating the esql: namespace. For example, your
> > example could trivially be coded in an esqlu (esql-utils) namespace. It
> > depends what the aim is - to provide everything you could want to do with
> > esql, or to provide a framework with which to build those
> > things... Donald?
>
> i aim to strike an uneasy balance, resulting in a namespace which pisses
> everyone off equally. :) naw, seriously, the idea is to be able to
> generate fairly complex xml from sql queries without having to resort to
> using xslt for structural manipulation (the ability to invoke logic blocks
> using esql was an unexpected but awesome side effect).
Exactly my opinion!
> having cogitated
> for a bit, i'm leaning back towards no-results, but i'd like to hear from
> other users.
<putting-my-hand-on-the-colt-under-my-coat>
I'm pretty sure there will be no other opinions, RIGHT?!
</putting-my-hand-on-the-colt-under-my-coat>
> can't wait to stop discussing and start coding. :)
C'mon, don't wait, hurry up! ;-)
> - donald
Marco
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 8 Nov 2000, Matt Sergeant wrote:
> On Wed, 8 Nov 2000, Marco Pauck wrote:
>
> > > 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.
>
> Having seen your example, I see both sides now :)
>
> Its a fine line between bloating the esql: namespace. For example, your
> example could trivially be coded in an esqlu (esql-utils) namespace. It
> depends what the aim is - to provide everything you could want to do with
> esql, or to provide a framework with which to build those
> things... Donald?
i aim to strike an uneasy balance, resulting in a namespace which pisses
everyone off equally. :) naw, seriously, the idea is to be able to
generate fairly complex xml from sql queries without having to resort to
using xslt for structural manipulation (the ability to invoke logic blocks
using esql was an unexpected but awesome side effect). having cogitated
for a bit, i'm leaning back towards no-results, but i'd like to hear from
other users.
can't wait to stop discussing and start coding. :)
- donald
Re: draft final version of the esql namespace
Posted by Matt Sergeant <ma...@sergeant.org>.
On Wed, 8 Nov 2000, Marco Pauck wrote:
> > 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.
Having seen your example, I see both sides now :)
Its a fine line between bloating the esql: namespace. For example, your
example could trivially be coded in an esqlu (esql-utils) namespace. It
depends what the aim is - to provide everything you could want to do with
esql, or to provide a framework with which to build those
things... Donald?
> > > > 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".
I know - originally Donald was proposing two separate methods for invoking
queries vs DML SQL. So I'm on your side in a way :-)
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
Re: draft final version of the esql namespace
Posted by Marco Pauck <pa...@wmd.de>.
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/ **
> \\//
> //\\
> // \\
Re: draft final version of the esql namespace
Posted by Nicola Ken Barozzi <ni...@supereva.it>.
From: "Donald Ball" <ba...@webslingerZ.com>
> 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?
IMO it is confusing.
Let's say you do something like:
<esql:select-query>select * from foo</esql:select-query>
etc...
or
<esql:insert-query>insert ... etc</esql:insert-query>
etc...
What prevents a user from doing:
<esql:insert-query>select * from foo</esql:insert-query>
?
IMO it's conceptually wrong to have different tags to specify the *same*
thing: an SQL query.
> 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.
I wrote a mail, a part of which Donald answered:
From: "Donald Ball" <ba...@webslingerZ.com>
> On Tue, 7 Nov 2000, Nicola Ken Barozzi wrote:
>
> > I thought that maybe different "taglibs" per SQL command could have
> > been better, but the SQL is a string you cannot control, and people
> > might end putting INSERT in a SELECT execution tag! :-P
>
> i think you've got a good argument there, it's just not in line with what
> i needed. i think you could write such a logicsheet as a wrapper around
> the esql logicsheet if you wanted to, tho.
I think I was not clear, sorry.
I meant to say that my solution is *wrong*, because of what I said above.
But the problem of different execution schemes remains.
Calling different tags for different SQL query types is equally is wrong
IMO,
because peolple can put code in tags that get never called... it should be
avoided.
Instead I propose to have *all* tags always active, so that with a SELECT,
the
"update" tag should return 0, and viceversa.
In this way we could see an SQL SELECT result as a table with 0 as info
on execution, and an insert as a an empty table with NUM_ROWS as
info on execution.
This is how I conceptually see the schema:
1-definitions <esql:driver>...</esql:password>
2-input (query) <esql:query></esql:query>
3-output(results) <esql:results>
4-info on execution <esql:execution-info> [was <esql:update-results>]
5-errors <esql:error-results>
and output has:
3-1-output-begin
3-2-3x-output-cycle(with nestings)
3-3-output-end
IMHO 3 and 4 should allways be called.
What do you think?
nicola_ken
Re: draft final version of the esql namespace
Posted by Matt Sergeant <ma...@sergeant.org>.
On Wed, 8 Nov 2000, Donald Ball wrote:
> On Wed, 8 Nov 2000, Matt Sergeant wrote:
>
> > > 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?
> >
> > No, DBI is agnostic about that. Every kind of statement preparation
> > returns a statement handle, which you then execute, and finally fetch
> > results from. Any sort of update will simply not return any rows (but set
> > the rows property for the number of rows updated). Thats where I'm coming
> > from... Maybe esql is similar and I haven't looked close enough...
>
> how do you distinguish between a query which returns an empty resultset
> v.s. an (update) query which returns no rows (updated)?
You don't, thats the point I'm making...
SELECT:
my $sth = $dbh->prepare("SELECT * FROM FOO");
$sth->execute;
while (my $row = $sth->fetchrow_hashref) {
...
}
UPDATE:
my $sth = $dbh->prepare("UPDATE FOO SET bar="value" where bar="old");
$sth->execute;
print "Updated : ", $sth->rows;
__END__
Does that help?
PS: Can we take this to xsp-dev? I'm not about to subscribe to
cocoon-users, so all this traffic ends up in my inbox...
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 8 Nov 2000, Matt Sergeant wrote:
> > 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?
>
> No, DBI is agnostic about that. Every kind of statement preparation
> returns a statement handle, which you then execute, and finally fetch
> results from. Any sort of update will simply not return any rows (but set
> the rows property for the number of rows updated). Thats where I'm coming
> from... Maybe esql is similar and I haven't looked close enough...
how do you distinguish between a query which returns an empty resultset
v.s. an (update) query which returns no rows (updated)?
- donald
Re: draft final version of the esql namespace
Posted by Matt Sergeant <ma...@sergeant.org>.
On Wed, 8 Nov 2000, Donald Ball wrote:
> 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.
Right... You should be able to go if(<esql:row-count> == 0) { ... } (or
whatever the Java parlance is), right?
> > > > 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?
No, DBI is agnostic about that. Every kind of statement preparation
returns a statement handle, which you then execute, and finally fetch
results from. Any sort of update will simply not return any rows (but set
the rows property for the number of rows updated). Thats where I'm coming
from... Maybe esql is similar and I haven't looked close enough...
--
<Matt/>
/|| ** Director and CTO **
//|| ** AxKit.com Ltd ** ** XML Application Serving **
// || ** http://axkit.org ** ** XSLT, XPathScript, XSP **
// \\| // ** Personal Web Site: http://sergeant.org/ **
\\//
//\\
// \\
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
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
Re: draft final version of the esql namespace
Posted by Matt Sergeant <ma...@sergeant.org>.
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/ **
\\//
//\\
// \\
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
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.
if you're looking to perform an xsp action based on an empty row set, you
could check the esql:get-row-count element in the results footer:
<esql:results>
<my:results>
<my:header>woo hoo</my:header>
<esql:row-results>
<my:value><esql:get-string column="1"/></my:value>
</esql:row-results>
<my:footer>hoo woo</my:footer>
<xsp:logic>
if (<esql:get-row-count/>==0) {
// my action occurs here
}
</xsp:logic>
</my:results>
</esql:results>
is there a situation you can describe which is possible with no-results
which is not possible without it, using the methods i've described?
> > 4. if a query returns a number of rows, the children of the update-results
> > element are instantiated.
>
> I guess you mean "if an update affects a number of rows", right?
no, i mean if a query returns a number of rows. straight from the JDBC API
- statement provides a method called getUpdateCount, which returns the
number of rows updated (read: inserted, modified, deleted, whatever) by
the query.
> And what about inserts?
> Right now (well, 1.22) neither <esql:results> nor <esql:no-results>
> are instantiated, so there's no way to find out if the insert was
> successful and how many rows were affected!
right. obvious failing in that version of the logicsheet.
> When working with MySQL, this gets even worse as an insert attempt
> of data that violates a unique key constraint doesn't result in an
> sql error (as with e.g. Oracle) but simply returns a "0 rows affected".
> So, how about a <esql:insert-results>?
there's no need to clutter up the namespace with extraneous results
elements. the JDBC API provides two types of results from queries -
resultsets, and update counts. (some weird queries can return multiple
resultsets and/or update counts, but we're sort of ignoring them
still.) three result types if you count SQLExceptions. so i'm providing
three results elements to be instantiated for each of the three cases.
> But now the real problem: ;-)
> In both cases, update as well as insert, it would be very helpful to
> have separate elements for the cases "some rows affected" and "no rows
> affected" as it is (or was) the case for queries (see discussion above).
again, like in no-results above, you can put in your own xsp:expr or
xsp:logic to switch on esql:get-update-count.
> 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?
- donald
Re: draft final version of the esql namespace
Posted by Marco Pauck <pa...@wmd.de>.
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!
> 4. if a query returns a number of rows, the children of the update-results
> element are instantiated.
I guess you mean "if an update affects a number of rows", right?
And what about inserts?
Right now (well, 1.22) neither <esql:results> nor <esql:no-results>
are instantiated, so there's no way to find out if the insert was
successful and how many rows were affected!
When working with MySQL, this gets even worse as an insert attempt
of data that violates a unique key constraint doesn't result in an
sql error (as with e.g. Oracle) but simply returns a "0 rows affected".
So, how about a <esql:insert-results>?
But now the real problem: ;-)
In both cases, update as well as insert, it would be very helpful to
have separate elements for the cases "some rows affected" and "no rows
affected" as it is (or was) the case for queries (see discussion above).
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?
Marco
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 6 Nov 2000, Brian P Millett wrote:
> Looks good Donald, how about the pool stuff?
>
> <esql:pool-name> name in connection pool </esql:pool-name>
or just <eqsl:pool>.
> > 1. connections are opened at the start connection element tag and closed
> > at the end connection element tag.
>
> This would be that connections in the pool are retrieved at start
> connection and returned at the end connection element tag?
right.
- donald
Re: draft final version of the esql namespace
Posted by Brian P Millett <bp...@ec-group.com>.
Donald Ball wrote:
> after much discussion and cogitation, i submit the following pseudoschema
> as the proposed final skeleton of the esql namespace:
>
> <esql:connection>
Looks good Donald, how about the pool stuff?
<esql:pool-name> name in connection pool </esql:pool-name>
> <esql:driver>org.postgresql.Driver</esql:driver>
> <esql:dburl>jdbc:postgresql://localhost/test</esql:dburl>
> <esql:username>test</esql:username>
> <esql:password>test</esql:password>
> <esql:execute-query>
> <esql:query>select id,name from department_table</esql:query>
> <esql:results>
> <header>header info</header>
> <esql:row-results>
> <id><esql:get-int column="id"/></id>
> <name><esql:get-string column="name"/></name>
> </esql:row-results>
> <footer>footer info</footer>
> </esql:results>
> <esql:update-results>
> there were <esql:get-updated-rows/> rows updated
> </esql:update-results>
> <esql:error-results>
> the query failed for some reason: <esql:get-message/>
> </esql:error-results>
> </esql:execute-query>
> </esql:connection>
>
> conformant implementations shall work as follows:
>
> 1. connections are opened at the start connection element tag and closed
> at the end connection element tag.
This would be that connections in the pool are retrieved at start connection and returned at the end
connection element tag?
> 2. multiple queries may be executed in the same connection
>
> 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.
>
> 4. if a query returns a number of rows, the children of the update-results
> element are instantiated.
>
> 5. if a query results in a sql error and an error-results element exists,
> its children are instantiated and the processor will attempt to
> continue.
>
> 6. the execute-query and connection elements may appear underneath the
> results, row-results, update-results, or connection elements.
>
> comments and suggestions are welcome. if everything thinks this is okay,
> i'll flesh out the namespace with all of the extras (max-rows, get-xml,
> etc.) begin writing a formal schema for this and bring the c1 and c2
> implementations into line with the specification.
>
> - donald
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
--
Brian Millett
Enterprise Consulting Group "Shifts in paradigms
(314) 205-9030 often cause nose bleeds."
bpm@ec-group.com Greg Glenn
RE: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 8 Nov 2000, Per Kreipke wrote:
> Donald,
>
> Hate to beat a dead horse, but you didn't address this observation about the
> examples below:
>
> "This second one would violate the test you mentioned just now about
> checking
> for row-results in the output to see if any results were returned."
er, i thought i did - the first one was the proper syntax, the second one
was not...
- donald
RE: draft final version of the esql namespace
Posted by Per Kreipke <pe...@onclave.com>.
Donald,
Hate to beat a dead horse, but you didn't address this observation about the
examples below:
"This second one would violate the test you mentioned just now about
checking
for row-results in the output to see if any results were returned."
Per.
> > > yes - the get-columns method.
> >
> > Ok. I didn't see that in your 'meta-schema'.
>
> it wasn't mentioned there, it's structurally insignificant.
>
> > In your example:
> >
> > <esql:results>
> > <header>header info</header>
> > <esql:row-results>
> > <id><esql:get-int column="id"/></id>
> > <name><esql:get-string column="name"/></name>
> > </esql:row-results>
> > <footer>footer info</footer>
> > </esql:results>
> >
> > where would I use get-columns?
> >
> > <esql:results>
> > <header>header info</header>
> > <esql:row-results>
> > <esql:get-columns/>
> > </esql:row-results>
> > <footer>footer info</footer>
> > </esql:results>
>
> yep.
>
> > And are there any options to get-columns?
>
> nope. you want style, you either do it in XSLT or you write a standard
> verbose esql:row-results section.
>
> - donald is terse, still clued to CNN
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-users-unsubscribe@xml.apache.org
> For additional commands, e-mail: cocoon-users-help@xml.apache.org
>
>
RE: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Wed, 8 Nov 2000, Per Kreipke wrote:
> > yes - the get-columns method.
>
> Ok. I didn't see that in your 'meta-schema'.
it wasn't mentioned there, it's structurally insignificant.
> In your example:
>
> <esql:results>
> <header>header info</header>
> <esql:row-results>
> <id><esql:get-int column="id"/></id>
> <name><esql:get-string column="name"/></name>
> </esql:row-results>
> <footer>footer info</footer>
> </esql:results>
>
> where would I use get-columns?
>
> <esql:results>
> <header>header info</header>
> <esql:row-results>
> <esql:get-columns/>
> </esql:row-results>
> <footer>footer info</footer>
> </esql:results>
yep.
> And are there any options to get-columns?
nope. you want style, you either do it in XSLT or you write a standard
verbose esql:row-results section.
- donald is terse, still clued to CNN
RE: draft final version of the esql namespace
Posted by Per Kreipke <pe...@onclave.com>.
> On Tue, 7 Nov 2000, Per Kreipke wrote:
>
> > Is there a way to do a default query and get back XML that uses
> the column
> > names from the database as the element names? E.g. the way the
> SQL taglib
> > worked.
>
> yes - the get-columns method.
Ok. I didn't see that in your 'meta-schema'.
In your example:
<esql:results>
<header>header info</header>
<esql:row-results>
<id><esql:get-int column="id"/></id>
<name><esql:get-string column="name"/></name>
</esql:row-results>
<footer>footer info</footer>
</esql:results>
where would I use get-columns?
<esql:results>
<header>header info</header>
<esql:row-results>
<esql:get-columns/>
</esql:row-results>
<footer>footer info</footer>
</esql:results>
or
<esql:results>
<header>header info</header>
<esql:get-columns/>
<footer>footer info</footer>
</esql:results>
This second one would violate the test you mentioned just now about checking
for row-results in the output to see if any results were returned.
And are there any options to get-columns?
Per.
RE: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Tue, 7 Nov 2000, Per Kreipke wrote:
> Is there a way to do a default query and get back XML that uses the column
> names from the database as the element names? E.g. the way the SQL taglib
> worked.
yes - the get-columns method.
- donald
RE: draft final version of the esql namespace
Posted by Per Kreipke <pe...@onclave.com>.
Is there a way to do a default query and get back XML that uses the column
names from the database as the element names? E.g. the way the SQL taglib
worked.
For example, a generic XSP page to dump the contents of a DB table without
having to customize the XSP with the table's column names.
Per.
Re: draft final version of the esql namespace
Posted by Donald Ball <ba...@webslingerZ.com>.
On Mon, 6 Nov 2000, Kevin Sonney wrote:
> On Mon, 6 Nov 2000, Donald Ball wrote:
> > comments and suggestions are welcome. if everything thinks this is okay,
> > i'll flesh out the namespace with all of the extras (max-rows, get-xml,
> > etc.) begin writing a formal schema for this and bring the c1 and c2
> > implementations into line with the specification.
>
> Wil this default to the current inner-method="no" when implemented, or
> back to the original methods?
that's outside the scope of the esql namespace definition. however it's
likely that at least the c1 implementation will default to putting the
code all in one method. it's been the case that people have trouble
accessing their own variables from the extra methods than they've actually
_needed_ those extra methods.
- donald
Re: draft final version of the esql namespace
Posted by Kevin Sonney <ke...@webslingerz.com>.
On Mon, 6 Nov 2000, Donald Ball wrote:
> comments and suggestions are welcome. if everything thinks this is okay,
> i'll flesh out the namespace with all of the extras (max-rows, get-xml,
> etc.) begin writing a formal schema for this and bring the c1 and c2
> implementations into line with the specification.
Wil this default to the current inner-method="no" when implemented, or
back to the original methods?
FWIW, I liked having the inner-method="yes/true" as the default. It helps
a *LOT* with the more complex SQL apps, and helps releive *SOME* of the
64k barrier on methods.
Of course, it's up to the implementor *grin*
--
+-------------------------------------------+
| Kevin Sonney kevin@webslingerZ.com |
| Systems Programmer www.webslingerZ.com |
+-------------------------------------------+
"The weakest link in any civil rights case is always the
defendant. Imagine being a lawyer and getting a call from me. That's why I
try to, uh, behave myself." - Hunter S. Thompson