JSP Technology -- Friend or Foe?
By Brett McLaughlin2003-03-07
The problems
|
|
I've spelled out what a good presentation technology should provide, as well as the specific problems that JSP technology seeks to address. Now, I'm ready to cut to the chase: JSP technology, while built on good ideas, presents quite a few problems. Before you choose to use JSP coding in your applications (which you might still do), you should at least be aware of possible pitfalls.
You should also be aware of a facet of the J2EE programming platform that is often ignored: just because an API comes with the platform doesn't mean you have to use it. As silly as this sounds, many developers are struggling with the JSP, or EJB, or JMS APIs, thinking if they don't use these APIs, their applications somehow won't really be "J2EE applications." In fact, the platform boasts more APIs than most applications need. If you have problems with or doubts about JSP technology, you don't have to use it! Take a close look at both the positives and the negatives before choosing to use JSP technology in your applications. Let's take a look at some of the negatives.
Tutorial Pages:
» A critical look at JavaServer Pages servlets as a viable presentation technology
» A bit of history
» The premise
» Segregation vs. integration
» Work vs. rework
» The promise of JSP technology
» Content vs. presentation
» Code vs. markup
» Designer vs. developer
» The problems
» Portability vs. language lock-in
» Mingling vs. independence
» Blurring the line between content and presentation
» Single-processing vs. multi-tasking
» HTML vs. XML
» Summary
» Resources
First published by IBM developerWorks
|
