> ..and this could probably be expanded to "When to use a servlet and when
> to use a Bean and when to use an EJB", but now we're asking for a white
> paper! :-)
Actually, you are missing one :-) "when to use a custom action", and
that is a very important one, although you have to wait for JSP 1.1 to
use it.
A custom action looks like
<x:foo att1="..." att2="..."> body </x:foo>
or
<x:foo att1="..." att2="..."/>
A custom action provides a convenient way of interacting with
server-side objects from your JSP page. You can see it as an
abstraction of some common action. For example you could have an action
like
<x:if cond=" "> body </x:if> -- conditionally perform some actions...
or something like
<x:template tag="foo"/> -- insert a template identified by a tag ...
or whatever. Semantically, the abstraction is implemented by a tag
handler, which is an invisible, server-side JavaBean component that
implements an additional interface (Tag or BodyTag) that provides a few
extra methods (for example doStartTag() or doEndTag()) for integration
with the JSP page.
Custom tags are very flexible; most of the standard tags of JSP 1.0 can
be described as custom tags, and many JSP vendors are providing their
own tag libraries to help their customers. The APM team is using tag
libraries in several places, for example there is one set that provides
integration with the EJB objects, and another that is used to construct
the MVC controller. I am currently using a few simple tags to write the
conformance tests for JSP implementations.
Additional advnatges of custom tags are that they allow for better
separation of the presentation creation role and the data access role;
one writes JSP pages that use custom tags and is likely to use a Web
authoring tool - the other writes custom tags that interact with the
data (and/or EJBs) and is likely to use an IDE. Also a JSP authoring
tool can do a much better job with a page that uses custom tags than one
that only uses scripting code.
I fully agree with Craig: it is difficult to generalize, but my current
preference is to have very little JSP scripting code in the JSP
presentation pages and instead access all the server-side data via
custom tags.
There is more stuff about custom tags in the JSP 1.1 PR2 spec at
java.sun.com/products/jsp, in the overview chapter and in the Tag
Extensions chapter. It is a spec, but I think it is reasonably
readable. The tomcat@jakarta project will be upgrading their
implementation to PR2 very soon. And we will be making available more
exmples using custom tags in the near future and in different places.
There are also several books on the topic being written.
Also, somebody asked about xmlc vs JSP. I think that xmlc is an
ingenious solution that uses standard HTML (using SPAN nodes), but JSP
is being or will be supported directly by most authoring tools so that
benefit is not very important, and a custom tag has additional
advantages, for example that the information in a custom tag can be
processed by tools easily, and that a custom tag is very easy to write
and reuse. Of course, I am biased :-).
Also somebody asked about scalability; one thing to add: you may want to
check the distributable attribute in the WAR deployment descriptor
(web.xml) in the Servlet 2.2 specification. I'll try to send more
another time.
- eduard/o
===========================================================================
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
