Jayson Falkner's Blog

Blog, blog, blog, why would a professional J2EE developer do this?

Blogging, the shameless method of displaying ones opinions on the net. It makes a person feel important, authoritative, as if the whole world is taking the time to read what they write. I don't like blogs. I fail to see them as much more than another time-leaching distraction on the web. Sure, sometimes you will find a gem or two, but overall it is just another quick information fix for us net junkies.

But wait...what is this? Am I not working on a fix for the community, flicking the web's veins and preparing a sweet dose of subjective writing? No, I'm blargging. Blarg. I don't want to take any of your time. I want to return it. I want to help you get your job done. I want to help you to bedazzle your boss, and I want to send you home satisfied and ready to spend quality time with your family.

What can I do and why would I do it? Well, I can't do everything, but I can help with Servlets, JavaServer Pages, Tomcat, and most all of J2EE. If you are building a Web Application, I'm your man. Why? Well, I'm one of those guys that works full time consulting, helps with JSRs, codes open-source projects, and writes tech material. I am the guy that actually does this stuff all the time; I am a lost cause. I realize this, yet I'm not going to stop. I like this addiction. I like living in front of my laptop, and I like attempting to dispense advice from my quirky knowledge base. Use me. Ask me to help get your work done. Lean on one of the piers of the J2EE Web Tier.

Seriously, this blarg is for you. Send me questions about what I know. I'll answer them in a completely subjective and practical manner. You can find me here, at JSP Insider, at JSPBook.com, or at home. Any of the above will do, but lets see if we can blarg a dent in these java.net blogs.

Comments

• Why are JSPs still relevant? You seem like the perfect guy to ask. Let me explain the question; I'm in projects that run for a very long time, we have to maintain them and add features for at least a year, but probably longer. Having bare JSPs (or even really nice tagged ones) makes this hard to maintain and keep bug-free for a very simple reason; The application programmer has to do the work since there is no clear seperation of content and code. Plus the obvious code duplication etc etc etc. When I came accross WebMacro/Velocity etc my idea was that JSPs would be considered like c. Nice to hack in, but really not material to write full applications with anymore. I.e they seem like the natural next-step and the old would soon die out. Are JSP programmers not just holding on to ancient technologies like c-programmers (or pascal, or cobol) are to their unmaintainable stuff? So; if they are, then why are JSPs still relevant?

  Posted by: zander on October 08, 2003 at 01:59 PM

• Why are JSPs still relevant? JSPs in a "Model 1" style are old and antiquated, imho. Java code inside a JSP page is just horrible. Writing JSPs using JSTL core tags are fantastic ways to totally separate the coder from the presentation layer. Sure, as the programmer I have to initlaly write the JSP page as well as the code. However, if other departments don't like how my HTML looks, our content team manage to edit and understand JSTL-based JSP pages with no problems. As I understand it, JSP 2.0 will only help/further this effort. Webapp development with Struts & JSTL seems to be leagues ahead of most other systems - the ASP.net guys here are really struggling to get the good code/presentation separation that comes naturally with our Java codebase.

  Posted by: lee_ on October 09, 2003 at 01:37 AM

• Why are JSPs still relevant? Well; many people are quite capable of writing perfectly good c code as well; my experience with this freedom is that (escpecially new developers) people will use it because its easier to hack then it is to do it 'correctly'. If in JSP2.0 you are not allowed to use java code anymore, I feel a lot better already :) Is it?

  Posted by: zander on October 09, 2003 at 02:54 AM

• Why are JSPs still relevant? Thanks, I think I'm a good guy to ask too. I wrote you a nice long blog about this http://weblogs.java.net/pub/wlg/552.

  Posted by: jfalkner on October 09, 2003 at 10:46 AM

• Why are JSPs still relevant?

  You are absolutely right lee_. This is the primary philosophy I wrote about in Servlets and JSP; the J2EE Web Tier, but it takes a lot of material to properly explain it. The just is that you can make really simple, elegant, and easy to maintain code if you correctly know how to divide things up -- pretty much using good model 2 concepts. You can even divide things up between different people, say a HTML coder, a Java coder, and a database person, and ensure they can't step on each others toes, and still keep things really simple. The key is to spend a little time figuring out the important/clever coding techniques that let you do this.

  As for the Struts & JSTL people being leagues ahead of most other systems, I would tend to agree. The nice free, open-source but commercially backed approach JSP and Servlets has is really generating some good stuff.

  Posted by: jfalkner on October 09, 2003 at 10:53 AM

