JSP still relevant

[SL Da]

I have learnt a bit of JSP.

Before I delve deeper, I just wonder whether JSP is relevant, or will
still be relevant.

I hope not to spend so much time, then suddenly it is obsolete; may be
HTML 5 ?

Thanks.

 

[Tim Slattery]

I have learnt a bit of JSP.

Before I delve deeper, I just wonder whether JSP is relevant, or will
still be relevant.

Absolutely. Java Server Pages is kind of servlets turned inside out. A
servlet is a Java program that outputs HTML. A JSP page is mostly
HTML, with Java code interspersed. I use the Struts framework which
uses both: servlets to do the work in the background, JSP pages to
control the look of the resulting pages, and integrate the data the
servlets have generated.

I hope not to spend so much time, then suddenly it is obsolete; may be
HTML 5 ?

Different issues. JSP is server-side technology, HTML is client-side.
You'll need to know both.

 

[Tim Slattery]

It is a best practice to have no raw Java scriptlet whatsoever in a JSP.

You use tags instead, sure. Given the JSTL and the many other taglibs
available, you don't need to use actual Java code hardly at all.

More correctly, to coordinate the view and the model logic.
Agreed.

And POJOs or JavaBeans to execute the model logic.

Yes.

 

[Arne Vajhøj]

I have learnt a bit of JSP.

Before I delve deeper, I just wonder whether JSP is relevant, or will
still be relevant.

Absolutely JSP is still the most used view technology in JSF.

I hope not to spend so much time, then suddenly it is obsolete; may be
HTML 5 ?

JSP can output HTML 5.

Arne

 

[Roedy Green]

I have learnt a bit of JSP.

Before I delve deeper, I just wonder whether JSP is relevant, or will
still be relevant.

I hope not to spend so much time, then suddenly it is obsolete; may be
HTML 5 ?

JSP is a sort of a macro ability to generate HTML on the fly at the
server. HTML 5 is like HTML 4 markup but with extensions. See
http://mindprod.com/jgloss/html.html#HTML5 for details.

You would use JSP to generate HTML 5 the same way you would get it to
generate HTML 4. Presumably there will be JSP implementations that
use the features of HTML 5 for the standard tags in addition to your
use in your own Servlets.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"Deer hunting would be fine sport, if only the deer had guns."
~ William S. Gilbert of Gilbert and Sullivan

 

[Tom Anderson]

You use tags instead, sure. Given the JSTL and the many other taglibs
available, you don't need to use actual Java code hardly at all.

I know this is conventional 'best practice' advice, but i think it's
actually really bad advice.

The problem is that just banning scriptlets doesn't ban code from JSPs, it
just means people write the code using tags instead - and tags are a
really, really bad programming language, like something from the 50s with
the added bonus of a massively verbose syntax. So rather than:

<%
boolean onFirstPage = pageIndex == 0;
if (onFirstPage) out.println("You are on page " + (pageIndex + 1));
else out.println("You are on the first page");
%>

(note that i want to leave onFirstPage as a variable, so i can use it
again later)

You have some monstrosity like:

<c:set var="onFirstPage" value="${pageIndex == 0}"/>
<c:choose>
<c:when test="${onFirstPage}">
You are on page <cut value="${pageIndex + 1}"/>
</c:when>
<ctherwise>
You are on the first page
</ctherwise>
</c:choose>

You wouldn't seriously claim that was better, would you? And this is just
a mild example!

I work with a big hairy CMS webapp whose JSPs are almost entirely made of
convoluted logic expressed using tags, far worse than the above. If it was
done with scriptlets, it would be more compact, more readable, much, much
more debuggable, and more maintanable. Oh, and it would be faster.

The problem is not java in JSPs, it's logic in JSPs. If you factored the
above code out into a custom tag, or a bean or something, where it could
be written in java and then cleanly integrated with JSP, i think that
would be ideal. But as long as the advice is "don't use scriptlets",
rather than "don't put logic in JSPs", that's not what people are going to
do.

tom

 

[Arved Sandstrom]

I know this is conventional 'best practice' advice, but i think it's
actually really bad advice.

The problem is that just banning scriptlets doesn't ban code from JSPs,
it just means people write the code using tags instead - and tags are a
really, really bad programming language, like something from the 50s
with the added bonus of a massively verbose syntax. So rather than:

[ SNIP ]

