Mike Wills asked:
> I am wondering how you normally output the webpage from a
> servlet. Do you actually embedded all of the HTML in the program?
> That seems a bit messy. Or is there a better way?
I felt the same way. Personally, I tend to prefer just a simple
templating system, but what works best depends largely on your
application, your production environment, and your tastes. The
"canonical" answer from sun is JSP - Java Servlet Pages. More about
them at the end.
Besides JSP, there are a variety of options for generating HTML,
like ECS, which let you construct a page as a set of objects.
I.e. you instantiate some sort of "page" object and you instantiate
and add a "table" object to the page (or maybe first a "body" object
and then a "table" object?) and then add a "form" object to the table,
etc. Then you output the set of objects as HTML tags.
I'm not sure if there are any prevailing template approach
systems. I'm not sure what the WebMacros paradigm is, but I hear
fairly positive comments about it in general.
If you're doing a very heavily document-oriented system, then
Jakarta Cocoon or similar approaches might just do what you want.
They're more oriented at document publishing, generating XML and then
translating that XML into HTML pages to publish it. It's a little
like templating, but more structured. I like the general idea, though
I haven't had time to look into it heavily; a coworker who looked more
closely expressed approval, but we've already committed to another
strategy.
Despite my own preferences, I use JSP because that's what most of
my customer base (i.e. corporations) wants to use. JSPs are
essentially a template scheme (if you squint hard enough :-). You
write a JSP by taking your normal, static, HTML page, rename it .jsp
and making sure your JSP engine knows about it (so it'll compile it
automatically, when the time comes).
That's in theory all you have to do to make a JSP, but of course
it doesn't buy you a whole lot. What the JSP engine - actually a JSP
compiler, but I think that phrase is misleading, because it implies a
far too static approach - does is, when asked for the page, compile
the JSP tags into java sourcecode for a servlet uses a lot of
brute-force print statements to print out the HTML tags contained in
the JSP. It's pretty ugly code, but since you don't actually have to
see or maintain it, whattayou care?
Now on top of that, you can use special JSP tags and occasionally
some JSP scriptlets in your JSP page. These also get compiled to the
appropriate java source code.
Some people report disatisfaction with JSP, and personally I was
kind of put off by the general concept. I've also heard some horror
stories about JSP nightmares caused by putting too much java code into
the JSP pages. JSP can be easily abused; I am by no means an expert
with JSP, but then again, I think most of the bad experiences people
have are because they get too clever with JSP and don't go to servlets
or to javabeans when they should. Maybe JSP taglibs will fix some of
that - JSP taglibs let you define your own special tags and implement
them in java.
However, a lot of that mess would be avoided if people used JSPs
well in the larger context. Start by making very shallow JSP pages -
basically little more than static HTML. Code servlets to do all of
the real programming stuff. Figure out what information the servlet
generates that has to go back to the user, code a javabean to hold
that information. A javabean is really just a class that follows a
set of naming conventions of having getSomeInstanceVariable() and
setSomeInstanceVariable() methods for each public instance variable.
When it comes time for the servlet to send info back to the user,
the servlet instantiates the relevant javabean, stores data in it,
stashes it either in a request attribute or in a the user's servlet
session, then uses the RequestDispatcher to (what else? :-) dispatch
the request off to the relevant JSP. The JSP has a "usebean" tag in
it that pulls that bean out and puts it in the JSP's local namespace,
where your other JSP tags can easily pull the information out of it
and into the page output. Anything clever in the way of java for
building the page should go in the javabean, not in the JSP.
You can use a similar strategy on the way in - read the JSP
tutorial to see how - to quickly and easily pull form inputs from a
request and put them in a javabean, then have the JSP dispatch that
off to the relevant servlet for serious processing.
I'm hearing a *lot* of good things about Jakarta Struts lately.
What exactly Struts is, is a little hard to say without more personal
experience of it. Struts is a combination of the MVC paradigm and
some other useful utilities. If you think that sounds really vague,
well, so do I, which is why it's "hard to say"...
The Struts taglib sounds really spiffy. Among other things, it
promises to do a lot of browser-specific tweaking and to generate &
insert browser-specific javascript code for a lot of
commonly-requested UI tweaks. That can only be good. It sounds like
Sun is trying to build a similar feature into the next round of JSP
with what they're calling "JSP Faces", which will be here someday.
Steven J. Owens
[EMAIL PROTECTED]
___________________________________________________________________________
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
