Jayson Falkner's Blog

October 2003 Archives

Blarg #3: About the new JSP EL, who is using it? Plus a few other questions.

Jayson,
Maybe you can make sense of this EL question. Background is after the questions.

1.) Who is the EL audience?
2.) How is Sun marketing EL to PHP and non-java web developers?
3.) Is this more fashion than function?
4.) Are non-java developers using EL?
5.) Does EL make it harder for java developers?

At a recent JUG, people unanimously said Java code in JSP is bad. In a JSF example involving database access, the group, with the exception of one lady, said that it was OK to use SQL in your JSF/JSP despite the recommendation against it. (She asked "what if your table name changes and you need to change the SQL", to which the group replied "you have a dba/design issue if they change table names on you").

My opinion is that <%//Some business/data logic%> and are about the same to non-developer web designers. They both basically say "stay away from this chunk here".To the extent that you can push code out of pages, it's a good thing.But then again, I was a roll-your-own-JDBC guy until I started using hibernate extensively. Now I cringe if I have to type Class.forName("jdbc.xyz...");
-Don

Good question Don, thanks for asking it.

I'll answer your five points then address your background information. It seems you are asking a little about the new JSP (i.e. what is it good for -- why would one want to use it) and you are also touching on the ever popular topic of good JSP programming practices.

1.) Who is the EL audience?

JSP 2.0 and above developers is the easy answer. The more practical answer is, anyone who understands good JSP coding practices -- basically, anyone who wants to more easily code and maintain a JSP, especially when working with more than one developer. Of course, I'll expand on this later, during your third point.

I think it is also worth saying that assuming the JSP EL is targeted only to scripters, such as PHP or Perl programmers, is a poor assumption. In my opinion, you are best off thinking of the JSP EL as allowing JSP to work as a template in a Model II (ish) design. Remember the JSP EL only evaluates simple expressions (well, as of the unofficial 2.0 spec), you can't dump lines of code in the middle of a JSP EL expression.

2.) How is Sun marketing EL to PHP and non-java web developers?

As far as I know, Sun is not making serious efforts to market the EL to PHP and non-Java web developers. Although, remember I am not working for Sun...my opinion comes just from what I've seen. I think JSP itself is the thing Sun is marketing to non-Java web developers, the EL is a perk that will allow for cleaner JSP.

3.) Is this more fashion than function?

Absolutely not. Personally I use the EL extensively in all my JSP projects and I'll never go back to custom tags or scriptlets for showing the value of a request-scoped variable. Why? In short, using something like ${foo} or ${foo.bar} anywhere in a JSP is way too convenient, especially if you consider that you can access an object in any scope (i.e. request, session, application) and that you can disable scripting while doing it.

For the long reasoning why, check out my book, Servlets and JavaServer Pages; the J2EE Web Tier. It walks through what the EL is, how to use it, and why it works a heck of a lot better than scriptlets and custom tags.

4.) Are non-java developers using EL?

Maybe, but I think they are hanging out with the JSP developers that are using non-Java languages in the scriptlets.

Seriously, no one that I know of is actually using the JSP EL outside of Java. However, I think you might have phrased the question slightly off. The JSP EL for a long time was rumored to be made in a fashion that would allow it to be used in any Java app (or just about any non-Java app), and some Java classes that could make sense of EL expressions would be made readily available to all developers. Meaning any Java app could use the EL, not just JSP apps. I think this idea is silly, and isn't worth dwelling on. Things like the EL are good for lots of things, but optimizing the JSP EL for things JSP developers do is what makes it helpful to use. As is, I consider the JSP EL optimized for JSP development.

If you meant, are things like the JSP EL used outside of Java and JSP. Absolutely. The JSP EL is pretty much an adoption of expressions used by other popular projects such as Ant and Velocity. The important concept is that you can split a dynamic web page in to two parts, code to generate dynamic values and a template to display those dynamic values through. The EL is the component that allows a template to take and display a dynamic value. Also, it is important that languages like the EL only allow for simple expressions, not full blown chunks of code such as scriptlets allow for. This helps ensure one is forced to keep business/database code and presentation code separate. Other non-Java technologies pioneered these concepts, and they use EL equivalents.

