Hi,
>I think it depends on your starting point. I'm comfortable using JSP
>too, because I understand what's going on underneath. I'd rather not
>have to think about that though.
But, I would think a java engineer would pretty much figure out whats going
on underneath anyways..especially if they are using servlets. I would hope
that when an architecture is chosen, or some method to ease someones life,
they know WHY they have chosen that route over others. This generally means
understanding whats going on underneath. At least for me it does.
>However, I feel the "graphics artist" that's targetted by JSP won't
>understand the difference.
That is why the JSP developer would create either a taglib, or a JavaBean
with methods that return the HTML. Sure, the JavaBean approach isn't quite
what JSP is all about, but it does make it easy to "hide" all the details
of looping, with a simple <%= bean.getXXX() %>. I mean..if all you had to
do was put a bunch of <%= bean.getXXX() %> on a page, how hard is that to
learn? Since HTML tags are pretty much going to stay the same, with the
exception of maybe new tags, using a JavaBean to return the HTML as a
"component" bean, I see no big deal in that, AND its far easier to learn
than using JSP or WebMacro. You just get a list of what the bean can do
(method calls). Voila!
>Easy enough for Java programmers. I'm OK with JSP being "a cheap way
>to write servlets". I've used it that way myself. However, when you
>get non-Java programmers into the mix people should be aware that there
>are other options that might work better for them.
As another fellow responded to you, I dont see much difference in the way
WebMacro does things. Either way, the HTML guy/gal will have to learn it.
Like I said above, if a JavaBean were to be used inplace of JSP scriplets
that just returned a result, hiding the implementation details, or a taglib
is used (JSP1.1+), that should make it much easier than learning either JSP
or WebMacro.
>No, nor does it need to be. Not everything needs to be in a
>specification. Not everyone has to do everything the same way.
>If your servlet uses a template engine, just include the engine
>classes along with your app and it'll work everywhere.
But what if your template engine only runs on Windows, and you want to move
to Unix? You cant. Not a very viable solution in my opinion. The main
reason people go to Java is its portability and ease of use (ok..thats why
we went to it), surely not J2EE or some specification. However, those
"standards" do help in conforming more companies to back it, which means
the likelihood of moving your Java/JSP/JavaBean code to another vendor
looks good. Even on a different platform.
I cant say if a template engine such as WebMacro exists on multiple
platforms or not, but I would imagine JSP/JavaBeans/Java has a much wider
range of platforms and far more support in app servers and web servers.
>All engines support template engines, without any changes to the
>server. No vendor-specific JSP bugs. :-)
Point taken.
>Whoa, you haven't used template engines. Perhaps you can go try it,
>use both on a real site, then decide if you still prefer JSP.
>That's what I did.
Actually, we did our own template engine via a servlet for a while. I can
say this..it was 8 times slower than JSP is. That might be because we parse
a "template" file replacing tokens with dynamic content in the servlet, but
it was FAR slower than the JSP site is now. Now, I'll give credit where its
do..our template servlet read in a template file EVERY time it was
requested. I imagine that WebMacro and others compile the .wm file into a
HTML file that gets sent back..and it does this once? Or does each request
to web macro and other template engines have to replace the web macro stuff
with dynamic content?
>Template engines are just classes like
>com.oreilly.servlet.MultipartResponse that help you generate content.
>You can have them serve .wm files if you like, such as when you're
>doing includes.
Yea..figured as much.
>JSP 0.90 I liked. It was an easy way to write servlets. Now JSP has
>been targetted at the non-programmer and I don't believe it can succeed
>well in that market, at least not without a great dependence on tools.
>Maybe that'll be its ultimate savior.
Hmm..good point. I didnt read much on .9, but I do agree that JSP 1.0 and
1.1 are more for developers than web gurus. I would imagine that this has
been thought out like this because the idea is to divide the project up
amongst many developers and web editors. Since I, probably like you, am a
"lone" web guy, I can see where it would be a problem, especially if you
know HTML/JavaScript but dont know Java. However, I have to assume that
your taking the point of a web developer that has to learn JSP, well..they
would have to learn Web Macro as well. Maybe Web Macro is easier to
learn..that I cant argue for or against. But, becuase my mindset is the way
it is (Java engineer..dives into JSP to make our site much better, part of
J2EE, etc), JSP seems a natural course of evolution for our site.
>In the second edition I'm demonstrating how to do "Model 2" using JSP.
>That's arguably the best technique for JSP and belongs more in the
>servlet book than the JSP book because it's servlet-centric.
Yeah..I have been altering my views on Model 1, 1.5 and 2. I use Model 1.5,
where JSP pages are the controller and viewer, but all the logic is done in
beans. I dont put any logic in the JSP page except when absolutley
necessary, such as a conditional scriplet to display one set of html over
another based on a flagged value or some other value. I almost went the
Model 2 approach, but it involves alot more coding and maintaining
initially, and we dont have the time for that. I read some articles saying
its more scalable in the future. I dont see how its any more or less
scalable than Model 1. I really do agree with the syntax of the servlet
doing all the logic, then passing it on to the JSP, I just dont like the
amount of code to do it. Its not that its a lot..its that its "easier" to
do it the way I am doing it now. The only thing I dont care for the way I
am doing it is the way forms need to be submitted. I either have to submit
them back to the same jsp page with some scriplet code in it to call a bean
method to handle the request (based on a parameter being in the form..a
hidden parameter), or submit the form to a new jsp page that does the same
thing, thus making more JSP pages. I am still not sure the route to go. I
do like the layout of Model 2..a JSP page being nothing but a view. But, I
argue that using the Model 2 still requires the creation of a bean in every
method, AND you dont automatically populate a beans properties with the
form data being passed in to the servlet, whereas the bean being used on a
JSP page with the <jsp:setProperty property="*"/> does this for you
automatically! That avoids alot of request.getParameter() calls to set the
created beans properties in the servlet. Unless..is there a better way of
doing this in the Model 2? Now..if they allowed a bean created in a method
to be populated through introspection by the request object in some
manner..that would be kewl! Then I would definitely go the Model 2 route.
Anyways..your still a java guru! ;)
Kevin Duffey
Software Engineer
[EMAIL PROTECTED]
===========================================================================
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
