a decade of "keep the code out of the jsp"

[Jeanne Boyarsky]

I noticed in one of Bear's posts that 2002 was the year that we should stop putting code in the JSP. I started doing it a few years later, but I've been there a long time now.) What do you think are the reasons people keep writing code in the JSP?

My thoughts:

Intro to JSP books show it that way

Copy/paste existing code

School classes teaching it that way

[Ulf Dittmer]

It's easy to get started with. JSPs generally get reloaded/recompiled automatically, whereas Java code -either in backing beans or in servlets- requires a restart of the web app.

[Anayonkar Shivalkar]

Ulf Dittmer wrote:It's easy to get started with. JSPs generally get reloaded/recompiled automatically, whereas Java code -either in backing beans or in servlets- requires a restart of the web app.

But in the days of 'hot-redeploy', I don't think that is a problem - I'm not supporting that we should write Java stuff in JSP of course, but at least above doesn't look very strong reason.

One reason I read about was - JSPs are supposed to handle by graphic designers, and hence they should be able to modify those even if they don't know Java - I guess that is how custom tags were born.

Just my 2 cents.

[Frank Silbermann]

I think the rule should be generalized to Don't Use JSPs.

[Bear Bibeault]

Er, yeah, because building up complex HTML, CSS, and JavaScript markup in strings inside servlets is so much more productive!

[Tim Moores]

Anayonkar Shivalkar wrote:But in the days of 'hot-redeploy', I don't think that is a problem

I think it is. Take a look around these forums - most of the folks who use scriptlets have trouble getting a web app to run in a servlet container running inside an IDE; much less in a servlet container running outside of an IDE. Do you think they've mastered hot redeploy?

[Seetharaman Venkatasamy]

it takes time.... most projects are in maintenance/enhancement(at least in india). people tends to write(most of them write) scriptlet even in development(from scratch) project.
1.to use JSTL etc.., jar needs to put explicitly.
some new developer may afraid to deploy it in lib.

2.some of the developer dont want to learn new things...

[Bear Bibeault]

Tim Moores wrote:

Anayonkar Shivalkar wrote:But in the days of 'hot-redeploy', I don't think that is a problem

I think it is. Take a look around these forums - most of the folks who use scriptlets have trouble getting a web app to run in a servlet container running inside an IDE; much less in a servlet container running outside of an IDE. Do you think they've mastered hot redeploy?

Running a web app outside of an IDE is considerably easier than running one inside one, in my experience.

[Bear Bibeault]

Seetharaman Venkatasamy wrote:it takes time.... most projects are in maintenance/enhancement(at least in india). people tends to write(most of them write) scriptlet even in development(from scratch) project.
1.to use JSTL etc.., jar needs to put explicitly.
some new developer may afraid to deploy it in lib.

2.some of the developer dont want to learn new things...

I'd say 99.5% the second one.

Most developers know how to copy a file into a folder.

[Jeanne Boyarsky]

Seetharaman Venkatasamy wrote:2.some of the developer dont want to learn new things...

Not a good job skill. And more importantly: if we didn't teach them wrong in the first place, it wouldn't be new!

[Frank Silbermann]

Bear Bibeault wrote:Er, yeah, because building up complex HTML, CSS, and JavaScript markup in strings inside servlets is so much more productive!

That's hardly the only alternative.

[Bill Clar]

As a JSP coder the only excuse I can give, for myself, is laziness. Something which I hope to rectify.

Like Bear says, it's easier to copy a file into a folder.

Tim Moores wrote:

Anayonkar Shivalkar wrote:But in the days of 'hot-redeploy', I don't think that is a problem

I think it is. Take a look around these forums - most of the folks who use scriptlets have trouble getting a web app to run in a servlet container running inside an IDE; much less in a servlet container running outside of an IDE. Do you think they've mastered hot redeploy?

'Tis true. I'm responsible for deployment and I know naught about 'hot redeploys'.

[Paul Clapham]

Frank Silbermann wrote:

Bear Bibeault wrote:Er, yeah, because building up complex HTML, CSS, and JavaScript markup in strings inside servlets is so much more productive!

That's hardly the only alternative.

Indeed. If you really want some fun, try writing an XSL transformation to produce a complex HTML document including Javascript.

[Bear Bibeault]

He may also be referring to alternate templating engines such as FreeMarker that were created back in JSP1 days when JSP sucked. Because JSP2 is pure templates, there really isn't any advantage to using those any more -- it's just the same as JSP2 but with a proprietary syntax.

Or he might be referring to frameworks like Play that aren't based on JEE at all, and use a proprietary templating technology (using Groovy or Scala).

