Hi,
Well, I would have thought that if a set of tags solve those "so common"
problems and enough developers agree on them, they should be in the JSP
spec. Is it not the purpose of it? The spec specifies the minimum set of
tags that solve common problems without getting a fat
spec/implementation and the tag extensions are for the "roll it your own
way" solutions but anyway... here are my comments.
I pretty much agree that in order to fulfill the goal of separating the
presentation part from the business logic one, some tags to solve common
tasks for JSP should be included, like the ones you proposed for
setting/getting data in different contexts. However I agree with David
Navas, I would also opt for <setData scope=xxx> to follow the syntax
that's already in the spec.
On the other hand, I think that introducing pseudo SQL tags like <query>
<connection> shouldn't be included. This goes, IMHO, completely against
the goal stated before by mixing business logic with presentation
issues, I would introduce, instead, some looping tags to iterate over an
Enumeration or some classical Java structures, this would allow the
programmer to define how to access the database, select the appropriate
rows... (Business logic with database specific code) inside a Bean, for
example, and return the results through an object that the HTML designer
can "understand" without a prior knowledge of SQL, the database
structure, ...
There has been a lot of discussion in here over the topic on how to
separate business logic from presentation issues and you can bet that
for every solution proposed, you can find a set of tags that would turn
into "HTML" the little portion of Java code remaining on the
presentation side. In my case, I always try to keep things as simple as
possible on the JSP page and 90% of the time, some looping through an
enumeration, some simple flow logic like if - else-if - else and some
error handling would do for me. It's not that I don't want SQL to show
up in my presentation code, I don't even like SQL to be in my business
logic code so I hide it under another layer that I tend to call Basic IS
API but anyway... I'm not against the definition of an open
source set of tags upon which a large number of developers agree. It's
the word standard that kind of scares me. Standards are good up to a
point but are difficult to reach and have to be very well thought out so
they don't tend to standardize too much.
My two cents, I'd follow the usual Java rules so keep things simple and
encapsulated, and give time to the JSP spec and programming model to
mature. Once we have a better idea on how to deal with JSP, servlets EJB
in a clean way, then it will be easier to agree in a common set of tags.
But by then Java will probably come up with something new and we'll have
to start all over again ;), but that's what they pay us for, isn't it?
Dan
PD: I came from my holidays yesterday and I still haven't found time to
have a look at the last public JSP spec so some things might have
already been included there.
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
Michael Hu wrote:
>
> Just as much as a free, and standardized API has accelerated Java
> adoption, a free and standardized tag library will accelerate JSP
> adoption. If enough developers can agree on a set of tags that solve
> common problems, then there is a strong argument to make those tags open
> source and include them into the <jsp: > namespace. The rest of this
> posting is a preliminary proposal for the following tags to be
> standardized:
>
> Tags which encapsulate implicit JSP objects:
>
> 1) <setPageData> and <getPageData>: get/set methods for declaring and
> referencing page scope scripting variables. This essentially converts
> the output of any custom tag which normally out.print()'s into a page
> scope scripting variable.
>
> eg)
> <setPageData name="foo" type="java.lang.String">
> <myCustomTag/>
> </setPageData>
> <jsp:forward page="<%=foo%>"/>
>
> Note that <jsp:forward page="<myCustomTag/>"/> is illegal in JSP and
> XML, and that attributes passed to a custom tag are not always
> constants. The <%= %> is the only variable resolution mechanism that
> can be embedded in a tag attribute, so a custom tag that converts the
> output of custom tags into a resolvable page scope variable is
> necessary.
>
> 2) <setSessionData> and <getSessionData>: get/set methods for declaring
> and referencing session scope variables. Obvious uses include "Show
> next 10 records" and "Shopping Cart" functionality.
>
> 3) <setRequestData>, <getRequestData>, <setApplicationData>,
> <getApplicationData>: get/set methods for declaring and referencing
> variables for request and application scope respectively. Not as
> critical as the previous two set of tags, but necessary for symmetry and
> completeness' sake.
>
> As for the other implicit objects, (response, pageContext, out, config,
> exception), I am not convinced as to their usefulness from an HTML
> authoring point of view. Their functionality is important for back-end
> business logic and should probably be encapsulated by Beans instead of
> tags (the old argument for the separation of display and business logic
> in web apps).
>
> 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.
>
> Feel free to comment on any of these proposed tags, or to propose tags
> of your own. Especially needed is an attribute list and nesting
> restrictions for these tags so a Document Type Descriptor can be spec'd
> out and implemented.
>
> --
> Michael Hu, Paradox Team, Corel Corporation
===========================================================================
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
