One thread in the replies to "what JSP really offers" was related to tag
libraries. See some follow-ups intermixed below.

Joe Walnes wrote:

> ... the most useful addition to JSP1.1 - taglibs.
> With a taglib you can define you're own custom tags which can be used in
> any html editor.
>
> Simple taglibs could include <bannerad />, <hitcounter />, <bigflashingbox
> color="blue">Hello</bigflashingbox>.
>
> Because you can implement them yourself, the possibilities are endless and
> they have greatly increased productivity in my organisation where the
> developers can define custom tags and simply show the HTML people how to
> use them.
>
> -Joe Walnes
> Software Architect - Wirestation

Joe is right: JSP 1.1 is essentially JSP 1.0 + Custom tags + s/Servlet
2.1/Servlet 2.2/

Users seem pretty happy with custom tags and I'd encourage anybody who
looked at earlier JSP draft specifications to reevaluate JSPs with their
functionality in mind.  I personally think that custom tags are
extremely important and we worked hard to include them in JSP 1.1 and in
J2EE 1.2.  Many vendors have made public plans for supporting JSP 1.1.
See the JSP web pages (at java.sun.com/products/jsp), or the
jsp-interest mailing list at java.sun.com.

We hope to keep improving them.

David Bullock wrote:

> >What JSP does not do, however, is let your web-designer work with pure
> >HTML (unless their editor makes special provision for the JSP tags).  It
> >also will not let unimaginative people visualise the results of your
> >generated content before the servlet is built.

and later he also wrote:

> Two hinderances to my own acceptance of JSP over XMLC would still be:
>
> 1. the actual *content* of those taglibs is still not 'specified visually', in
> such a way that a person could visualise them. [albiet, you could do two
> versions - a 'template' version, and a 'filled-out' version, but this doubles
> your maintenance woes].  This seems important to me from the perspective of
> communicating with the client - arguably the most difficult aspect of
> development for most of us.

I think that David is touching an important issue that involves

- how to communicate the desired layout from author to developer
- how to present the pages to the author in an authoring tool so he can
be sure they
do what you want.

There are probably many ways to attack the first issue.  One may be to
just let the author control the layout by manipulating (X)HTML and tags
that correspond to data, either directly, or through some design control
representation.  For example, a custom tag can be used to extract a
field from some data source (e.g. some relational database query); and a
design control can be used to manipulate several of these, and HTML
data, under guideance of the user.

You can also address the first issue "a la XMLC".  In this case you
could have a tag that takes as argument the HTML fragment.  You are
essentially replacing the ID mechanism of XMLC with the name of the
custom tag.  Something of the form:

        <x:myFoo>
                <ul>
                <li>....</li>
                ...
                </ul>
        </x:myFoo>

I don't know if all the HTML editors and browsers will both preserve and
ignore the <x:myFoo>, but a sample of one (navigator) did.

The second issue is presenting a custom tag to a web author in a way
that can be recognized by the author and then can be manipulated.  There
is nothing in the JSP 1.1 mechanism for this; we were in such a hurry
that we did not even put an icon opportunity in he TLD (the tag library
descriptor).  I expect we wil spend some time on this area in the next
version of he spec.

The use of a standard tag library can also help with some of these
issues, as an authoring tool can provide specialized support for known
tags.

> 2. [??] the file would not validate against the HTML 4.0 DTD.  This seems
> important to me from the perspective of automating quality-assurance of HTML
> files.

That is correct.  I hope we can think about this in the context of the
next spec, but I believe that the actual the problem is more complex
than validating the page that is written by the author: what you want is
assurances that the dynamically generated page is valid, and that may or
not have any relationship with what the author is writing, or what the
developer is generating.

Milt Epstein wrote:

> One other thing I meant to mention.  "Template" systems (such as
> freemarker, webmacro, and others) may allow better separation of
> display and logic/data than JSP.  YMMV.
>
> Milt Epstein
> Research Programmer
> Software/Systems Development Group
> Computing and Communications Services Office (CCSO)
> University of Illinois at Urbana-Champaign (UIUC)
> [EMAIL PROTECTED]

The "template" systems that I am aware can be seen as very simple cases
of JSP tags.  Essentially they provide syntactic sugar for something
like <x:templateEval "expr"/>,
where "expr" is an easier to write syntax for a combination of getters
on implicit objects.  I have not mentioned before, but custom actions
can create new implicit objects, with different types of lifescope.

This is not to underestimate the value of simple syntax, specially when
writing pages in a POTE (plain old text editor) like vi, or even
(x|gnu|)emacs.

I'd be interested if the characterization above is missing.

...

Hope this helps,

        - eduard/o

___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".

Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html

Reply via email to