But, the vast majority of people writing Java-based web apps use JEE and JSP and should be using JSP2 and not JSP1. It's been freaking 10 years!

[Frank Silbermann]

Bear Bibeault wrote:He may also be referring to alternate templating engines such as FreeMarker that were created back in JSP1 days when JSP sucked. Because JSP2 is pure templates, there really isn't any advantage to using those any more -- it's just the same as JSP2 but with a proprietary syntax.

Or he might be referring to frameworks like Play that aren't based on JEE at all, and use a proprietary templating technology (using Groovy or Scala).

But, the vast majority of people writing Java-based web apps use JEE and JSP and should be using JSP2 and not JSP1. It's been freaking 10 years!

There is also Velocity which, though low level, can be more easily built upon.

What annoys me most about the JSP approach is the difficulty obeying the SLAP -- the Single Level of Abstraction Principle (http://www.ibm.com/developerworks/java/library/j-eaed4/index.html).

I don't like the idea of having code that expresses decisions motivated by application logic (i.e., what information you wish to present to the user and what information you want the user to provide in return) interspersed with code pertaining to details of the HTTP protocol and browser technologies. I find that using JSPs (and, to be honest, most approaches to web development), it requires superhuman effort to keep those abstraction levels separate. With most JSP-based applications that I've seen, HTML is written not to reflect generic application-wide layout decisions but rather is custom-written for individual user tasks.

[Bear Bibeault]

Many (most) people do use JSP badly, but I'm not sure that's the fault of JSP itself.

And anyone who doesn't write semantic HTML, well, just shouldn't be working on the web.

But that's why I write books... trying my best to make it all better!

[Rudy Gireyev]

Jeanne Boyarsky wrote: What do you think are the reasons people keep writing code in the JSP?

Hi Jeanne
Maybe it will help if you clarify what kind of code you had in mind. Like business logic, or persistence layer interface code or presentation layer code.

I personally prefer using JSP code for presentation layer because
1. It's standard JAVA, which means it's powerful, easily understood and flexible.
2. TLD libraries that use their own tags tend to be many in number, have limited functionality and sometimes contain bugs. On top of that they use auto generated code, something I try to avoid in general.

Rudy

[Ant Jackson]

Rudy Gireyev wrote:
I personally prefer using JSP code for presentation layer because

Agreed. Also TLD libraries are more difficult to debug.

[Timothy Stone]

We shut it down at my employer. Hard stop. Not allowed and we have full lifecycle development in the IDE too. It really is simple; of course we couple a number technologies and processes to do it, Maven being the biggest piece to deliver full lifecycle DEV in the IDE.

We started with the following directive in the web.xml

<jsp-config> <jsp-property-group> <url-pattern>*.jsp</url-pattern> <scripting-invalid>true</scripting-invalid> </jsp-property-group> </jsp-config>

Anyone trying to remove it is labeled (yes, we are quite the bully team and feeling often get hurt). In enforces better design in the Controller and Model layer as well.

[Bear Bibeault]

Ant Jackson wrote:

Rudy Gireyev wrote:
I personally prefer using JSP code for presentation layer because

Agreed. Also TLD libraries are more difficult to debug.

Arguments such as "it's easier" are invalid. It's much important to do thing correctly, than to do them easily. And tags really aren't all that hard to debug either, if they're used.

[Paul Anilprem]

Bear Bibeault wrote:

Ant Jackson wrote:

Rudy Gireyev wrote:
I personally prefer using JSP code for presentation layer because

Agreed. Also TLD libraries are more difficult to debug.

Arguments such as "it's easier" are invalid. It's much important to do thing correctly, than to do them easily. And tags really aren't all that hard to debug either, if they're used.

For what it's worth, IMHO, custom tags maintenance is a nightmare. I would never use them unless they are third party and are used for basic functionality, the kind provided by struts. The latest specification has made them a little easier though.

[Jeanne Boyarsky]

Rudy: I meant any Java code. I didn't have any specific code in mind.

[Bear Bibeault]

Hmm, not getting the problem with custom tags. But on the other hand, I only use them sparingly. I dislike replacing perfectly good HTML markup with custom tags "just because". I like to keep the pages as simple and lean as possible. That's what really helps with maintenance.

[Jeanne Boyarsky]

I wind up using tag files and not tags. Tag files still use JSP syntax so can have lots of display. And can be reused without having something that looks like HTML in a servlet.

[Bear Bibeault]

Likewise. For the tags that I do implement, most are tag files.

[Rudy Gireyev]

Jeanne Boyarsky wrote:Rudy: I meant any Java code. I didn't have any specific code in mind.

Yup. I got that. I always read your posts very carefully as they tend to be quite insightful and always helpful. I just wanted to make the distinction between the different types of code that could go into a JSP. And while I agree that all other types of Java code should stay away from the JSP, I feel that the code that is presentation layer specific is perfectly at home within the JSP. Not only that, it is actually preferable to any other alternative that I have employed so far.

Bear Bibeault wrote:Arguments such as "it's easier" are invalid.

Invalid on what basis? Spaghetti code is more difficult to read and maintain than code that is clear and concise. Should we stop writing code that is clear and concise and start writing spaghetti code because it is more difficult?

Bear Bibeault wrote:It's much important to do thing correctly, than to do them easily.

Correctly, as defined by whom? Winds of fashion have blown over this profession for as long as I've been in it. And as such they don't always blow in the right direction. Please remember EJBs were once "The" technology to do things "correctly". I know you are old enough to remember.

[Bear Bibeault]

Bear Bibeault wrote:Arguments such as "it's easier" are invalid.

Invalid on what basis? Spaghetti code is more difficult to read and maintain than code that is clear and concise. Should we stop writing code that is clear and concise and start writing spaghetti code because it is more difficult?

Twisting words wins no points in a debate. In no way can "doing something sloppy because it's easy is bad" be validly construed as "doing things the difficult way is good".

Bear Bibeault wrote:It's much important to do thing correctly, than to do them easily.

Correctly, as defined by whom?

Experienced and seasoned developers with the scars to prove that doing it "wrong" hurts.

Please remember EJBs were once "The" technology to do things "correctly". I know you are old enough to remember.

I never had any use for EJBs. It's a straw man argument in any case. Comparing a technology to best practices is apples and oranges. And I'll be the first to say that just because there's a "standard" for something doesn't make it "correct". Just look at the abomination that is JSF.

[Jeanne Boyarsky]

And just because something was once considered a good idea, doesn't mean it still is. Same applies to EJB 1.0 and a 100 lines of code in a JSP. Practices improve over time.

[Ant Jackson]

Easier works for me every time :-)

