--
Michael Hu, Paradox Team
x5279



BTW -- not sure if you meant to CC JSP-INTEREST, but you didn't -- you
can forward any of these responses to there if you like.

Michael Hu wrote:
> Yes.  Also, <connection timeout="sec"> would allow a database connection to
> have a different lifetime than a <query timedcache="sec"> server-side cached
> query, an argument against combining the <connection> and <query>  tags
> together.

Okay, we agree that having a text-based description of a connection is
a good thing.  What I object to is having that exist in the jsp page.
There's already a JDBC standard way of naming connections -- over here, we
use the setDataSourceName() call on RowSet and never worry about describing
connections....

> It may be possible to implement
> <connection> using connection pooling in such a way that the JSP author would
> never have to worry about it; it will "just work."

Yes, well, we've already got that.  Sounds like a weakness in a particular
server, rather than something a JSP tag should address.

> However, combining the <connection> and <query> tags (perhaps by making
> connection info as attributes of query) would make JSP authoring simplier, but
> at the potential cost of lost flexibility and reusability.  Any comments?

Connection attributes don't belong in the query tag, definitely.  I would
argue connections (and query select statements) also don't belong in JSP pages.
Sorta orthogonal.

<[loading sql from a separate file]
> Agreed, it is a good thing to have.  Why not make it loadable from a URI?

Great idea!

> This allows for accessing the SQL statement from a local file, or from any
> arbitrary resource on a network.

Ayep.

> There are three ways of implementing variable attributes within a custom tag:
> 1) Use a pre-processor to resolve the variable/custom tag into a constant so
> it will be XML compliant.
>   - Unnacceptable: The solution is non-JSP compliant (as of the 1.1 specs).
> However, having variable attributes in a custom tag seems to be important;
> perhaps a mechanism to embed custom tags in the attribute list of another
> custom tag should be allowed in a future JSP spec.  Any comments?
> 2) Convert the custom tag into a page scope variable, and use <%= %>
>   - Inelegant and daunting to an HTML/JSP author, but it works.  The
> <setPageData> may provide a standard mechanism to do this though.
> 3) Nest the variable attribute in a separate tag (as above)
>   - Messy and complicated to implement:
>   1. Violates OO principles of encapsultation (attributes of a tag are in its
> attribute list AND/OR (depending on the context, ie: very bug prone) in one of
> its children tags)
>   2. Confusing to the HTML/JSP author: tag attributes should be attributes,
> not tags themselves.  In HTML 4.0, there are no tags which modify the
> attributes of other tags.  There should not be any in JSP either.
>  2. Nested tags are evaluated in top-down order in JSP and HTML.  If children
> tags modify the behaviour of parent tags on run-time, then this would
> necessitate nested tags to be evaluated in down-top order.  This may be
> possible in JSP, but it gets messy very quickly.

I agree with all of this.  The ONLY comment I made on the JSP1.1 spec was that
the restriction of not allowing custom tags as attributes of other tags was
horribly restrictive.  Eduardo produced the above as the "way to do it", and my
response was "yuck!".  I suggest you carry this discussion on in the
interest or expert groups, or private email with Larry and/or Eduardo.

I'd be happy to make my voice heard on the subject again :)

> As you said, allowing <loop> tags inside of <query> tags makes <query> tags
> less reusable, especially if queries are cached to be used in different pages
> or scopes.  <loop>s make sense outside of a <query> and simplify the
> application model; I vote for keeping the tags separate, and in general,
> keeping tags as context neutral as possible.

In which case, you need an attribute for the query-parameter to direct the
parameter at a particular query.  Additionally, we need to invent a semantic
for "[re]execute query".  Perhaps as an attribute of loop?

> You have a BodyJspWriter which allows you to get its contents, assign it a
> variable, and clear() it during <setPageData>.doAfterBody().  This all happes
> before the BodyJspWriter is flush()'d to the page in doEndTag().

Yeah -- that's what I thought.  It appears this is a bug in the jsp1.1 impl
I've got on my system.

> <loop startRow="specific row" maxRows="10"> would solve the problem.  If
> startRow and maxRows are variables, then "Show next 10 Records" functionality
> can be implemented using session variables or URL rewriting which redirects to
> the same JSP page.  startRow and maxRows attributes looks useful, I vote for
> them.

Problem -- the "last" button should go to numRows-in-resultset minus the
rows-to-display (maxRows, here).  For forward-only resultsets, this can be
problematic!

> Agreed that SQL is complicated, perhaps too complicated to encapsulate in a
> standard tag.  However, <query> SQL statements here that are unparsable to
> JSP, but parsable by the backend database </query> would be a useful standard
> tag to have as a starting point anyway.

I agree.  Otherwise I wouldn't be writing some.

-Dave


Reply via email to