JSP still relevant

[EricF]

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

Ii is probably not an option but if you like your shell scripts, cygwin on
windows will probably run them.

Maven is an option to ant. It is more concise and I like that, but it has its
own share of problems.

Eric

 

[Tom Anderson]

Just curious: which CMS is that?

The CMS That Cannot Be Named. Because Its Proprietors Have Got Pretty
Upset With People Slagging It Off In Public In The Past, And I Don't Want
Any Trouble.

tom

 

[Tom Anderson]

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.

This is where we disagree.

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.

Here too. I think java *always* allows a clearer, less complex and
easier-to-follow expression of logic than tags. I'm not talking about
undue complexity here, i'm talking about where to put due complexity.

tom

 

[Tom Anderson]

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.

I agree entirely that it's presentation logic, but it's exactly this kind
of stuff that i don't want to see done with tags. Those pages are going to
be full of great big unreadable verbose gobs of JSP code mixed in the the
page HTML, when it could all be cleanly separated into java code.

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 don't see why you'd have to have more pages - but then i know nothing
about JSF.

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.

That sounds like the kind of thing i envisage.

As another example, what would be your viewpoint on JSF EL?

I've never used JSF. How does it compare to JSP 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.

I like the backing bean approach. You'd write something like:

<c:forEach items="maintable.rows" var="row">
<td class="<cut value=""${row.HTMLClass}>"></td>
</c:forEach>

There, i'm using JSTL and EL purely as the glue to get values from the
objects backing the page.

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!

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

I'm not sure about that. Make and ant have different philosophies - make
is about a tree of dependencies, where you build a target by building all
its dependencies, and ant is about a sequence of steps, where you build a
target by executing all the steps for it. It's analogous to the difference
between functional and imperative languages. If you prefer make's
philosophy, you won't like ant, but that doesn't mean it's objectively
better.

My opinion of this difference is coloured by the fact that i don't use
build tools to do partial rebuilds, which is the bread and butter of the C
developer - i have Eclipse to do all that sort of thing for me. Rather, i
use the tools to carry out the process required to move from a project
freshly checked out from CVS to a running JBoss instance - compile the
code, package a JAR, construct WARs and EARs, do various incantations
required by the framework we use, make datasource XMLs, clear out the
database, define all the tables, import the initial data, etc. That's a
process in which every step is carried out every time, so the idea of
checking dependencies doesn't seem very useful.

Now, it's true that if i'm developing, rather than setting up a production
machine or something, many of these steps could be skipped: if i haven't
changed the database definition, there's no need to recreate the tables
from scratch, just to empty out their contents. That's somewhere a
make-like system could be useful - if i had a local file that was a totem
for the database, so its last-modified date corresponded to the when the
database was last rebuilt, i could have a target which rebuilt the
database only if the SQL had changed. But i'm not convinced this would be
that useful - the complete rebuilds i do are fairly infrequent (a few
times a day), fairly quick anyway (a few minutes), and are for the kind of
purpose where you'd want to do a 'make clean' anyway (checking everything
works before committing to CVS etc). Still, i could be wrong; i'll have to
think about this.

tom

 

[Tom Anderson]

Ii is probably not an option but if you like your shell scripts, cygwin
on windows will probably run them.

It probably wouldn't go down well with the customer. But even if it did,
my (limited) experience with cygwin suggests that it's mostly a rapid path
to madness.

Maven is an option to ant. It is more concise and I like that, but it
has its own share of problems.

My experience with Maven has not been good, but that's mostly to do with
it being incredibly broken at downloading things from repositories: if you
have multiple dependencies and multiple repositories configured, but where
not all repositories have all the dependencies, then when it asks a
repository for a dependency it doesn't have, it just happily downloads the
404 error page and tries to use that, which if course is unsuccessful. If
you give it the flag which makes it check result codes (-C?), then when it
gets that 404, it stops dead, rather than trying to find another
repository. Also, it has some insanely convoluted attitude to running the
tests, where it insists on recompiling all the sources, recopying all the
resource files, etc, then hiding the test results in some random
directory, where you have to go and grep to find out what happened. I
guess this is okay for the build-from-scratch paradigm, but it's totally
hopeless as support for active development.

tom

 

[Arved Sandstrom]

I agree entirely that it's presentation logic, but it's exactly this
kind of stuff that i don't want to see done with tags. Those pages are
going to be full of great big unreadable verbose gobs of JSP code mixed
in the the page HTML, when it could all be cleanly separated into java
code.

See my below - Facelets processing results in no generated servlets. So
no Java scriptlets in pages either (although I've seen 3rd party tags
that accept Bean Shell). As I also point out below, JSF doesn't require
Facelets; you can use JSPs instead.

I don't find a typical XHTML Facelets template page, or a typical XHTML
Facelets view page, or a typical XHTML Facelets component, to be
unreadable. Not if it's well-written. There are going to be a fair few
JSF tags for UI components anyhow (which may make you shudder anyway )

I don't see why you'd have to have more pages - but then i know nothing
about JSF.

Many - if not most - JSF developers will be using JSPs (hopefully JSPX),
so then this would be a moot point. For the purposes of this discussion
the important thing is that Facelets processing of XHTML is not going to
generate servlets. Java scriptlets therefore make no sense in Facelets.