The problem is not java in JSPs, it's logic in JSPs. If you factored the
above code out into a custom tag, or a bean or something, where it could
be written in java and then cleanly integrated with JSP, i think that
would be ideal. But as long as the advice is "don't use scriptlets",
rather than "don't put logic in JSPs", that's not what people are going
to do.

tom

Nicely put - I agree 100%.

Although I deal with JSF and Facelets those pages are susceptible to the
same problems. I keep my <c:if>...</c:if> logic confined to deciding
what sections of XHTML to show, based on role, that kind of thing.

AHS

 

[David]

<c:set var="onFirstPage" value="${pageIndex == 0}"/>
<c:choose>
  <c:when test="${onFirstPage}">
   You are on page <cut value="${pageIndex + 1}"/>
  </c:when>
  <ctherwise>
   You are on the first page
  </ctherwise>
</c:choose>

I absolutely hate the syntax they used for this- choose, when,
otherwise! In a vacuum it's fine, but the terms used are so very
unrelated to anything else you use in Java. Best I can tell, the only
reason they used that syntax was to show they were breaking away!

why not
<c:ifelseif>
<c:if ...>show stuff</c:if>
<c:if ...>show something else</c:if>
<c:else ...>show the default</c:else>
</c:ifelseif>

 

[Tom Anderson]

I absolutely hate the syntax they used for this- choose, when,
otherwise! In a vacuum it's fine, but the terms used are so very
unrelated to anything else you use in Java. Best I can tell, the only
reason they used that syntax was to show they were breaking away!

why not
<c:ifelseif>
<c:if ...>show stuff</c:if>
<c:if ...>show something else</c:if>
<c:else ...>show the default</c:else>
</c:ifelseif>

The 'if' task in ant (actually ant-contrib - and don't get me started on
how much i hate ant) looks like:

<if>
<equals arg1="${pageIndex}" arg2="0"/>
<then>
whatever
</then>
<else>
whatever else
</else>
</if>

Which is weird in its own way (else goes inside if?), but i think is
better than what JSTL does.

tom

 

[Lew]

Nicely put - I agree 100%.

Although I deal with JSF and Facelets those pages are susceptible to the
same problems. I keep my <c:if>...</c:if> logic confined to deciding
what sections of XHTML to show, based on role, that kind of thing.

Actually, I do see that advice phrased as "don't put business logic in JSPs,
only view logic" from a lot of sources. That is, of course, the intent behind
the less rigorously-phrased form.

 

[Arved Sandstrom]

Tom Anderson wrote:
[ SNIP ]

The 'if' task in ant (actually ant-contrib - and don't get me started on
how much i hate ant) looks like:

[ SNIP ]

I'm a shit disturber...I don't mind getting you started on how much you
hate Ant.

I'm no fan of it either. For starters I don't like the fact that it's in
XML (a serious Ant build file is bloated and unnecessarily difficult to
understand). And I don't find it nearly as powerful or flexible as
make-type build tools, not without major extra effort.

Unfortunately I have to use Ant on the job - not many of the junior or
intermediate Java developers I work with have ever seen any other build
system.

AHS

 

[Tom Anderson]

Actually, I do see that advice phrased as "don't put business logic in
JSPs, only view logic" from a lot of sources. That is, of course, the
intent behind the less rigorously-phrased form.

But even that is wrong (IMNERHO) - in the example i give, and the
nightmare system i work with, the logic in question is all view logic.
Unless the promulgators of this advice think that the choice of which
message to display in that example is business logic? The writing of view
logic in JSP is something that i don't see warnings against - indeed, i
see a whole industry and community that's built around the idea that
programming with tags is a legitimate thing to do.

tom

 

[Tom Anderson]

Tom Anderson wrote:
[ SNIP ]

The 'if' task in ant (actually ant-contrib - and don't get me started on
how much i hate ant) looks like:

[ SNIP ]

I'm a shit disturber...I don't mind getting you started on how much you
hate Ant.

I'm no fan of it either.

Right, time for a hate-on-ant thread!

For starters I don't like the fact that it's in XML (a serious Ant build
file is bloated and unnecessarily difficult to understand).

Yup. It's a classic example of XML for its own sake - ant gains nothing by
being in XML. It's not like people use CSS to display it, or XSLT to
transform it. It just adds verbosity and awkwardness.

And I don't find it nearly as powerful or flexible as make-type build
tools, not without major extra effort.

I have no experience with make, so i can't comment. I find ant to be of a
similar power to shell script, but taking four times as long to say
anything, and that's what makes it agonising.

