does JSP suck compared to Enhydra's XMLC?
Peter Kleinmann
Dear fellow programmers,
No offense is truly meant, but this post is meant to be provocative. Your
thoughtful
responses will help to clarify the choices for best-practice web
development.
Have any of you out there taken a look at Enhydra's XMLC? I am about to get
started with my first web-based java project, and I've been looking at
WebMacro,
Velocity, JSP and Enhydra's XMLC. Frankly, they all seem to like ok ideas
that xmlc
just blows away. Not by an inch but by a mile, at least on a conceptual
level.
For those unfamiliar, here is a snippet
Suppose we want to pop a value into a page
<table>
<tr>
<td>
<%= mybean.getYourNameInLights() %>
</td>
</tr>
</table>
With Enhydra, our html page would look like
<table>
<tr>
<td ID="yourNameInLights">
YourNameInLights
</td>
</tr>
</table>
i.e., exactly the way the designer left it (we programmers do not have to
mutilate those pretty pages generated from DreamWeaver).
Instead, Enhydra compiles the page, and gives us a bean that has accessor
methods for each html element in the page with an "ID" attribute specified.
As a result, designers can wholly own the presentation, and we don't have to
mingle code with truly static elements of presentation. Please note that
unlike
JSP, XMLC ACTUALLY DOES SEPERATE the presentation layer from the
application logic. The proof of this statement is obvious - take a jsp file
and
try to view it in a browser - you can't, unless you process it. Take the
html used
by enhydra - it is exactly as the designer left it.
So why would anyone want to use JSP, when they could use Enhydra's XMLC?
Though not as clunky as JSP, why use WebMacro or Velocity?
Once again, while I have put things in provocative terms, I really mean no
offense,
but would like to get your opinions on best-practices web development.
Thank you for your time.
Anthony Shipley
>With Enhydra, our html page would look like
><table>
> <tr>
> <td ID="yourNameInLights">
> YourNameInLights
> </td>
> </tr>
></table>
What if you wanted, let's say, a font tag for that specific cell:
<td ID="yourNameInLights">
<font color="red">
YourNameInLights
</font>
</td>
or any other markup or text in the table cell in question?
Otherwise, I'm quite happy to agree that it's a big improvement over
JSP.
anthony shipley
<math> 2 + 2 = 5 for sufficiently large values of 2</math>
Laurens
news:EdJK6.12$VK1....@typhoon2.ba-dsg.net...
>
<snip>
>
> As a result, designers can wholly own the presentation, and we don't have
to
> mingle code with truly static elements of presentation. Please note that
> unlike
> JSP, XMLC ACTUALLY DOES SEPERATE the presentation layer from the
> application logic. The proof of this statement is obvious - take a jsp
file
> and
> try to view it in a browser - you can't, unless you process it. Take the
> html used
> by enhydra - it is exactly as the designer left it.
>
Actually, your statement about the separation of presentation and
application logic is not entirely true. With XMLC you are coding HTML in
your servlet. Only, you're doing it using the Document Object Model. For
simple, fill-in-the-blanks templates like your example this does not really
apply. However, when you're creating table rows with table cells you are, in
essence, hard-coding HTML. Also, complex layouts will probably break when
they're changed by a page designer, requiring changes in the XMLC code. The
XMLC approach is most useful when the servlet programming and page design
are done by the same person. I believe many servlet programmers also create
the HTML pages. I do.
> So why would anyone want to use JSP, when they could use Enhydra's XMLC?
> Though not as clunky as JSP, why use WebMacro or Velocity?
JSP will continue to be used because Sun sponsors it. For that matter, why
do people use ASP? Because it's quick-and-dirty and for small projects
produces results fast. Of course, the larger your project becomes the less
useful and productive these solutions will be. Also, don't forget that JSP
has tag libraries. These go some way to addressing issue of separating
application logic, presentation and content. (Struts is a nice library that
seems to have gained some mindshare.)
As for WebMacro/Velocity or Freemarker, these solutions give some measure of
control over conditions and looping to the page designer using fairly simple
instructions, while XMLC does not.
>
> Once again, while I have put things in provocative terms, I really mean
no
> offense,
> but would like to get your opinions on best-practices web development.
>
The "best" approach IMO for web publishing would be to use XSLT. Granted,
you do need to convert your SQL data to XML (or a DOM or a series of SAX
events) first, but this step can be automated easily. (The latest versions
of Oracle and SQL Server can present data in XML.) Using XSLT does not tie
you to a specific platform or language. Also, XSLT processors have reached
a level of maturity over the last year and the Java XML API (JAXP) has been
implemented, too. The big advantage is that you're working with a language
that is truly meant for transforming (i.e. presenting) data and that you can
transform the data into a non-web document as well. XSLT is useful outside
of the realm of web server programming as well.
The downside is that XSLT is hard to learn and there isn't that much
documentation available (exactly because it is so difficult). Also, there
are some holes in XSLT that definitely need to be filled. Grouping,
more-or-less essential for database reports, is unnecessarily difficult
using standard XSLT. However, you can create your own extension elements
that provide this functionality.
Wrapping it up, there is no "best" way. Each approach has its advantages and
disadvantages. The best approach really depends on the practices and skills
of your team and the project you're working on.
Regards
-Laurens
Chris Smith
> Have any of you out there taken a look at Enhydra's XMLC? I am about to
get
> started with my first web-based java project, and I've been looking at
> WebMacro, Velocity, JSP and Enhydra's XMLC. Frankly, they all seem to
like
> ok ideas that xmlc just blows away. Not by an inch but by a mile, at
least
> on a conceptual level.
I think you're not being entirely fair to JSPs. There are a couple of very
good reasons for JSPs:
1. They are a standard, which is in my mind critically important as long as
they are good enough for the task at hand.
2. With tag libraries, they provide excellent content/presentation
separation, with a LOT more flexibility than a lot of other technologies.
> Suppose we want to pop a value into a page
>
> <table>
> <tr>
> <td>
> <%= mybean.getYourNameInLights() %>
> </td>
> </tr>
> </table>
With tag libraries, this looks like this:
<table>
<tr>
<td>
<mylib:yourNameInLights />
</td>
</tr>
</table>
> As a result, designers can wholly own the presentation, and we don't have
to
> mingle code with truly static elements of presentation. Please note that
> unlike JSP, XMLC ACTUALLY DOES SEPERATE the presentation layer from the
> application logic. The proof of this statement is obvious - take a jsp
file
> and try to view it in a browser - you can't, unless you process it.
> Take the html used by enhydra - it is exactly as the designer left it.
Well, you did have to add the "ID" attribute. Similarly, If I'm concerned
about being able to display a JSP with custom tags, I could write the above
as:
<table>
<tr>
<td>
<mylib:yourNameInLights>
YourNameInLights
</mylib:yourNameInLights>
</td>
</tr>
</table>
HTML browsers will ignore the unknown tag. Since I probably return
SKIP_BODY from my tag handler, the JSP interpreter will ignore the static
data. Just as with XMLC, I've modified the HTML page in a non-destructive
way.
More importantly, though, I recently did something like this in JSP tags:
<libName:error>
<font color='red'>
There were errors in this page. Please fix the following errors:
<ul>
<libName:errorMessage errorToken="BadName">
<li>The name entered was not valid.</li>
</libName:errorMessage>
<libName:errorMessage errorToken="NoPhone">
<li>You didn't enter a phone number.</li>
</libName:errorMessage>
...
<libName:defaultMessage>
<li>An unknown error was reported by the application.</li>
</libName:defaultMessage>
</ul>
</font>
</libName:error>
This allows the page designer to declare a section of code that's only
included if there are one or more error messages, and define error message
mappings for the errors. This is all in the presentation, as it should be.
My problem with most template-type page generation setups like that is that
they force you to move a lot of presentation stuff into Java code. This
makes it set in stone from the perspective of web designers, and they end up
hating you for it. As another respondent mentioned, XMLC has a lot of
capabilities for building output formats from Java through DOM, but it takes
those out of the presentation language.
In my experience, a good JSP application that's intended to be deployed in
an environment where content is entirely separated from presentation is
developed in several pieces:
1. Data objects that model the database.
2. Servlet code that interacts with data objects, and always ends up
forwarding to a JSP.
3. A tag library implementation to do any presentation of dynamic data
that's required.
4. A SAMPLE set of JSPs that are used for testing, and are given to your web
designers as a starting point.
The tag library can be made flexible enough that the web designers can
create most any look they want without resorting to requesting changes to
the Java code.
Yes, JSPs can be used otherwise, and I have done so in quick and dirty
projects that aren't going to last long. However, when you consider the
best each world has to offer, I'll take JSPs any day.
Chris Smith
Geert Van Damme
'JSP doesn't separate application logic from presentation and xxx does'
It's exactly the same as
' I heard that java is not 100% OO ?'
The main problem is absolutely not the programming language/tool, but the
developer (or architect). A tool or language can _help_ you in working more
cleanly (that can be: proper OO, using MVC,...) but these are all desing
issues, no syntax or grammar issues.
It's perfectly possible to separate presentation and application logic in
about anything. but in one language , it becomes more difficult than in
others. MVC in cgi/perl might be comparable to using OO techniques in
assembler. There are better solutions, but it's possible.
And IMHO JSP does a very good job in helping you create clean code.
Geert Van Damme
"Laurens" <sp...@block.com> wrote in message
news:9dgaa0$g5t$1...@porthos.nl.uu.net...
Chris Smith
> I really don't like all these discussion about
> 'JSP doesn't separate application logic from presentation and xxx does'
> It's exactly the same as
> ' I heard that java is not 100% OO ?'
My theory is that when people say this, they really mean that it doesn't
present each piece in its appropriate language for the developer role that
will be working with it. This is a real problem with JSP 1.0 applications:
it's hard to write really dynamic pages that don't require:
1. Writing substantial amounts of Java code in the JSP file, or
2. Writing substantial amounts of HTML code in String constants in a Java
source file
The result is that any modification to the application must involve both
Java programmers and web designers, because it might involve changing HTML
that's hard-coded into the application, or changing Java code that's
hard-coded into the presentation logic. The presentation and content can be
separated, but they are often in the wrong language.
As I explained in another response, JSP 1.1 and custom tag libraries fix
this when it's necessary to fix.
Chris Smith
Roedy Green
1. Ordinary WYSIWYG HTML editors don't understand JSP. Do they meddle
with it? Make it hard to insert/see? What editors do you use?
3. How do you verify your HTML? Do HTML verifiers/syntax checkers
trip over the JSP? or do you have to run generated pages through the
verifiers?
-
For more detail, please look up the key words mentioned in this post in
the Java Glossary at:
http://mindprod.com/gloss.html or http://209.153.246.39/gloss.html
If you don't see what you were looking for, complain!
or send your contribution for the glossary.
--
Roedy Green, Canadian Mind Products
Custom computer programming since 1963.
Almost ready to take on new work.
Laurens
Roedy Green <ro...@mindprod.com> wrote in message
news:4dhoftohva0nv2g24...@4ax.com...
>
> 1. Ordinary WYSIWYG HTML editors don't understand JSP. Do they meddle
> with it? Make it hard to insert/see? What editors do you use?
Dreamweaver Ultradev recognizes JSP syntax. Code between <% and %> is
displayed as an icon in the design view. Actually, Dreamweaver works best
when you put all your code in the JSP(not the recommended approach). This
way you can take advantage of the live preview feature. Unfortunately, it
doesn't recognize tag libraries by itself(it supports JSP 1.0). You need to
declare them in a
separate Dreamweaver configuration file to make them editable using
Dreamweaver's dialogs.
-Laurens
David H. Young
cell."
My answer would be "use cascading style sheets to address this." For
example, if the app were a Football Player status application, the html
might partially look like below. You would use the xmlc compiler to
build the dom template, then access class attribute that refers to the
stylesheet and replace it with playerInjured (red) or playerHealthy
(green).
As long as we're talking about supporting a healthy separation of
designer
and developer, CSS should be part of the equation, giving control to the
designer. I show the html and suggested xmlc Java code here...
<style type="text/css">
<!--
.playerInjured { color: #00CC00; font-style: italic}
.playerHealthy { color: #3333FF}
-->
</style>
</head>
<table> <tr><td id=yourNameInLights class="playerStatus">
Your name in lights</td></tr>
...
The Java servlet code looks like:
// hard coded values that could be fetched instead by a business object.
String playerName = "Pele";
boolean playerHealthy = true;
// Grab the Java class created by the compilation of the HTML file by
xmlc
// during development time. It contains the dom and xmlc-generated
convenience
// methods.
football = (FootballHTML)comms.xmlcFactory.create(FootballHTML.class);
// Use xmlc generated method to update the content.
football.setTextYourNameInLights(playerName);
// Use another xmlc generated method to fetch the table cell node.
// need to import org.w3c.dom.html
HTMLTableCellElement cell = football.getElementYourNameInLights();
cell = football.getElementYourNameInLights();
// Update the class attribute with the CSS the represents the player's
health.
if (playerHealthy == true) {
cell.getAttributeNode("class").setValue("playerInjured");
} else {
cell.getAttributeNode("class").setValue("playerHealthy");
}
comms.response.writeDOM(football);
Hope that was useful.
David
You would access the value of
Anthony Shipley wrote:
--
David H. Young
Chief Evangelist
Lutris Technologies, Inc.
1200 Pacific Avenue, Suite 300
Santa Cruz, CA 95060 USA
831.460.7310; 831.471.9754 (fax)
http://www.lutris.com
http://www.enhydra.org
Anthony Shipley
>As I explained in another response, JSP 1.1 and custom tag libraries fix
>this when it's necessary to fix.
I don't keep up with JSP details so I might be showing my ignorance -
again.
Are custom tag libraries not just another way of embedding presentation
tags within code?
Chris Smith
> I don't keep up with JSP details so I might be showing my ignorance -
> again.
>
> Are custom tag libraries not just another way of embedding presentation
> tags within code?
I'm not sure what you mean. What they are is a way to define certain
XML-syntax tags that be included in JSP code to do dynamic things. At
request time, the tags are evaluated to produce the real HTML. The
advantage over the scripting components is there is NO code within the
presentation pieces.
Chris Smith
David H. Young
article on custom tag libraries. It'll either impress you or scare you
away with code like:
<javapro:stockQuote symbol="<%=request.getParameter(\"ticker\")%>"/>
I love this bit of irony since part of the idea of taglibs is to remove the
need
for Java code from the HTML template file in order to maximize the
separation of designer and developer.
But it is really well written. To relate it to the subject line of this
thread,
all the things that you have to write in taglib language are completely
unneccesary with Enhydra XMLC. And there's no need to introduce
new tags (and therefore no need for pointing to tld files and what not)
If I get time, I'll rewrite his Yahoo ticker example using XMLC and
post a reference link to this newsgroup.
David
Chris Smith wrote:
--
brl...@my-deja.com
> If I get time, I'll rewrite his Yahoo ticker example using XMLC and
> post a reference link to this newsgroup.
If you get time? That must be a complicated example. I haven't read
the article myself. How about a simpler one. What would be the XMLC to
output something like this:
<a title="Get Quote"
href="http://finance.yahoo.com/q?s=[ticker]&d=v4">[ticker]</a>
Of course, the web designer should control "Get Quote" and other
attributes of the tag (e.g. class), while the programmer controls where
the ticker comes from (e.g. database).
--
Bruce R. Lewis http://brl.sourceforge.net/
I rarely read mail sent to brl...@my-deja.com
Chris Smith
> Check out the June 2001 issue of JavaPro. Excellent, excellent
> article on custom tag libraries. It'll either impress you or scare you
> away with code like:
>
> <javapro:stockQuote symbol="<%=request.getParameter(\"ticker\")%>"/>
>
> I love this bit of irony since part of the idea of taglibs is to remove
the
> need for Java code from the HTML template file in order to maximize the
> separation of designer and developer.
To be honest, this makes very little sense to me. I see design choices in a
web-based application as progressing something like this:
1. Just a quick hack to stick dynamic content in a page: use a JSP with
scripting
2. Okay, it's getting a bit more involved but not a huge project and won't
require long-term maintenance: use servlets that forward to JSPs with
scripting
3. Code will be much-used and modified: use a servlet that forwards to a JSP
with custom tags
I don't see where you go about using custom tags, but not servlets. Seems
kinda pointless to me. To write this in a better application model, you'd
make the symbol attribute optional, and if it's not present, retrieve is as
a request attribute. Your servlet would set the request attribute before
forwarding.
> But it is really well written. To relate it to the subject line of this
> thread, all the things that you have to write in taglib language are
> completely unneccesary with Enhydra XMLC. And there's no need to
introduce
> new tags (and therefore no need for pointing to tld files and what not)
Yes, but this is a very simple template-substitution example. For a more
complex dynamic page, involving things like conditional inclusion of text,
looping, or dynamic formatting of tables, JSP custom tags are about the only
reasonable way I've seen to do to (or jhtml oparams to an extent, but who
wants those any more?)
I haven't used Enhydra though... does XMLC provide a way to do that while
still keeping all the HTML in your presentation file?
Chris Smith
David H. Young
simple... for conditional text inclusion, looping, you
would do the following with xmlc... BTW, Jason Hunter's
updated Java Servlet Programming (2nd Edition) has a
chapter dedicated to xmlc programming... In the
meantime, say you have a table... you want to add names
to...
<table>
<tr id=friendRow><td=friendCell>joe</td></tr>
<tr class=delete-me><td>pete</td></tr>
</table>
xmlc compiles this into a Java class containing a DOM
tree which is your template. During compile, you indicate
to xmlc to delete all elements in the class "delete-me".
The purpose of this is to give designers the ability to
insert mocked up rows for design reviews. Also during
compile, the id values are used to create convenience
methods that reduce the need to do DOM traversal...
id=friendsTbl becomes getElementFriendsTbl(), id=friendCell
becomes getElementFriendRow() and setTextFriendCell().
The Java code I wrote looks like this...
public void doGet(HttpServletRequest request, HttpServletResponse response)
throws ServletException, IOException {
XMLCContext xmlc;
FriendsHTML page;
String now;
String friendsList [] = {"George", "Paul", "Ringo", "John"};
xmlc = XMLCContext.getContext(this);
page = (FriendsHTML) xmlc.getXMLCFactory().create(FriendsHTML.class);
// find our way to the DOM nodes representing the table
// and the row element.
HTMLTableElement table = page.getElementFriendsTbl();
HTMLTableRowElement templateRow = page.getElementFriendRow();
// loop through the list of friends, update the cell,
// in the template, then clone the template and add it
// to the table.
for (int i=0; i<friendsList.length; i++) {
page.setTextFriendCell(friendsList[i]);
Node clonedRow = templateRow.cloneNode(true);
table.appendChild(clonedRow);
}
// get rid of the template now that we're done with it.
table.removeChild(templateRow); // removes the template
//spit out the HTML back to the client.
xmlc.writeDOM(request, response, page);
Hope that helps on the conceptual side... more stuff on xmlc at
http://xmlc.enhydra.org
David
Chris Smith wrote:
> "David H. Young" <david...@lutris.com> wrote ...
> > Check out the June 2001 issue of JavaPro. Excellent, excellent
> > article on custom tag libraries. It'll either impress you or scare you
> > away with code like:
> >
> > <javapro:stockQuote symbol="<%=request.getParameter(\"ticker\")%>"/>
> ....
>
> > But it is really well written. To relate it to the subject line of this
> > thread, all the things that you have to write in taglib language are
> > completely unneccesary with Enhydra XMLC. And there's no need to
> introduce
> > new tags (and therefore no need for pointing to tld files and what not)
>
> Yes, but this is a very simple template-substitution example. For a more
> complex dynamic page, involving things like conditional inclusion of text,
> looping, or dynamic formatting of tables, JSP custom tags are about the only
> reasonable way I've seen to do to (or jhtml oparams to an extent, but who
> wants those any more?)
>
> I haven't used Enhydra though... does XMLC provide a way to do that while
> still keeping all the HTML in your presentation file?
>
> Chris Smith
--