You are viewing a plain text version of this content. The canonical link for it is here.
Posted to taglibs-dev@jakarta.apache.org by "Scott M. Stirling" <ss...@mediaone.net> on 2001/01/09 05:17:51 UTC
What (or for whom) are JSP tags?
I'm going through the JNDI taglib documentation and putting it into XML form, tweaking my XSL as I go, so I can generate docs for any taglib.
While I'm at that, and since I've taken a look at some of the other tag
libs (for example , the JSP implicit object tag libs) I'm noticing a
trend that's a little unsettling, but maybe it's just me.
Basically what I think I'm seeing are tags that are little more than
wrappers for Java method calls. I am wondering how these are going to
appear to a JSP coder, who is going to be boggled by tags that require
him to know Java objects and concepts.
How about JSP tags with 10 attributes? Granted, all of them are
optional in, for example, the JNDI useContext tag. Or take any tag
whose function is to get or set a property. To me it's like using tags
for the sake of using tags. If I'm a JSP coder, wouldn't it be as easy
for me to learn how to call pageContext.getAttribute() in a scriptlet as
it is to call a tag that does the same thing?
Tags have a performance overhead that may go away in the future, but for
now they aren't the most efficient means of coding a JSP, particularly
if they are simple method calls. What do you think?
Scott Stirling
West Newton, MA
Re: What (or for whom) are JSP tags?
Posted by Dan Mandell <dm...@stanford.edu>.
>I also don't see much difference
>between <foo:getAttribute name="bar"/> and <% foo.getAttribute("bar")
>%>. Forgetting which is potentially neater in simple examples or better
>for tool vendors (which looks at it from the wrong end, IMO), does
>either really abstract anything from the user? Is there a better user
>interface in one than the other? I don't think so. They look about the
>same to me.
Though I would mention that the benefit of tags is in their ability to
encapsulate powerful java functionality, and do so using an authoring
paradigm that is more intuitive to web developers. If we are assuming our
"web developers" (in quotes because the definition of our target users is
so fuzzy) are more HTML than Java savvy, then we assume that they know
<foo:getAttribute name="bar"/> means they're using the "getAttribute" tag
with a "name" attribute of "bar", whereas they may not know that
<% foo.getAttribute("bar") %> means 'pass "bar" as a parameter to the
"getAttribute()" method of the "foo" object. With something as functionally
basic as getAttribute, its not necessary for the user to know what the java
syntax means, so there is no real disadvantage in writing the scriptlet.
But with more complex tags, like SQL query tags for example, we abstract
away a greater proportion of the java-centric details. These high level
tags are where the real power of taglibs lies, but of course they currently
rely on many low-level tags like "getAttribute". Now the advantage of using
<foo:getAttribute name="bar"/> over <% foo.getAttribute("bar") %> for the
low-level tags is really just consistency with the high level tags, which
is why we're using tags in the first place. We're still left with the
problem of tags which rely on many low-level tags. To help we can wrap up
as much functionally as possible in high level tags, as in Hans's dbCollect
tag. And tool support will be a great help for authoring JSPs with many
unavoidable single attribute tags, like getAttribute.
Re: What (or for whom) are JSP tags?
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
"Scott M. Stirling" wrote:
> [...]
> After HTML-ifying the doc for the JNDI taglib, I think it safe to say
> there's no way a non-Java programmer would have a clue about how to use
> it. There's no significant abstraction. I don't mean to attack the
> JNDI taglib, since it's not really much different from several others.
> One that is really well done, I think, is the BSF taglib.
>
> But here's the basic design pattern I'm seeing:
>
> 1. Take a Java class or interface with methods
> 2. Write a tag or taglib that corresponds directly with that
> class/interface, and provide multiple tags and attributes for
> instantiating the class and calling its methods.
> 3. Add an iterator tag for any collection returned from the class'
> methods or constructor.
>
> That's it. But these are tags for Java programmers. They're
> engineer-centric, instead of user-centric.
>
> I'll agree that a JSP written in tags could look nicer than one written
> in scriptlets. But I think that JSPs are nasty looking with a ton of
> tags that are necessitated by the fact that each one encapsulates hardly
> any functionality. The more useful functionality you can encapsulate in
> a tag, the more you remove the tag user from having to know how it works
> or what it technically does on the back end.
I agree; custom actions that map a Java class/interface too closely
leads to what I call "programming with tags"; intricate conditional
testing, execution of low-level functions etc. is still "programming",
even if all statements looks like HTML tags. It's not the syntax that
is important, it's the thought process.
It's hard to draw the line, though, and maybe the application, session,
request etc. actions fill a purpose; I don't know. But I always try to
look at what makes most sense to a page author, as opposed to a
programmer,
when I design custom actions. One example, from our InstantOnline
Basic taglib, is to allow conditional processing control for the most
common cases through "event handler attributes".
<iob:dbCollect id="theResult" table="Foo"
onNoRowsForward="noresult.jsp" />
If no rows are returned from the query, the request is forwarded
to the specified page. No "if statement" needed.
Another example from InstantOnline (sorry if it seems like I'm plugging
this product. It's not my intention, in this forum at least ;-), is
the use of a "variable expression" syntax for providing input from
various sources (scopes):
<iob:sendMail to="$http|receiver$"
from="$session|currUser.name$>
This is the content of the mail, using data from various
sources:
$application|numbOfCurrUsers$
$cookie|userName$
$header|User-Agent$
$system|sysdate$
</iob:sendMail>
An InstantOnline variable is enclosed in dollar signs, and can
be defined using multiple parts separated by vertical bars. In this
example the "scope" and the "name" parts are used, where scope is
one of the standard JSP scopes plus others such as cookie, header,
system, etc. If scope is omitted, all scopes are searched in a
defined order.
Based on the feedback I have recieved, page authors (who are not
programmers) really like this approach.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: What (or for whom) are JSP tags?
Posted by Hans Bergsten <ha...@gefionsoftware.com>.
Glenn Nielsen wrote:
> [...]
> What would really be nice is if there were a setTagLocation(int line, int column)
> in the Tag and BodyTag interfaces so that the JSP compiler could generate code to
> let the tag know where it is located in the original JSP page source. Then the
> errors generated by the tag could idenitify the exact location in the JSP page
> source where the error occurred.
Great idea! I've been looking at making this info available to the
author during the translation phase (when isValid() on a TEI is used
to validate, or using the new validation classes), but it would also be
very helpful in the request phase. I'll bring this proposal to the
JSR-053 group in case Eduardo doesn't see this mail.
> These discussions regarding tag design are interesting. Perhaps it will
> help inspire new design concepts for custom tag libraries.
Yes, and they serve as great input to JSR-052 where the best ideas
can be formalized in some manner.
Hans
--
Hans Bergsten hans@gefionsoftware.com
Gefion Software http://www.gefionsoftware.com
Author of JavaServer Pages (O'Reilly), http://TheJSPBook.com
Re: What (or for whom) are JSP tags?
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
"Scott M. Stirling" wrote:
>
> On 09 Jan 2001 08:21:20 -0600, Glenn Nielsen wrote:
> > "Scott M. Stirling" wrote:
> > > While I'm at that, and since I've taken a look at some of the other tag
> > > libs (for example , the JSP implicit object tag libs) I'm noticing a
> > > trend that's a little unsettling, but maybe it's just me.
> > >
> >
> > Is the JSP implicit object a Jakarta taglib? If so, which one is it in?
>
> I was referring to the application, page, request, etc. taglibs, which
> are essentially wrappers for calls that could as well be made on the JSP
> implicit objects directly.
>
> > > Basically what I think I'm seeing are tags that are little more than
> > > wrappers for Java method calls. I am wondering how these are going to
> > > appear to a JSP coder, who is going to be boggled by tags that require
> > > him to know Java objects and concepts.
> > >
> >
> > If the tag set and its features are well documented, it should be fine.
> > And if the docs don't assume any knowledge of Java.
>
> After HTML-ifying the doc for the JNDI taglib, I think it safe to say
> there's no way a non-Java programmer would have a clue about how to use
> it. There's no significant abstraction. I don't mean to attack the
> JNDI taglib, since it's not really much different from several others.
> One that is really well done, I think, is the BSF taglib.
>
> But here's the basic design pattern I'm seeing:
>
> 1. Take a Java class or interface with methods
> 2. Write a tag or taglib that corresponds directly with that
> class/interface, and provide multiple tags and attributes for
> instantiating the class and calling its methods.
> 3. Add an iterator tag for any collection returned from the class'
> methods or constructor.
>
> That's it. But these are tags for Java programmers. They're
> engineer-centric, instead of user-centric.
>
I agree that the taglibs for the implicit JSP objects are engineer centric,
and that they essentially wrap a java class and its methods. At the time
I wrote them I was also working on a much more complex tag lib for Jive,
http://coolservlets.com/jive/. (Allaire just signed on as a Jive sponsor)
I needed tag sets that exposed the basic environment of a JSP page. I used
it as an exercise to see if a complex app could have its display pages done
completely using tags. And to learn more about designing and using JSP
custom tags.
> I'll agree that a JSP written in tags could look nicer than one written
> in scriptlets. But I think that JSPs are nasty looking with a ton of
> tags that are necessitated by the fact that each one encapsulates hardly
> any functionality. The more useful functionality you can encapsulate in
> a tag, the more you remove the tag user from having to know how it works
> or what it technically does on the back end. I work for Allaire, so of
> course I'm thinking of the oodles of CFML tags that ColdFusion has, and
> the hundreds of tags people have written -- that people sell, even.
>
I agree that there is a need for tags that encapsulate a great deal more
functionality. For example a tag like "cookieCheck", that checks to see
if a remote client is sending cookies, if not, it sends a cookie and sees if
it gets it back, if it doesn't get the cookie back, it redirects to a user
specified page.
Part of the complexity of tags is due to the complexity of an HTTP Request,
there are cookies, headers, parameters, etc. Its hard to know what actions
a user might want to take in their JSP page based on what is received from
the client. Tags to get at the nuts & bolts of the request will be needed.
Encapsulating frequently needed functions into a single tag would help
minimize a page authors need to use the more 'low-level' tags.
> > I am looking at this from the perspective of how JSP is being deployed
> > where I work. In my case, we are like a web hosting service.
> > We host several hundred web sites and over 800 people can publish
> > content. We want to push out to them the ability to do 'dynamic content'
> > using JSP. For many of them, learning Java programming concepts would
> > be too high a barrier for them to use the technology. Plus from our
> > side it would be a great deal easier to support well documented tag
> > sets than java code embedded in scriptlets. If performance becomes
> > an issue we can always throw more hardware at it.
>
> Then I am most interested in your perspective, since you are in the
> thick of the marketplace/user base toward whom JSP is thrust. I've
> argued this at work with people, when discussing PHP versus JSP (among
> other things). That is, a well-written PHP function is no more
> difficult to use than is a well-written CFML or JSP tag. In PHP, you
> have a method call into which you pass a few paramters. In JSP/CFML
> tags, you have a tag with attributes. I don't see a whole lot of
> difference if you them both right. I also don't see much difference
> between <foo:getAttribute name="bar"/> and <% foo.getAttribute("bar")
> %>. Forgetting which is potentially neater in simple examples or better
> for tool vendors (which looks at it from the wrong end, IMO), does
> either really abstract anything from the user? Is there a better user
> interface in one than the other? I don't think so. They look about the
> same to me.
>
Your scriptlet might cause a null pointer exception in the page, a tag
could handle it more gracefully and give you a better error message
that is context sensitive like "foo:getAttribute, attribute 'bar' doesn't exist".
Even if the tag is just wrapping a get method, a well designed tag can make it
easier for non programmers.
What would really be nice is if there were a setTagLocation(int line, int column)
in the Tag and BodyTag interfaces so that the JSP compiler could generate code to
let the tag know where it is located in the original JSP page source. Then the
errors generated by the tag could idenitify the exact location in the JSP page
source where the error occurred.
These discussions regarding tag design are interesting. Perhaps it will
help inspire new design concepts for custom tag libraries.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
Re: What (or for whom) are JSP tags?
Posted by "Scott M. Stirling" <ss...@mediaone.net>.
On 09 Jan 2001 08:21:20 -0600, Glenn Nielsen wrote:
> "Scott M. Stirling" wrote:
> > While I'm at that, and since I've taken a look at some of the other tag
> > libs (for example , the JSP implicit object tag libs) I'm noticing a
> > trend that's a little unsettling, but maybe it's just me.
> >
>
> Is the JSP implicit object a Jakarta taglib? If so, which one is it in?
I was referring to the application, page, request, etc. taglibs, which
are essentially wrappers for calls that could as well be made on the JSP
implicit objects directly.
> > Basically what I think I'm seeing are tags that are little more than
> > wrappers for Java method calls. I am wondering how these are going to
> > appear to a JSP coder, who is going to be boggled by tags that require
> > him to know Java objects and concepts.
> >
>
> If the tag set and its features are well documented, it should be fine.
> And if the docs don't assume any knowledge of Java.
After HTML-ifying the doc for the JNDI taglib, I think it safe to say
there's no way a non-Java programmer would have a clue about how to use
it. There's no significant abstraction. I don't mean to attack the
JNDI taglib, since it's not really much different from several others.
One that is really well done, I think, is the BSF taglib.
But here's the basic design pattern I'm seeing:
1. Take a Java class or interface with methods
2. Write a tag or taglib that corresponds directly with that
class/interface, and provide multiple tags and attributes for
instantiating the class and calling its methods.
3. Add an iterator tag for any collection returned from the class'
methods or constructor.
That's it. But these are tags for Java programmers. They're
engineer-centric, instead of user-centric.
I'll agree that a JSP written in tags could look nicer than one written
in scriptlets. But I think that JSPs are nasty looking with a ton of
tags that are necessitated by the fact that each one encapsulates hardly
any functionality. The more useful functionality you can encapsulate in
a tag, the more you remove the tag user from having to know how it works
or what it technically does on the back end. I work for Allaire, so of
course I'm thinking of the oodles of CFML tags that ColdFusion has, and
the hundreds of tags people have written -- that people sell, even.
> I am looking at this from the perspective of how JSP is being deployed
> where I work. In my case, we are like a web hosting service.
> We host several hundred web sites and over 800 people can publish
> content. We want to push out to them the ability to do 'dynamic content'
> using JSP. For many of them, learning Java programming concepts would
> be too high a barrier for them to use the technology. Plus from our
> side it would be a great deal easier to support well documented tag
> sets than java code embedded in scriptlets. If performance becomes
> an issue we can always throw more hardware at it.
Then I am most interested in your perspective, since you are in the
thick of the marketplace/user base toward whom JSP is thrust. I've
argued this at work with people, when discussing PHP versus JSP (among
other things). That is, a well-written PHP function is no more
difficult to use than is a well-written CFML or JSP tag. In PHP, you
have a method call into which you pass a few paramters. In JSP/CFML
tags, you have a tag with attributes. I don't see a whole lot of
difference if you them both right. I also don't see much difference
between <foo:getAttribute name="bar"/> and <% foo.getAttribute("bar")
%>. Forgetting which is potentially neater in simple examples or better
for tool vendors (which looks at it from the wrong end, IMO), does
either really abstract anything from the user? Is there a better user
interface in one than the other? I don't think so. They look about the
same to me.
--
Scott Stirling
West Newton, MA
Re: What (or for whom) are JSP tags?
Posted by Glenn Nielsen <gl...@voyager.apg.more.net>.
"Scott M. Stirling" wrote:
>
> I'm going through the JNDI taglib documentation and putting it into XML form,
>tweaking my XSL as I go, so I can generate docs for any taglib.
>
> While I'm at that, and since I've taken a look at some of the other tag
> libs (for example , the JSP implicit object tag libs) I'm noticing a
> trend that's a little unsettling, but maybe it's just me.
>
Is the JSP implicit object a Jakarta taglib? If so, which one is it in?
> Basically what I think I'm seeing are tags that are little more than
> wrappers for Java method calls. I am wondering how these are going to
> appear to a JSP coder, who is going to be boggled by tags that require
> him to know Java objects and concepts.
>
If the tag set and its features are well documented, it should be fine.
And if the docs don't assume any knowledge of Java.
> How about JSP tags with 10 attributes? Granted, all of them are
> optional in, for example, the JNDI useContext tag. Or take any tag
> whose function is to get or set a property. To me it's like using tags
> for the sake of using tags. If I'm a JSP coder, wouldn't it be as easy
> for me to learn how to call pageContext.getAttribute() in a scriptlet as
> it is to call a tag that does the same thing?
>
> Tags have a performance overhead that may go away in the future, but for
> now they aren't the most efficient means of coding a JSP, particularly
> if they are simple method calls. What do you think?
>
> Scott Stirling
> West Newton, MA
Yes, there are tradeoffs. There are pros and cons for each. Looking
at this from the perspective of a web publisher...
Scriptlets, rtexprvalue, etc.
----------------------------
Pro
1. Better performance, actual java code is embedded directly in the servlet
when JSP page compiled.
2. For those comfortable with Java, it may be easier to use a scriptlet than
a custom tag that provides a similar capability.
Con
1. Requires web publisher to learn some fundamentals of Java programming.
2. More likely that javac compiler errors will be generated, these can be
more intimidating for a web publisher to figure out.
3. More difficult for web publishing tools to provide support for coding
in java directly, it then becomes more like an IDE.
4. Using Scriptlets isn't HTML like.
JSP tags
--------
Pro
1. Easier for web publishing tools to provide support for tags.
2. Tags can expose only the functionality needed, and then well document
the tag interface.
3. Doesn't require knowledge of Java programming.
4. Error messages (JspTagExceptions) can be very specific about the tag
usage and not some general compiler error.
5. A tag can hide some complexity from the user, even if its only 5-10
lines of java code.
6. Using JSP tags in a page looks like HTML, the page is more readable.
Con
1. Performance overhead. Although there is some compile time checking of
custom tags, there is still alot of additional code that gets executed
at runtime. This may or may not be an issue. When evaluating performance,
the most critical issue is request latency, i.e. how long a remote user
has to wait for a page to be displayed. Server load is secondary.
Feel free to add your own pros & cons to my list.
I am looking at this from the perspective of how JSP is being deployed
where I work. In my case, we are like a web hosting service.
We host several hundred web sites and over 800 people can publish
content. We want to push out to them the ability to do 'dynamic content'
using JSP. For many of them, learning Java programming concepts would
be too high a barrier for them to use the technology. Plus from our
side it would be a great deal easier to support well documented tag
sets than java code embedded in scriptlets. If performance becomes
an issue we can always throw more hardware at it.
Regards,
Glenn
----------------------------------------------------------------------
Glenn Nielsen glenn@more.net | /* Spelin donut madder |
MOREnet System Programming | * if iz ina coment. |
Missouri Research and Education Network | */ |
----------------------------------------------------------------------
JSP