Unfortunately I have to use Ant on the job - not many of the junior or
intermediate Java developers I work with have ever seen any other build
system.

We're in the opposite situation: we had a build system made entirely out
of shell scripts. Yes, it was pretty hairy, but it worked, and as time
went by, we refactored and bulletproofed and added sanity checks and so
on, and it was actually pretty decent - although i wouldn't enjoy being
someone unfamiliar with it who had to do anything but run it. Recently, we
started work on a new project which had different needs for its build, and
where we'd have to deliver the build system to the customer, who was using
windows on their development boxes. For that project, we went with ant,
because shell scripts are neither portable nor widely understood and
accepted as a serious build tool. We've since started retrofitting that
new build system to our previous project, and i've had a chance to compare
the two languages side by side.

Someone, i think on kuro5hin of all places, said that the problem with ant
is that it was invented by someone who thought make was too complex, but
later discovered that there was a reason for that complexity. In other
words, it consists of some basic ideas that are really too simple to do
the job, with a load of extra complexity shoehorned in on top.

I am increasingly of the opinion that build scripts are programs, and
should be written in a programming language. They're complex enough to
both use the power that real programming languages provide (simple things
like loops, arrays, if-then-else) and to benefit from the rigour that
comes with it (subroutines with named parameters and return values,
lexical scoping, typed values, if not typed variables). Of course, a
general-purpose language isn't ideal for build scripts, because there are
all sorts of things you frequently need to do that are cumbersome to
express (my canonical example is "do this task, but only if it hasn't
already been done" - trivial in make, but taking a few lines in a
general-purpose language, or in ant for that matter).

That's the core of my problem with ant, really. To do even the simplest
thing seems to take lines and lines of horrific XML.

My plan is for a thin layer on top of python, with a conceptual approach
more like ant than make, ie tasks not targets. Python is concise and
readable (and writable), on a similar order to make, and is easily
extended in certain directions. Tasks would just be functions with a
special decorator; further decorators could be use to express particularly
buildy ideas (note - python's decorators look like java's annotations, but
are more like lisp's macros; they can actually change the definition of
the thing they decorate). And there would be a library of functions and
classes based on ant's building blocks, like filesets and so on. I'm
thinking it would look like:

@onlyonce
@task
def installRunConf():
copy("/run-resources/run_myapp.conf", JBOSS_HOME + "/bin")

@ifnewer("/sql/oracle/create_tables.sql", "/sql/mssql/create_tables.sql")
@task
def regenerateMSSQL():
run("/bin/ora2ms.sh", "/sql/mssql", glob("/sql/oracle/*.sql"))

@public
@task
def setupConfigurationFiles():
"Sets up the run.conf and SQL files for MyApp."
installRunConf()
regenerateMSSQL()

There'd then be a fairly simple driver tool which would load and run build
scripts (doing some necessary trickery with imports), and also let you do
things like list the tasks in them (with descriptions), run a script with
some level of tracing, and whatever. Like:

pant --trace setupmyapp.pant deployApp instanceName=myapp-demo-1 dbType=oracle dbName=DEMO1

Bruce Eckels previously and independently had a similar idea:

http://www.artima.com/weblogs/viewpost.jsp?thread=241209

Although his is much more make-ish than mine.

tom

 

[John B. Matthews]

I am increasingly of the opinion that build scripts are programs, and
should be written in a programming language.

[...]

Others agree: this project management scripting language looks
(not surprisingly) like the language itself:

<http://gcc.gnu.org/onlinedocs/gcc-4.4.0/gnat_ugn_unw/GNAT-Project-Manager.html#GNAT-Project-Manager>

 

[Lew]

But even that is wrong (IMNERHO) - in the example i [sic] give, and the
nightmare system i [sic] work with, the logic in question is all view logic.
Unless the promulgators of this advice think that the choice of which
message to display in that example is business logic? The writing of

It probably is, in that case.

view logic in JSP is something that i [sic] don't see warnings against -

But the warning against undue complexity in programming generally abounds.

indeed, i [sic] see a whole industry and community that's built around the
idea that programming with tags is a legitimate thing to do.

It is.

But as with all programmming, overly-complex and hard-to-follow code is bad.
It doesn't matter whether you're doing JSPs, POJOs or whatnot, the problem is
not with the tags but with the coding style.

 

[markspace]

I work with a big hairy CMS webapp whose JSPs are almost entirely made
of convoluted logic expressed using tags, far worse than the above. If

