Hans Bergsten wrote:
> First, I'm sure we can argue this back and forth forever without
> totally convincing each other. But hopefully we, and others, can
> at least learn something about the pros and cons with the two
> alternatives.
Exactly! I say you should use whatever you like. I'm just shocked
how much play JSP has gotten and how little play other servlet-based
solutions have gotten.
> I believe most of the areas you bring up can be solved with custom
> actions in JSP 1.1 today, and even better tomorrow when the most
> commonly requested custom actions get standardized. As you know,
> there's an approved JSR for specifying a standard JSP tag library.
Yep, that's the best hope for JSP.
> The reason I feel that custom actions are so important is that I'm
> pretty sure that the majority of the web sites we see today are
> developed with tools like FrontPage, NetObject Fusion, DreamWeaver,
> etc. rather than by people hacking HTML in a text editor.
Maybe, although in polling people at Web99 conferences I found BBEdit,
HomeSite, and vi extremely popular tools. Professionals, it seems,
prefer to have ultimate control.
> Tools like this makes it possible for people
> without programming skills to develop fairly sophisticated dynamic
> web sites.
If a tool can generate a JSP page, why can't the tool just directly
generate a servlet? :-)
> I must admit I have not looked much at WebMacro (yes I know, I
> should),
>From the email I've received tonight in response to this article, no
one who has used WebMacro has disagreed with my points. The only
disagreements have come from JSP-only developers.
> I get the feeling that it requires Java programmers to develop
> the request processing and business logic pieces, and the templates
> are pure "views".
Depending on use. WM has a capability similar to custom tags that
could allow the use of a generic support servlet for simple tasks.
> That's ideal for a complex web application, when you have access to
> both programmers and web page developers.
Yep.
> Tools that makes it possible to develop these apps without having
> access to programmers is a big advantage. There are a lot more web
> page designers out there than there are Java programmers.
Sure enough. That's why I'm concerned on JSP's general reliance on
Java syntax.
> > And you (should) write OO C++. Meanwhile, Java makes you. I prefer
> > that, just as I prefer how template engines enforce the separation.
>
> Both these arguments are moot if you, as I, believe that higher level
> tools than a text editor will be used to develop the web applications.
Reliance on tools to hide underlying complexities doesn't feel right
to me. When you have to leave the tool (and you will) you're going to
be stuck with a mess.
> > Plus, JSP 1.1 support is very spotty and each vendor has
> > their own bugs you have to work around. There's something nice
> > about WebMacro working with the older Servlet API 2.0 and without
> > any vendor-specific bugs. There's just the one open source
> > implementation
> > to fix bugs in. Kinda like Perl.
>
> This is just a matter of time. You know as well as I do that most
> vendors have beta versions for JSP 1.1 available, or has announced
> support to be included in products released during this spring.
But if your ISP supports Apache/JServ as many do, how long will you
have to wait until you get real JSP 1.1 support? Isn't it ironic that
the "standard" solution is the one you can't use?
> As far as bugs go, having just one vendor doesn't mean that it's bug
> free;
No, but it has the same bugs everywhere. That means no surprises, and
easy to develop workarounds. Plus, since you have the WM source you can
fix the bug yourself and just use your custom build.
Applets are a pain in the neck because you have to work around every
browser vendor's bugs. Even old browser bugs since the client may still
be using that browser. JSP pages suffer the same problem. To be
portable they have to work around the bugs (or "alternative spec
interpretations") present in all servers. Bugs in old servers will
have to be worked around as well as long as people use that server. A
WebMacro-based program can ship with the WM classes and be sure to work
everywhere. If WM has a bug fix, the app can ship with the new WM
library.
> and even with one vendor for the template system you may run into
> vendor specific bugs on the platform where you deploy it.
But it's so much less likely than JSP implementation bugs.
> > C++ vs Java: C++ has a String type in the STL, but it'll always
> > be an add-on even though it's a standard.
>
> The standard tag library will likely make this point moot.
Maybe. The taglib will be designed by committee. Watch out!
> > Perl isn't formally specified apart from implementation (at
> > least I've
> > never seen the spec), but yet it's still *widely* covered.
>
> Sure, only time will tell if WebMacro (or another template system)
> will gain this kind of exposure. I'm, however, sure that the fact the
> JSP is part of J2EE pretty much guarantees that it will be widely
> covered.
Yep. That's why you're smart to write a book on JSP and not on
WebMacro! :-) But I wouldn't mind seeing alternatives to JSP getting
more attention.
> You made a few other interesting points in your article that I like to
> say something about as well.
>
> [Jason] Problem #5: Useless Error Messages
>
> Yes, here we're in full agreement! And if you use scripting elements
> you will run into this sooner rather than later. That's yet another
> reason why I promote using custom actions, removing virtually all
> Java code from the JSP pages.
You can still get weird error messages even if you take all the Java
code out of the page. For example, change the <jsp:useBean> class
attribute for a session bean while your server's running. You get a
strange ClassCastException. Why? Because the server pulled the old
version out of the session object and tried to cast it to the new type.
You have to restart the server for it to work again.
I suppose a smart JSP implementation could work around this, but then
running your JSP page on a less-than-smart impl won't work. See
vendor-specific bug discussion above. :-)
> [Jason] Problem #6: Need a Compiler
> Not completely true. Sun has allowed ASF to redistribute the javac
> compiler, in a separate JAR file as opposed to the complete tools.jar.
What about other servers?
> [Jason] Problem #7: Wasted Space
>
> Yes, the class files take up disk space. But disk is cheap, so I
> don't see this as such a big deal.
Does no one expect to use an ISP to run their JSPs? 30 Megs is your
standard allotment.
> I'm not convince the difference is so
> big. I assume that for a high performance site you would end up
> caching all templates, which would require roughly the same amount
> of memory as JSP class files.
Except the templates can be removed from cache when memory runs out.
JSPs generally can't.
> But even if you're right, memory is also cheap.
ISPs won't be happy to hear about JSP's memory usage. They want to host
large numbers of sites, and don't want each bloating memory.
> So have you changed your mind Jason? I didn't think so ;-)
Hee hee. Have I changed yours? :-)
-jh-
___________________________________________________________________________
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
