Re: JSP still relevant
On Sun, 28 Jun 2009, Arved Sandstrom wrote:
Tom Anderson wrote:
On Sat, 27 Jun 2009, Arved Sandstrom wrote:
Tom Anderson wrote:
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.
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.
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.
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="<c:out 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.
In JSF the example I mentioned (somewhat modified) could look something like:
<h:dataTable id="table1" value="#{maintable.rows}" var="row">
<h:column>
<h:outputText 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
--
limited to concepts that are meta, generic, abstract and philosophical --
IEEE SUO WG