Just curious: which CMS is that?

 

[Mike Schilling]

Tom Anderson wrote:
[ SNIP ]

The 'if' task in ant (actually ant-contrib - and don't get me
started on how much i hate ant) looks like:

[ SNIP ]

I'm a shit disturber...I don't mind getting you started on how much
you hate Ant.

I'm no fan of it either.

Right, time for a hate-on-ant thread!

It's a build system that can't express "A depends on B" in a
conmsistent fashion. Enough said.

 

[Arved Sandstrom]

But even that is wrong (IMNERHO) - in the example i give, and the
nightmare system i work with, the logic in question is all view logic.
Unless the promulgators of this advice think that the choice of which
message to display in that example is business logic? The writing of
view logic in JSP is something that i don't see warnings against -
indeed, i see a whole industry and community that's built around the
idea that programming with tags is a legitimate thing to do.

Identifying something as presentation logic rather than business logic
is sometimes hard to do. Let me elaborate on my above example - let's
say that my application page navigation is assisted by the provision of
a row of category tabs, each displaying a row of links underneath the
tab row when the specific category tab is clicked. Let's also say that
each page (I usually use Facelets in JSF for my J2EE apps) can have divs
for top-level structure when rendered.

It's not uncommon to want to display specific tabs, and specific links
for each tab, in this example, when the logged-in user has specific
roles. It's also not uncommon to want to display certain divs making up
an XHTML page not only based on logged-in role, but also on other
factors. Finally, perhaps you'd like to enable the input form elements
when the page is in a "Edit" mode, but disable them when the page is in
a "View" mode.

Provided that the logic for doing all of this resides in the web tier
(specifically in XHTML and JSF managed beans) I don't really have a
problem if much of it is done using JSTL tags or Facelets function tags.
To me all of this is presentation logic. The alternative would be to
have more pages and Java logic in managed beans deciding what page to
show at a finer granularity...with Facelets this would not be too
onerous but ultimately I see the tags as cleanly accomplishing the same
thing.

I can see the point of your example. In the applications I've recently
worked on, this kind of information (overall page number, or the
contextual information accompanying a paginated data table) is computed
in, and resides in, a JSF backing bean, and all the Facelets page does
is use JSF UI elements to pull that data in.

As another example, what would be your viewpoint on JSF EL? A typical
example of how I might use it is if I had values in one column of a
table, which must be colour-coded black, red or green according to the
value of yet another column. The appropriate CSS style attribute must be
determined somewhere, and to me the best place to do that is right on
the page. This is a readable compression of view logic akin to using
tags, IMO.

AHS

 

[Martin Gregorie]

Tom Anderson wrote:
[ SNIP ]

The 'if' task in ant (actually ant-contrib - and don't get me started
on how much i hate ant) looks like:
[ SNIP ]

I'm a shit disturber...I don't mind getting you started on how much
you hate Ant.

I'm no fan of it either.

Right, time for a hate-on-ant thread!

It's a build system that can't express "A depends on B" in a conmsistent
fashion. Enough said.

It probably has to be that way. I've tried using make for Java but its
problematic, both because of the legal circularities you can set up in
Java imports and because of the dependencies built into javac. I ended up
ditching make for ant because of these features of language and compiler.

That said, I much prefer make to ant. I've wondered about mixing them. By
that I mean calling ant from make to handle Java compilation and using
normal make recipes for everything else. Has anybody tried this and, if
so, what gotchas did you trip over?

 

[Mike Schilling]

On Sat, 27 Jun 2009, Arved Sandstrom wrote:

Tom Anderson wrote:
[ SNIP ]

The 'if' task in ant (actually ant-contrib - and don't get me
started on how much i hate ant) looks like:
[ SNIP ]

I'm a shit disturber...I don't mind getting you started on how
much
you hate Ant.

I'm no fan of it either.

Right, time for a hate-on-ant thread!

It's a build system that can't express "A depends on B" in a
conmsistent fashion. Enough said.

It probably has to be that way. I've tried using make for Java but
its
problematic, both because of the legal circularities you can set up
in
Java imports and because of the dependencies built into javac. I
ended up ditching make for ant because of these features of language
and compiler.

Even when building Java, Ant compiles .java file if:

1. The corresponding .class file is absent
2. The corresponding .class file is older than the .java file

This is the usual make-like file dependency logic, but it's hardcoded
into the <javac> task instead of being a standard part of Ant.