[E Armitage]

Frank Silbermann wrote:I think the rule should be generalized to Don't Use JSPs.

Agreed. JSF with Facelets is a much better option. The EE spec has already moved on from JSP.

[Frank Silbermann]

Frank Silbermann wrote:
What annoys me most about the JSP approach is the difficulty obeying the SLAP -- the Single Level of Abstraction Principle (http://www.ibm.com/developerworks/java/library/j-eaed4/index.html).
... With most JSP-based applications that I've seen, HTML is written not to reflect generic application-wide layout decisions but rather is custom-written for individual user tasks.

Bear Bibeault wrote:Many (most) people do use JSP badly, but I'm not sure that's the fault of JSP itself.

Aside from SLAP, there's the Don't Repeat Yourself principle (DRY), which is violated when the code for moving HTTP request parameters into a business object is rewritten on behalf of each page touching that business object. (Unfortunately this violation seems to be the basic way of working in any framework based on the Struts/JSP approach.)

E Armitage wrote:
Agreed. JSF with Facelets is a much better option. The EE spec has already moved on from JSP.

When Facelets was added to JSF, we finally had a respectable Java standard for web development. That said, I don't like the way JSF is taught. You can read five books on JSF and never learn how to instantiate and configure components in code (rather than in XHTML), which is essential for many re-use scenarios.

For example, suppose there is a database that you want unsophisticated users to mine for information. They don't know SQL, so you want to give them a few dozen queries that they can parameterize and enter. Depending on the query and its parameters, you will get a different set of columns. You certainly don't want to have to lay out the table in XHTML for every permutation -- you'd rather have generate the table configuration from a POJO that is created from the database result set via code. (In fact, for quick and dirty internal applications there should be a modifiable default way of displaying the results of a generic database query without having to _repeat_ in XHTML the table schema information that was already coded elsewhere, and which is already present in the ResultSet -- or at least a reasonably easy way to write one.)

Obeying the DRY principle often requires sophisticated use of OO techniques; any information that you have to encode in a notation that is not object oriented will be difficult to re-use. Yeah, I know you can sometimes hack a solution using Velocity, or XSL, but to me that's like an IBM Basic Assembly Language programmer telling me that I don't need that new-fangled COBOL with its procedure subprograms and automated parameter passing because I can rely on macros for code reuse.

[E Armitage]

Frank Silbermann wrote:..

For example, suppose there is a database that you want unsophisticated users to mine for information. They don't know SQL, so you want to give them a few dozen queries that they can parameterize and enter. Depending on the query and its parameters, you will get a different set of columns. You certainly don't want to have to lay out the table in XHTML for every permutation -- you'd rather have generate the table configuration from a POJO that is created from the database result set via code. (In fact, for quick and dirty internal applications there should be a modifiable default way of displaying the results of a generic database query without having to _repeat_ in XHTML the table schema information that was already coded elsewhere, and which is already present in the ResultSet -- or at least a reasonably easy way to write one.)

..

This is a painful thorny issue for me. A big advantage of component based frameworks is that there should be good tooling support (drag and drop and on the fly code generation) since the components are well (and pre) defined. Yet dynamic table generation still remains a problem. Even in EE6 with facelets it's difficult to achieve without you running into runtime vs page compile time tag problems. Especially if you use the new (convenient) ViewScope for the backing beans. I recently had to resort to a mixture of JSTL and facelet tags to get it to work when I'm really supposed to be moving away from JSTL tags with facelets.

[Frank Silbermann]

E Armitage wrote:

Frank Silbermann wrote:..

For example, suppose there is a database that you want unsophisticated users to mine for information. They don't know SQL, so you want to give them a few dozen queries that they can parameterize and enter. Depending on the query and its parameters, you will get a different set of columns. You certainly don't want to have to lay out the table in XHTML for every permutation -- you'd rather have generate the table configuration from a POJO that is created from the database result set via code. (In fact, for quick and dirty internal applications there should be a modifiable default way of displaying the results of a generic database query without having to _repeat_ in XHTML the table schema information that was already coded elsewhere, and which is already present in the ResultSet -- or at least a reasonably easy way to write one.)

..

This is a painful thorny issue for me. A big advantage of component based frameworks is that there should be good tooling support (drag and drop and on the fly code generation) since the components are well (and pre) defined. Yet dynamic table generation still remains a problem. Even in EE6 with facelets it's difficult to achieve without you running into runtime vs page compile time tag problems. Especially if you use the new (convenient) ViewScope for the backing beans. I recently had to resort to a mixture of JSTL and facelet tags to get it to work when I'm really supposed to be moving away from JSTL tags with facelets.

That is very disconcerting. I built a system such as I described quite easily using Wicket (to be fair, my table panes were display-only), but the Enterprise Architecture group insists that it be rewritten using one of their technology standards. It was hoping that JSF/Facelets could save the day, because using lower-level frameworks would basically mean re-implementing something like Wicket from scratch.

Do the problems you describe occur even when the set of columns is fixed for a page but various from one page to another?

I can imagine that special methods must be used if/when the set of columns changes on the same page during post-back. Is there no facility to replace a JSF component on a page in response to an event? (That, too, was rather easy in Wicket.)

[Bear Bibeault]

The current trend in web applications is moving away from complicated server-side apparatus and towards more client-side frameworks and instrumentation, with the server frequently relegated to providing a simple RESTful API consumed by the client. This ultimate Separation of Concerns bodes well for server-side scalability, but of course, presents its own set of unique challenges that the industry is currently addressing.

Over-complicated server-side machinery like JSF (and to me, all but the simplest JSPs), especially those that interject themselves heavily into the presentation UI, are beginning to feel very dinosaur-ish.

It's a wonderful time to be working the arena of web apps -- so much new stuff going on, and my reading list is sky high!

P.S. Frank, this trend directly addresses the concern you voiced. Dealing with heavily tagged JSP/JSF/whatever pages can be a nightmare from client-side code. With no (or minimal) server-side intrusion into the HTML, those concerns are mitigated or dissappear.

[Bear Bibeault]

A little bit more on this. This push to separating client UI from server machinery is fueled by a number of factors:

(As mentioned in the previous post) making the client-side instrumentation play nice with the pages.

The meteoric rise in the importance of mobile platforms.

The growing number of web-enabled embedded-system devices that have relatively weak processing power. (Think set-top boxes, DVRs, blu-ray players, game consoles, even refrigerators!) In this scenario, the client systems are frequently much more powerful than the servers!

A continuing tend towards good old Separation of Concerns.

And more...

This is not good news for web developers who are heavy on Java (or ColdFusion, or whatever on the server) and light on HTML/CSS/JavaScript.

I know that here in Austin, the biggest demand (and biggest paychecks) are for seasoned and savvy client-side developers. This is a trend I see spreading and becoming industry-wide (if it hasn't already).

[E Armitage]

Especially with HTML 5 bringing scoped state and even persistence there is definitely going to be a lot of view support logic moving to the client side.
This is why it's even more important to use these frameworks correctly if at all these days.
Thankfully CDI now makes it possible to write controllers and view helpers that are not framework specific.

[Frank Silbermann]

Bear Bibeault wrote:The current trend in web applications is moving away from complicated server-side apparatus and towards more client-side frameworks and instrumentation, with the server frequently relegated to providing a simple RESTful API consumed by the client. This ultimate Separation of Concerns bodes well for server-side scalability, but of course, presents its own set of unique challenges that the industry is currently addressing.

Over-complicated server-side machinery like JSF (and to me, all but the simplest JSPs), especially those that interject themselves heavily into the presentation UI, are beginning to feel very dinosaur-ish.

It's a wonderful time to be working the arena of web apps -- so much new stuff going on, and my reading list is sky high!

P.S. Frank, this trend directly addresses the concern you voiced. Dealing with heavily tagged JSP/JSF/whatever pages can be a nightmare from client-side code. With no (or minimal) server-side intrusion into the HTML, those concerns are mitigated or dissappear.

Well, that would move us closer to the Applet idea (though not the Applet implementation).

Of course, I still don't see why it would be more desirable to code in HTML/CSS/JavaScript rather than in, say, a language which compiled to the "machine" implemented by the browser (the GWT idea).

[Bear Bibeault]

Frank Silbermann wrote:Well, that would move us closer to the Applet idea (though not the Applet implementation).

Not at all. Since the advent of Ajax, more and more functionality has been moving to the client. No applets, no plugins, no non-native elements. This is simply a continuation of that trend.

Of course, I still don't see why it would be more desirable to code in HTML/CSS/JavaScript rather than in, say, a language which compiled to the "machine" implemented by the browser (the GWT idea).

You are in the minority on that front. Most web devs would rather deal with the client code directly than let something generate it for them. GWT is a tool that certainly has its place, but it'll never become wide-spread.

[Frank Silbermann]

Bear Bibeault wrote:

Frank Silbermann wrote:Well, that would move us closer to the Applet idea (though not the Applet implementation).

Not at all. Since the advent of Ajax, more and more functionality has been moving to the client. No applets, no plugins, no non-native elements. This is simply a continuation of that trend.

Duh, I didn't say we're moving closer to Applets; I said closer to the Applet idea. (i.e., to execute code in the browser). I guess you didn't read the part where I wrote "though not the Applet implementation".

Bear Bibeault wrote:

Of course, I still don't see why it would be more desirable to code in HTML/CSS/JavaScript rather than in, say, a language which compiled to the "machine" implemented by the browser (the GWT idea).

You are in the minority on that front. Most web devs would rather deal with the client code directly than let something generate it for them. GWT is a tool that certainly has its place, but it'll never become wide-spread.

If it is indeed more desirable to code in HTML/CSS/JavaScript, perhaps it should be explained why for twenty years no one felt the need to create a HTML/CSS/Javascript environment for building stand-alone PC applications.

I know that writing HTML/CSS/JavaScript is what most webdevs do, but I've always presumed this was either:

for the same reason that until C became available most system programmers wrote in assembler language -- because higher-level languages didn't provide all the features they needed, or

for the same reason mainframers still prefer to program in COBOL -- because that is what is familiar to them

.

[Bear Bibeault]

Frank Silbermann wrote:Duh, I didn't say we're moving closer to Applets; I said closer to the Applet idea. (i.e., to execute code in the browser). I guess you didn't read the part where I wrote "though not the Applet implementation".

I don't think that there are many who would equate the idea of Applets with client-side coding in JavaScript, except at the stratospheric level of "code that runs on the client".

If it is indeed more desirable to code in HTML/CSS/JavaScript, perhaps it should be explained why for twenty years no one felt the need to create a HTML/CSS/Javascript environment for building stand-alone PC applications.

Desktop apps and web apps are very different beasts. GWT tries to bring the desktop programming metaphor to the web, and it's perfectly appropriate for some uses, but that metaphor just isn't going to go much of anywhere in the grand scheme of things -- it's just not very suitable to the purpose, and not even in the mindshare of up-and-coming web devs. They didn't "grow up" writing Windows or X desktop apps like we did, and telling them they need to write the structure of UI in a programmatic manner in Java rather than in a declarative manner is likely to get you some odd looks.

I know that writing HTML/CSS/JavaScript is what most webdevs do, but I've always presumed this was either:

Not in my experience. The best web devs wield the holy trinity of the web: HTML, CSS and JavaScript, like sabre-sharp weapons. It's not because they "don't know any better", it's because they do know how to use these tools effectively. And anything that tries to get in the way is a bother rather than a help.

Like many from the Java world, you seem to be looking askance at HTML and CSS, and even JavaScript, as something foreign and dangerous. Something to be avoided or worked around. A poisonous bug that needs to be squashed. The broad and influential web dev community is not in that camp.