As far as my reference to more pages goes, I believe this would apply to
all view technologies. Regardless of what view technology we're using we
have a great deal of control over what portions of a page we actually
display, based on various variables. At some point, if there's way too
much logic in the page (however that logic is implemented) that has to
do with these kinds of decisions, it may be better to refactor in the
backing Java code, and have logic there instead that chooses from
several views (these several replacing the original single target page).

That sounds like the kind of thing i envisage.


I've never used JSF. How does it compare to JSP EL?

If you're using Unified EL (EL 2.1, in JSF 1.1 and up, JSP 2.1) then
they are the same. One of the main differences in usage would probably
be due to the different lifecycles - I would normally use the #{...}
deferred syntax, while JSP people would use the ${...} immediate syntax.

I like the backing bean approach. You'd write something like:

<c:forEach items="maintable.rows" var="row">
<td class="<cut value=""${row.HTMLClass}>"></td>
</c:forEach>

There, i'm using JSTL and EL purely as the glue to get values from the
objects backing the page.

tom

In JSF the example I mentioned (somewhat modified) could look something
like:

<h:dataTable id="table1" value="#{maintable.rows}" var="row">
<h:column>
<hutputText value="#{row.description}"
style="#{row.status ? 'color: red' : 'color: green'}" />
</h:column>
</h:dataTable>

The difference being, I'm also handling the styling decision directly in
the page.

AHS

 

[Lew]

I've never used JSF. How does it compare to JSP EL?

Java Server Faces is a component library, Expression Language is a programming
language, or rather, a piece of one, that provides glue logic.

 

[Lew]

The CMS That Cannot Be Named. Because Its Proprietors Have Got Pretty
Upset With People Slagging It Off In Public In The Past, And I Don't
Want Any Trouble.

What, are you afraid that their lawyers will try to (speciously) argue that
your exercise of free speech to tell the truth (as you experienced it)
regarding their product constitutes some sort of actionable offense?

Really?

C'mon, just tell us. Criminy. Demonstrate the courage of your convictions.

 

[Tom Anderson]

What, are you afraid that their lawyers will try to (speciously) argue that
your exercise of free speech to tell the truth (as you experienced it)
regarding their product constitutes some sort of actionable offense?

Really?

They've done it before, so yes. Bear in mind that 'action' in this case
could just mean 'moaning at my boss and threatening to withdraw our
Official Partner status', but even that would be annoying.

C'mon, just tell us. Criminy. Demonstrate the courage of your
convictions.

I'm demonstrating it right now - it's just that i haven't got much!

tom

 

[Lew]

They've done it before, so yes. Bear in mind that 'action' in this case
could just mean 'moaning at my boss and threatening to withdraw our
Official Partner status', but even that would be annoying.

A company like that doesn't deserve to be in business. Such injustice.
Obviously their product is crap or they wouldn't have to resort to strong-arm
tactics.

 

[Tom Anderson]

I don't find a typical XHTML Facelets template page, or a typical XHTML
Facelets view page, or a typical XHTML Facelets component, to be
unreadable. Not if it's well-written.

To some extent, this is a matter of taste, of course. You might have more
tolerance for tag code than me.

But well-written code is not the problem. It's the scope for badly-written
code, and for large bits of normally-written code, to become
incomprehensible.

Also, how do you debug code written in tags? Is there a debugger for it?
Debugging JSP code with a java debugger is rather painful; it would be far
better from that perspective if the code was in java.

There are going to be a fair few JSF tags for UI components anyhow
(which may make you shudder anyway )

This is why i've stayed away from JSF so far.

Many - if not most - JSF developers will be using JSPs (hopefully JSPX), so
then this would be a moot point. For the purposes of this discussion the
important thing is that Facelets processing of XHTML is not going to generate
servlets. Java scriptlets therefore make no sense in Facelets.

Okay, got it. I'm happy to turn my back on scriptlets, as long as the
logic a can be written in java somewhere else, like a bean.

As far as my reference to more pages goes, I believe this would apply to
all view technologies. Regardless of what view technology we're using we
have a great deal of control over what portions of a page we actually
display, based on various variables. At some point, if there's way too
much logic in the page (however that logic is implemented) that has to
do with these kinds of decisions, it may be better to refactor in the
backing Java code, and have logic there instead that chooses from
several views (these several replacing the original single target page).

Right, got you. Agreed.

In JSF the example I mentioned (somewhat modified) could look something like:

<h:dataTable id="table1" value="#{maintable.rows}" var="row">
<h:column>
<hutputText value="#{row.description}"
style="#{row.status ? 'color: red' : 'color: green'}" />
</h:column>
</h:dataTable>

The difference being, I'm also handling the styling decision directly in
the page.

In a simple case like this, it's not too bad (although using a style
rather than a class - shame on you! ). It's when you apply this
approach to bigger problems that it all starts to go wrong.

tom

 

[Mike Schilling]

A company like that doesn't deserve to be in business. Such
injustice. Obviously their product is crap or they wouldn't have to
resort to strong-arm tactics.

Yeah, Tom, tell 'em that!