• Why are JSPs still relevant?

  Again, the point it well made. New users often resort to hacking in solutions, which can give flexible technologies such as JSP a bad name when really it is the new developers fault.

  Yes (still 'unofficial' but you can read in the proposed final draft of the spec), in JSP 2.0 you can choose to disable scripting on an application-wide, group of pages, or per-page basis. It is really slick, but nothing more than an easy way of doing an old trick -- you could have coded in a similar solution in JSP 1.1+.

  Posted by: jfalkner on October 09, 2003 at 10:59 AM

• A Solution If you don't like to blog don't do it. If you don't like to read about others opinion don't do it. But I guess this is not about blogging but more aobut having a catchy title that makes readers alert so that the blog is read. Blogging is a shameless act to publish its own opinion but to share opinions. On the other hand I find it very hypocritical to hate blogs and still write blogs.

  Posted by: schaefa on October 09, 2003 at 11:28 AM

• Why are JSPs still relevant? I'm not sold on custom tags either. It seems to me like tags are a whole other language within the JSP that someone has to know and understand. The idea of handing off an HTML page with custom tags to your GUI designer doesn't quite work in my experience. From a code reuse standpoint, it is a definite improvement over scripts within JSP includes, but still does not solve the maintenance and upgrade problem. Would it be more reasonable to truly separate your design from code by utilizing a template engine? I haven't had the opportunity to use one, but it seems like a good idea. Messing around with XSLT, I was able to convert an XML doc into HTML, PDF (using FOP), and WML. With a little more work, I could render more complex pages from the same source. That is true separation of content from presentation that JSP will never handle elegantly. I know at one time the Disney Internet Group's framework TEA was the template engine of choice. I'm not sure what else is an option these days.

  Posted by: john_watts on October 09, 2003 at 11:36 AM

• Why are JSPs still relevant? Custom tags are an improvement over java scriptlets, but certainly aren't perfect. But then again, neither are any of the alternatives. The root cause of the problem of course is that the 2 skills (design/artistic vs. programming/logic) are darn near impossible to find in a single individual. The problem with all of the existing solutions, including not only JSP but also various macro languages, template systems, and XSLT, is that the web designer still has to think in programming terms, i.e., branching, conditional logic, looping, etc. While some of the solutions are certainly easier for a non-programmer to learn than Java, the designer is still expected to learn that way of thinking. I think a better approach is to have the designer responsible for doing mock-ups of web pages, but not actually coding the HTML. They can continue to use the tools they're confortable with, regardless of how bad the generated HTML is (and it is often VERY bad). They should also continue to be responsible for a consistent site-wide look and feel, usability, site navigation, accessibility, and other design issues. They also have one more major responsibility, which I'll get to below. I think the programmers are better suited for writing the actual HTML. Now, before anyone says I'm crazy, what you need to understand is that if you learn to code HTML correctly, it's actually very, very easy, and DOESN'T REQUIRE ARTISTIC ABILITY OR DESIGN SKILLS. The problem is that we've all been brainwashed into using HTML in a way that was never intended. The extensive use of HTML tables for page layout, and font tags for specifying which fonts to use and their size and color, as well as vendor additions of other layout and style-oriented tags and attributes, has polluted a markup language that was originally intended to be platform-independent and free of presentation specifics. The new paradigm, that's just now catching on but still has a long way to go, is to write very simple, clean HTML (preferably XHTML), and use CSS (Cascading Style Sheets) for virtually all presentation specifics (layout, fonts, font colors, font sizes, background colors, borders, etc.). If you're still skeptical, I'll point you to a great example. Visit http://www.homelesspixel.de/remix/ . This page won a contest for re-designing the home page of the World Wide Web Consortium (http://www.w3.org) using XHTML and CSS. What's amazing about this site is the simplicity of the underlying HTML, considering the sophistication and artistry of the page layout. The key is taking advantage of the power of CSS. To create that fancy orange date element associated with each article, all the HTML coder need to know is to surround the date with a span tag with a class attribute of "date". He doesn't need to know anything about how to specify the color, or the font, or the light gray background color, or the medium gray solid border, or the slight offset to the left. These are the responsibility of the site designer (the responsibility I left out earlier) and are completely handled by the CSS stylesheet. And here's the kicker. The site becomes much, much easier to maintain, because in order to change the look and feel of the entire website, all you need to do is update the CSS - you don't have to touch the HTML! Tired of the orange theme at http://www.homelesspixel.de/remix/ ? Just click on the "green it!" menu choice under the "choose your style:" heading at the upper right of the page. For some even more dramatic examples of dynamically changing presentation using CSS, visit Eric Meyer's website at http://www.meyerweb.com/eric/css/ and click on the various menu choices under the "Presentation" header. And also note that, because this HTML is so clean, it is generally extremely easy to make it display in a very clear and desirable way under even the most antiquated browsers (for example, click the "void(style);" presentation on the Eric Meyer website, which displays the same HTML page with no stylesheet). Sure, it'll be bland, but the information will be laid out in a clear and very usable manner. No need for "This site requires Microsoft Internet Explorer version . . .". So ultimately, with this approach, your programmers can create the JSPs (preferably using custom tag libraries and avoiding scriptlets) containing simple HTML markup, and the web designers can concentrate on layout and other presentation details by authoring the CSS stylesheets. I think this approach does a better job of separating presentation from programming. Of course, I could be wrong. By the way, as you mentioned, XSLT is a very powerful tool for dynamically generating various output formats. The Apache Cocoon project (http://cocoon.apache.org) supports exactly what you described, and may actually be what you were alluding to. Cocoon supports the use of JSPs as generators, so your JSP can dynamically generate XML instead of HTML, and subsequently Cocoon can use one or more XSLT transforms to eventually serialize the output to HTML, PDF, WML, etc. So the combination of JSPs and XSLT can give you the best of both worlds.

  Posted by: kdenehy on October 11, 2003 at 11:52 AM