5.) Does EL make it harder for java developers?

Not really. In the case of JSP, the whole idea is that Java developers don't have to care about the EL. Coding Java is the same as coding Java has always been. However, accessing dynamic values that are placed in request, session, or application scope by Java code in JSP is now trivial thanks to the EL. This is helpful because if you are an HTML developer you can get away with skipping Java knowledge all together. If you assume your buddy the Java developer correctly populates the request-scope variable named "name", you can access it with an EL expression, e.g.:

<html>
Hello ${name}, welcome to the website.
</html>

And teaching someone who knows how to use HTML how to use ${name} takes about two seconds. Likewise, you can generalize this example by assuming the HTML/interface people meet with the Java people and agree upon a set of request-scoped variables, e.g. name, date, favoriteColor, etc. Coding the Java to populate request-scoped variables is the same as it ever was -- if anything it might be made simpler because of how the '.' character does all sorts of great things in the JSP EL.

At a recent JUG, people unanimously said Java code in JSP is bad. In a JSF example involving database access, the group, with the exception of one lady, said that it was OK to use SQL in your JSF/JSP despite the recommendation against it. (She asked "what if your table name changes and you need to change the SQL", to which the group replied "you have a dba/design issue if they change table names on you").

About Java code in JSP. Yeah, pretty much bad, but not always. Remember two things. JSP EL isn't Java code, EL expressions are simple, one-line expressions -- often just something such as ${foo}. The second thing, remember design patterns such as Model 1 1/2 still work really well and they allow for as much Java code in JSP as you want. The drawback is you aren't enforcing that pure Java code is kept away from the HTML. See the book if you don't know about Model 1 1/2 or ask it to be a blarg topic.

About SQL code in JSF/JSP. I have really strong opinions about this. I think you can't ever justify putting SQL in your JSP when you are building a real web app. It just mucks things up in the long run. You'll note, I wrote several paragraphs on why I think this in my book, and I even explain why it isn't worth your time to even consider using stuff such as the JSTL SQL tags. In short, your JUG response is a good one, and if you ever hear someone rambling on about putting SQL in your JSP, ignore them. Odds are they don't really build web applications.

A funny note is that I once made a fool of myself while harboring the above mindset. I was talking to some Sun buddies at JavaOne and I basically explained why I thought it was a horrible idea to have ever considered making the JSTL SQL tags. The argument was well received, but it just so happened the person who put the JSTL SQL tags in the JSTL was part of the discussion...oh how sweet my foot tastes. Sorry queen of taglibs!

My opinion is that <%//Some business/data logic%> and are about the same to non-developer web designers. They both basically say "stay away from this chunk here".To the extent that you can push code out of pages, it's a good thing.But then again, I was a roll-your-own-JDBC guy until I started using hibernate extensively. Now I cringe if I have to type Class.forName("jdbc.xyz...");

I'm taking a guess at what you mean by this. If non-developer web designers (i.e. the HTML folks) see either scriptlets or custom tags they shouldn't touch the code. Fair point, and I think it merits some agreement. However, I think you should always assume the worst, e.g. assume the HTML folks could care less about your code. The best approach is to ensure non-developer web designers can not touch code that they shouldn't be allowed to change. In other words, do not put Java code on a JSP. Give HTML/CSS coder equivalents free reign over the entire presentation page and train them -- in the simplest possible way -- to display dynamic information. Basically, teach them the just of the JSP EL and teach them how the JSTL iteration tag works. Then disable JSP scripting all together, which you can do in JSP 2.0 -- note, JSP EL is not scripting for this case. As for how dynamic values are put in to request, session, or application scope, that is up to you. Look in to Model II.

About Hibernate versus Class.forName(...). That is a really good point. If anyone who is reading this is using Class.forName() with JDBC device drivers, stop...stop now. At least use a DataSource object or at most look in to a full framework for abstracting database connectivity. A little more of a stretch but still a good analogy is comparing scriptlets versus Model II combined with the new EL. Stop using scriptlets, stop now. If you don't know what I'm talking about, ask a blarg or read a good book.

Cheers,
Jayson Falkner - jayson@jspinsider.com

