Michael Hu wrote:
> Tags which encapsulate database functionality:
>
> 1) <connection>: allows for connection pooling, and multiple queries to
> reuse a common database connection.
>
> 2) <query>: allows for execution of arbitrary SQL statements over a
> <connection>. Some may agrue that this tag should be <sql> as <query>
> implies SELECT functionality only. ADD, UPDATE, DELETE, etc SQL
> functionality seems problamatic to encapsulate in a custom tag; an open
> discussion to solve this common problem would be much appreciated (ie:
> How do you implement rollbacks?)
>
> 3) <loop>: iteration over a <query>; FOR EACH functionality
>
> 4) <field>: outputs the contents of a database field. Probably only
> makes sense being nested within a <loop> tag.
Oddly, I just started writing pretty much these exact tags yesterday. Your
timing is impeccable :) My comments below.
I'm not sure what you're trying to accomplish with <connection>, exactly.
Is connection going to describe the attributes of a connection, making it
available to a query? I'm not sure you want a JSP author to manage connection
pooling, that seems more back-endish to me.
My query tag looks like:
<query name="..." command="..." connection="jdbc/demo">
<command>...</command> //[For building the command attribute]
//[We also support loading a query from a
// separate file, which removes sql from your
// jsp/presentation-layout, which seems like a
// good thing]
<param name="destName|Offset" type="destType" value="...">
<value></value> // As you note, we can't nest tags, which is
// a drag. So, this is how I base a parameter
// on, say, a nested query value to do breaking
// [hierarchical] reports.
</param>
<loop query="name_of_query_to_loop_over" max="max-rows">
<field name="column" query="..." format="...">null_value</field>
</loop>
</query>
I've made loop possible to exist within the query tags. One might just as
easily
make <query> a pure definition, and force the query attributes of loop and field
(which default to the parent Query tag if unspecified right now).
Unfortuantely,
once you make query a definition, someone is going to want to put them in
separate, included jsps, so then we have to talk about what context the
definition is for, etc.
Also, my loaded-from-a-file type of query has actual names for the parameters.
I really dislike JDBC's numbered parameter scheme as it makes separating queries
from their usage instances really nightmarish. Someone ought to ding the JDBC
group on that one. Anyway, the name of the parameter could just as well be an
offset, or unspecified, in which case the parameters are numbered in ascending
order.
A quick btw -- if someone can 'splain to me how this kind of tag:
<setPageData> <myCustomTag/> </setPageData>
can capture its body, I'd sure appreciate it. Maybe it's just the engine I'm
using, but I'm not clear as to how that's accomplished. It seems like all I
have is a writer. I can probably get the contents out of it, but how do I
prevent the output from ending up on the page?
Oh, and while we're on the subject of <setPageData>, I vote for
<setData scope="page"> instead.
Anyway, back to queries. There are possible ambiguities as to where the
RowSet gets executed. One might execute on loop entry, but if you wanted a
table of ten rows, a break, and then ten more rows, etc., one wouldn't want
the query executed on every loop entry! Similarly, if one wanted the query
to start at a specific row, one would need the query to be executed before
you call absolute() on the RowSet.
Additionally, sql construction is a slightly more sophisticated proposition
than outlined here. In particular, search pages would call jsps that would
require complex where clauses to be build. One would prefer to have something
like:
<command>select * from emp where :whereClause and deptid=:parent</command>
<param name="whereClause" value="<%= getWhereClause()>"/>
<param name="parent" value="<%= request.getParameter("deptid")"/>
but all we manage to do is add additional ambiguities! The whereClause
parameter
must be replaced before the command is set on the query, otherwise the sql is
not standard/parsable. The parent parameter should be set after command is set,
otherwise the sql isn't reusable/cached-on-server across departments.
And, of course, that's the easy part. People are going to want to extend these
tags and allow for, say, VCR-like navigation across record sets. They'll want a
version of loop whose doEndTag() is overridden to output the
first/prev/next/last
buttons, or they might choose to automatically have the loop tag generate into
a javascript array with the necessary support logic to allow navigation of the
results purely on the client. Then there's the external-to-app-server client
who is building n-tiers and uses jsp to deliver an xml stream of the ResultSet.
But let's not over-complicate matters :)
I think what I'm trying to say is that standards are a good idea, but you should
let people use them as a starting point. Let's agree that setData, query, loop,
and field are a good idea. Let's agree what some of the attributes of those
tags are, and let's revisit an exact definition, once multiple people have gone
out to the field and used them for a half-year or so.
My two cents, anyway.
-Dave
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
