Helping ordinary people create extraordinary websites!

JSP Technology -- Friend or Foe?

By Brett McLaughlin
2003-03-07

Single-processing vs. multi-tasking
Ideally, as discussed above, a designer ought to be able to perform a single process, working purely on graphic design, and a developer should be able to focus purely on coding. So the designer should be able to work on a page after it has been converted to an application-suitable format. In the case of a JSP page, that would be after JavaBeans have been imported, inline coding has been inserted, and custom tag libraries have been added to the page. The problem is that some designers use HTML editors, such as HoTMetaL, Macromedia Dreamweaver, or FrontPage, that do not recognize code scriptlets or tag libraries, which means the designer effectively receives only a partial page. Imagine the difficulties when tag libraries or code fragments generate rows of a table, or other formatting details for the page. Designers using the incompatible HTML editors can't see what those elements look like. When designers can't easily revise pages after developers finish coding them, instead of clarifying distinct roles, JSP coding can cause them to merge: a developer must multitask, becoming developer, designer, and more.

Unconvinced about the importance of this feature? Then download the J2EE Reference Implementation and load one of the included JSP pages into a WYSIWYG HTML editor, such as Dreamweaver. The page immediately fills with yellow areas letting you know about all the "illegal" markup contained within the page. Of course, the yellow results from the JSP tags and code, rather than any real error in the page.

To date, no JSP-capable WYSIWYG editors exist, and I have not heard of any efforts to build one. While template engines have this same problem, many Java-based solutions, such as my favorite, Enhydra, allow you to supply the markup page as input to the presentation technology. In this case, the designer can make changes as often as needed and resupply the markup page. Running the engine or compiler for the presentation technology converts it to the proper format, and no code changes have to be made (in the typical case). The result is the desired one: designers remain designers, and developers remain developers.

So, be wary of the promise of JSP technology as compared to the reality of what it delivers. In practice, to function in a JSP technology-driven environment you must either have your developers handle a large portion of the markup or have designers learn at least some JSP coding.





Tutorial pages:

First published by IBM developerWorks
 3 Votes

You might also want to check these out:


Leave a Comment on "JSP Technology -- Friend or Foe?"
You must be logged in to post a comment.

Link to This Tutorial Page!
GET OUR NEWSLETTERS