Blarg #2: What do you think about weblogs?

Hi lee, thanks for asking. I don't think I can fully answer your question, but hopefully I can provide a solid opinion and provide a place where others can add their thoughts. Since you squeezed a few questions in to one e-mail, I'll try to break them up before answering.

I don't think it is my business to be saying who should and who shouldn't blog. As I understand it, part of blogging is that it is something anyone can do, and I think that implies anyone who wants to blog should blog. However, I would answer the question completely differently if you were asking if I think all blogs are helpful. I have formed the general opinion that most blogs are not good for trying to get work done.

Again, I don't think I am the one to say what I think blogging should be for. Blogging is popular because anyone can do it and usually there is little to no peer review or editing of what someone blogs. That means blogging is useful for just about whatever a person can blog well about.

However, if we narrow down the question to only consider blogging as a tool to aid Java/J2EE developers. I would say blogging isn't really helpful for either of your options. Once a developer starts searching the web it usually means they have no clue as to what they need to get done, and they are looking for some free, quick answer to their solution. Blogs aren't about that, and that is also why I'm playfully naming these answers "blargs". Blogs are usually just a kind-of popular Java/J2EE figure venting some thoughts. Hopefully my blargs will be popular enough to make people start to think blogs can be helpful for your second option, answers to specific problems. But really, I'm just doing free, no-liability consulting and it happens to be getting publicized via blogging. I don't think that will ever go mainstream.

If we consider the case where you are a Java/J2EE developer who has some spare time on his or her hands, then I think it is fair to say blogs are a good way to feel out the current state of things in the Java/J2EE community. I would equate it to something like slashdot.org. If you are a geek drinking some coffee and killing some time, slashdot is a fun way to feel like you are hip to the tech community. Likewise, if you are a Java person who is just killing time in front of your computer, Java/J2EE blogs can make you feel like you are hip to the current happenings of other developers. Although in both cases it doesn't mean you will be any more productive at work.

If you want to blog you have several options. No, you don't need to set up software on your own site, but you could if you wanted. Usually if you have your own site you can simply edit an HTML page to include your thoughts and call it a blog. But, if you want to have flashy user feedback and such you will need to either do some coding or install an existing package.

In general if you just want to blog you can find a site that will let you do it for free. Off the top of my head I know this site does it (although I never figured out if anyone can start blogging for free) and JavaLobby provides JRoller, http://www.jroller.com/, which you can also get the source-code for if you like. Outside of those two I can't say much beside that I have heard of tons of other free open-source weblog packages, but I don't know any names or links. I think this is a question best left to others to help with. I'm sure a good deal of the people that read this will have a link or two to suggest, and if that is you, please post the link in the talk-back.

Cheers,
Jayson Falkner (jayson@jspinsider.com)

Blarg #1: Are JSP Still Relevant?

Blarg #1: Why are JSPs still relevant?

You seem like the perfect guy to ask.

So; if they are, then why are JSPs still relevant?

Great question zander, and it is one I just so happen to have a lot to say about. You would be surprised how often this type of question seems to pop up, not just about JSP, but about just about any J-starting acronym the marketing folks throw to the masses. In some cases it is valid to ask, say the technology in question really is dated...or it was just pretty worthless in general. However, in the case of JSP, there are several great reasons it is still relevant. I'll address a few of the particular reasons I think are most important, and I'll try to phrase things assuming you don't know much about JSP. I don't mean to be condescending, but far too often this type of question is asked simply because the person doesn't really understand what the J-starting acronym really describes. If you aren't that type of developer, then please bear with me, I'm assuming there are plenty of other developers who will certainly appreciate an answer that doesn't assume much.

My reasons for why JSP is still relevant.

1. JSP is a key part of the J2EE Web Tier
2. JSP is The standard
3. It is easy to use JSP in amazing ways

JSP is a key part of the J2EE Web Tier

J2EE is huge, and almost all of it is good for at least one particular task. People do spend a lot of time (namely JSR expert group people) designing each and every J2EE related technology, which means in general something helpful is made. Note, this does not imply that your work will benefit from every J2EE technology, say JSP in particular. So let us be clear on what JSP is good at, and then you can decided if you are trying to do that, or if you could care less -- either way we should hopefully agree JSP is a technology worth keeping around.

