Skip to main content

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

Posted by jfalkner on October 23, 2003 at 3:46 PM PDT


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.:

&lt;html&gt;
Hello ${name}, welcome to the website.
&lt;/html&gt;

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

Related Topics >>