You will, of course, get opinions across the entire spectrum, but that's what I'm seeing a great deal of.
Or is that not what you were asking?
From the small amount of information that I have read, it appears that JSP is no longer the preferred way to present the GUI? Or am I way off?
How about, the trend is "poorly written and poorly designed Java Server Pages(JSP) are no longer the preferred way.
Sloppy, unmanageable JSPs with nested business logic are no longer in fashion
"Out of the box, JSF 1.x uses JavaServer Pages (JSP) for its display technology, but can also accommodate other technologies (such as XUL and Facelets). JSF 2 uses Facelets by default for this purpose. Facelets is a more efficient, simple, and yet more powerful view description language (VDL)."
My learning "trail" has been simple Servlet/JSP stuff. As a matter of fact I got most of my start right here in the "servlet" trail: "http://www.javaranch.com/drive/servlet/index.jsp".
Every time I start into Sun's official tutorials concerning J2EE/Servlets I begin to get the "I am overwhelmed" feeling. So instead, I started looking into Tomcat. But I am not sure of it's advantages over Orion, which I already have set up.
Point being that I am doing this for my own educational benefit and have to fit it into my regular work schedule, and therefore want the most streamlined approach. I like things as simple as possible from both a programming perspective and, for that matter, from most other perspectives as well. Thanks again for your help.
Bill Johnston wrote:Every time I start into Sun's official tutorials concerning J2EE/Servlets I begin to get the "I am overwhelmed" feeling.
This is a long way from "to JSP or not to JSP", but that isn't an unreasonable feeling. Programming languages are easy, if you want something done you write some code, and if you want to change that then you change the code or write more of it. But the Java EE trend is to take things out of programming and to put them into configuration.
This is a good thing to do, from the design point of view. However in practice to change the configuration you have to track down scattered bits and pieces of configuration from all over the place. A real-life example: we're upgrading our database server to a new version. So we set it up on a new server, and created a test copy of our old database. It turned out there was a bug in the current JDBC drivers for that DB so we had to include a file which patched the bug. I wrote up the process for changing the Websphere configuration for the connection pool, and by the time I finished there were 19 steps in the procedure.
And that's just a small part of the procedure for setting up a working instance of Websphere, even though we aren't using EJBs or anything complicated. If you go over to the Ranch'sWebsphere forum and scan through the posts, you'll see that many of them are about configuration problems. Most of those go unanswered because you can't say "Post your configuration and let's have a look at it".
So anyway, yeah, as the others have said, stick to JSPs for getting started in Java EE. It does take some getting used to no matter what you choose, so sticking to the standard methods is best until you know what you're doing.
The application server is a good example of this. I chose JBoss AS (community edition) because I had previous experience with it.
I agree that Servlets and JavaServer Pages are not old technology (yet). There are so many tutorials that walk you through all that is needed to use them, it just takes time to go through them. To help me, I downloaded Eclipse (Galileo) and the JBossTools plugin (or whatever they call it) which provides JBoss-specific features to Eclipse. Now, it's easy to create a full JEE application which includes Servlets and JSPs, Session EJBs, Entities, etc. and deploy on my JBoss application server.
If you want help getting started, there's just no better place than Java Ranch. If you want more information on what I did to get rolling, just ask and I'll provide you with some links, etc. ... and of course you can always ask questions.
One quick comment concerning the " ... scattered bits and pieces of configuration from all over the place.", and about my own "Keep it simple Stupid" point of view ...
In a prior job I worked with one particular gentleman who was known to have an exceptionally high IQ, and who could routinely do the NY Times Xword puzzle in about 3 to 5 minutes, and his programming logic could be relied on as solid. He took things to an extreme, in that, as I recall, he had made it his personal quest to decouple Cobol main programs from one or more particular subprograms, by modifying the main programs that called the subprograms; because to him it was much simpler that way. Though probably all of us would agree - if I may be so bold - that it was very bad design to do so.
I guess then, that intellectual capability is not the sole reason for making things either simple or complex, and that there are always more than "one way to skin a cat" ... though I can assure you they are all messy. regards,
Deepak Bala wrote:As much as I love JSTL + EL + JSP, I still find that many are unaware of EL and script-less pages
Yes, I find it quite amazing that over eight years after the introduction of JSP 2.0 with it's native EL implementation that people still write JSPs as if it were 2002.
It might be attributed to the fact that most books on JSP still teach scriptlets as part of JSP (because they still are -- not officially deprecating scriptlets with JSP 2.0 was an mistake, in my opinion) and don't emphasize good practices and use of the JSTL and EL enough.
Since I went through Servlets first, I didn't find this too distracting - I just basically ignored certain sections of the book, as it was clear to me that the code being considered would be done within the Servlet and not the JSP. I can see, though, how this may lead some in the wrong direction.
The book did a real good lob teaching me JSTL though, so don't get me wrong. I'm just glad I had an understanding of Servlets and MVC design patterns before I read it.