So what is JSP good for? JSP is great for generating dynamic web pages, think any web page that uses markup, e.g. HTML, XHTML, WML, or even just plain text. When I say "dynamic" I mean something that changes. A good example would be an on-line store like Amazon.com that takes a little bit of information from you, say a title of a book, and automatically generates tons of HTML-based web pages that try to get you to purchase something. This is dynamic because Amazon.com certainly doesn't have billions of HTML files saved on their servers, it wouldn't be practical. Amazon.com only keeps around key information about books, and when needed uses JSP to generate HTML on the fly. A bad example of dynamic is something like my personal resume. It is nothing more than an HTML page I update maybe twice a year. It makes a lot of sense to simply code my resume by hand, using only HTML, and let people download it as is.

JSP is really the only good technology to do this in the standard set of Java/J2EE tools. Now that is an over-simplified statement, but it is true. There are several other technologies such as Servlets and JDBC that are almost always used with JSP to get the job done, but if you try to make dynamic web pages without JSP it takes a lot more time and effort.

In summary, I'm saying if you want to make dynamic HTML, XHTML, or text and send it over the World Wide Web, JSP is what you should use. That is why it is important. If you don't want to believe me I'll give a link at the end that does a proper job of arguing this point against the millions of common counter-points developers have. Now to move on....

JSP is The standard

A key thing to understand is that JSP is a standard. It has been around for good deal of time, lots of companies have dumped lots of money in to it, several other technologies are based on JSP, and there are tried and proved successful uses of the technology. In short, I'm saying any other Java technology that is trying to compete with JSP and isn't part of the standard J2EE API is more or less worthless. I don't care if you want to argue that something is more elegant, or that you can show me an open-source project that has a few top quality hacks working on it. None of that matters. JSP does get the job done, JSP can do a great job, and you can make a good living off of programming JSP/J2EE knowing Sun, IBM, Oracle, and a slew of other companies will keep the money flowing. Other projects like WebMacro/Velocity have lost. They are bitter, and they should be. Some really neat ideas and some great code might have been produced, but they certainly won't get much credit when the next version of JSP incorporates those features.

In summary, I'm saying JSP is relevant because it is a standard. As an average developer you should forget anything you hear from other non-standard Java technologies. Sad, but true, especially if you only care about making a living as a Java web programmer.

JSP is easy to use in amazing ways

JSP can be used well, and it can do amazing things. I've spent several years of my life figuring this out. I've tried the alternatives. I know about the other open-source projects. I've helped the JSP expert group. And I've spent a year of my life writing a book about this very topic. If you want to build a good web application that is fast, efficient, and easy to maintain, JSP can do it. If you don't believe me the best I can do is tell you to do some reading. Check out Sun's website, read java.net, read JSP Insider, or simply read my book. And you are right if you are thinking I'm just pushing what I like. I like JSP, but I say that because I've tried just about every other solution to building web applications. I've dealt with the poorly funded open-source solutions, the hyped commercial solutions, and even some home-brewed attempts to improve the state of things. But I think JSP is the best.

In summary, I'm saying that I honestly think JSP is a great technology, and I think I have the experience to fairly say so. Especially considering JSP 2.0, there are far too many helpful things that you can do easily with JSP. If you understand the technology, you will get the job done and you can certainly get the job done well.

And that is why JSP is still a relevant technology. I really wish I had the time to type out each and every bit of knowledge I have on the subject, in particular some of the really slick coding tricks that would completely solve your hard to maintain JSP problems, or reasons you shouldn't bother with stuff like WebMacro/Velocity, but I seriously just got done doing this in a JSP 2.0 and Servlet 2.4 book that went on sale a few days ago. Go buy it if you want an instant fix, or try to ask some specific questions on my points above if you want a slower, free-loader fix. I'll try to answer as many questions as I can as long as you keep sending them to me -- feel free to make them specific so I can try to show some code or talk about JSP 2.0 features.

Jayson Falkner - jayson@jspinsider.com

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.

This work is licensed under a Creative Commons License.