JonTom Kittredge wrote:
>
> Hans Bergsten wrote:
>
> > That's as close as you get in JSP 1.0. In JSP 1.1 there are ways to pass
> > parameters to the included servlet (as a query string on the page URI or
> > using <jsp:param> actions).
> >
> > But you may also like to analyze your design and see if the included
> > servlets really need to be servlets at all. A servlet is not meant to be
> > a general purpose component, it's role in life is to process requests.
> > You may want to see if it's better to redesign your included servlets into
> > JavaBeans or utility classes (works in JSP 1.0) or custom actions (works
> > in JSP 1.1).
>
> That's one point of view, but I think it's arguable. I still admire ATG's Dynamo
> product (I'ld be using it, except management didn't want to use a propietary
> technology). Dynamo provides an embedded-Java HTML generation system like JSP, except
> that it is based entirely on using servlets as components.
>
> It includes only a handful of special tags, (DROPLET, OPARAM, ...), and flow of
> control is provided not by custom tags, but by special-purpose servlets (called
> droplets).
Let me clarify; I'm not at all against using tags for this type of design,
be they called <droplet>, <servlet>, or whatever. My suggestion for redesign was
to use a different type of component behind the tag. For instance a custom action
in JSP 1.1, or possibly a <jsp:useBean> action in JSP 1.0 (combined with a small
amount of scriptlets).
Why? Because the way the Servlet spec is written, servlets are not meant to be
components. There's no formal spec for the <servlet> tag and the spec for
RequestDispatcher.include severely limits what an included servlet is allowed
to do (can't set headers, so it can't set cookies, redirect, set error codes, etc.).
That said, you can get pretty far with the <servlet> tag model. My company has
sells a product based on this model and we have many satisfied customers. But we
are now migrating this product to the custom action model, and if you design
a new application today my advice is that you do the same.
> For instance, this snippet displays names from an array of "person" objects.
>
> <droplet bean="ForEach">
> <param name="array" value="bean:personList">
> <oparam name="output">
> <!-- On each iteration, element will be one of the "person" objects on
> peopleList -->
> <p><strong>Name: </strong><valueof param="element.name">
> </p>
> </oparam>
> </droplet>
>
> In some ways this strikes me as more elegant than that of the JSP approach. The
> "oparam" concept is particularly powerful. The oparam element can contain arbitrary
> HTML, which is passed to the containing droplet, to handle as it wishes.
>
> I keep fantasizing about having a spare week or two to see if droplets and oparams
> could be implemented with JSP 1.1 custom actions.
You can easily implement a custom action with the same semantics in JSP 1.1,
with even cleaner syntax:
<foo:forEach name="personList" loopvar="person">
<!-- On each iteration, element will be one of the "person" objects on
peopleList -->
<p><strong>Name: </strong><valueof param="<%= person.getName() %>">
</p>
</foo:forEach>
--
Hans Bergsten [EMAIL PROTECTED]
Gefion Software http://www.gefionsoftware.com
===========================================================================
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