• Why are JSPs still relevant? Thanks for the extensive feedback. I was on a project that made the leap to convert all the JSP pages with hard coded style to use CSS. It took awhile, but it made a significant difference. We still had to recreate the pages with our imbedded scriptlets, but at least the next L&F change would be easy. That's when I started scratching my head over the use of custom tags. We still would have had to put in our custom tags after the fact since the designer was off in her own world recreating from scratch. Again, true separation of content to me means eliminating custom tags and going with the Cocoon approach. If you're generating HTML and CSS from a set of source data, then you can achieve the goal of having designers do what they do best and programmers do what they do best. I'm just not sure the practicality of doing that approach across a large project or IT organization. It would take a great deal of education and proof of concept demonstrations to get people to think of web programming in a different way. The CSS in HTML argument would be a much easier sell. Today, I'm part of a company's architecture group which is planning a set of J2EE components to help speed project development. With 15 - 20 projects in production and another 15 in the works, we're looking at ways to help standardize the development of applications in hopes of promoting "pluggable programmers". The past has been fraught with developers learning niche technologies which limits their reusability within the organization. The Cocoon concepts are too radical for our IT department. (There are still people who think J2EE is NOT a viable solution for production quality products despite the fact there are 15-20 in production!). I can see now how tags will make it easy for us to implement corporate-wide features. For example, there is a central reporting engine. We can write a component to facilitate the request to the report server and a custom tag to handle the response from that server in the JSP. By handing over a corporate custom tag JAR, projects can start using those services without having to spend a great deal of time understanding how the various API work. I too am not sure what the “answer” is. I think it’s like Java in general. There is more than one way to solve the problem, so you just have to pick the solution that fits your problem domain the best.

  Posted by: john_watts on October 14, 2003 at 05:55 AM

• A Solution I think I get what you are saying, but please correct me if I did not understand you clearly. Sure, maybe I'm a hypocrite.

  Posted by: jfalkner on October 14, 2003 at 03:50 PM

• Why are JSPs still relevant? I really like your answer, and I pretty much agree with exactly what you are saying. Restricting JSP use to HTML/CSS is a fantastic way to do things, and it accomplishes almost anything you might be trying to do. A note on XSLT and stuff like Cocoon. I throw that in to the waste of time category for a JSP/J2EE developer. You don't need them, and in general they are just doing what JSP does but in a different way, a way that will take more time for you to learn and not help your JSP/Java skills.

  Posted by: jfalkner on October 14, 2003 at 04:09 PM

• Why are JSPs still relevant? Please send me a question asking about custom tags. Tell me why you aren't sold on them, and I'll elaborate on why I too think they aren't that helpful. In my opinion there are really only one or two good uses for custom tags, and for most practical purposes you can ignore them. On a side note, it seems like you have been influenced by Jason Hunter. Did you read his book? Yes, true separation of design from code is important, but I'm saying you can do this with JSP. Not only that, but you are wasting your time looking elsewhere since JSP is the standard (assuming you aren't a microsoft guy :). Spending time on stuff like FOP or TEA just leaves you understanding there is more than one method to get the job done. That is always the case. I think it is best for a Java developer to spend time learning how to cleverly use the standards and to then get work done. You'll end up having spare time, and you'll also have a skillset that will surely be worth some money for several years to come.

  Posted by: jfalkner on October 14, 2003 at 04:17 PM

This work is licensed under a Creative Commons License.