RE: You make the decision Velocity/Turbine vs. Struts/JSP
Or to put it another way, Putting Velocity on top of Servlets doesn't fix the warts in Servlets. It simply hides them until your developers find them. See getInitParameter in ymtd. -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au NetRexx: http://www.multitask.com.au/NetRexx.nsf - Forwarded by dIon Gillard/Multitask Consulting/AU on 09/03/2001 01:32 AM - RE: You make the decision Velocity/Turbine vs. Struts/JSP But, the point of what I am trying to say (and I will try to clarify it further in the document) is that by using Struts and JSP there is *NO* enforcement that requires you to not use scriptlets. [snip] Putting Struts on top of JSP doesn't fix the warts in JSP. It simply hides them until your developers find them. Jon; if I read you correctly a JSP engine would be better for having its scriptlets capability disabled. Or less radically allow the it to be specified in the web.xml file that scriptlets are not allowed for a given web-app. I think I buy that. In retrospect I even wish I had been able to do that on a few JSP projects past. Joerg Beekmann [EMAIL PROTECTED] Previous Document Next Document Return to View
Re: You make the decision Velocity/Turbine vs. Struts/JSP
So far, the arguments have been based on whether it is
better for the page designer or Java developer. How
about performance? IHMO, it would be interesting to
find out the timing for each of the three approaches.
I would agree with the Velocity's author that JSP
taglibs is no much better than ColdFusion tags if
performance is not addressed.
--- Incze Lajos [EMAIL PROTECTED] wrote:
On Sun, Mar 04, 2001 at 08:11:31PM -0800, Martin
Cooper wrote:
Niall's revised example is *almost* right. Here's
a fixed version of it:
html
headtitleHello/title/head
body
h1
% if (request.getParameter("name") == null) %
Hello World
% else %
Hello, %= request.getParameter("name")
%
/h1
/body/html
The difference is that in order to print out the
name parameter, you need to
use an expression rather than a scriptlet (i.e.
%= ... % rather than %
... %).
Of course, with Struts, you could write this
without scriptlets altogether:
html
headtitleHello/title/head
body
h1
logic:notPresent parameter="name"
Hello World
/logic:notPresent
logic:present parameter="name"
bean:parameter id="name" name="name"/
Hello, bean:write name="name"/
/logic:present
/h1
/body/html
Hope this helps.
--
Martin Cooper
I think the "canonical" solution in JSP is something
like this:
---
jsp:usebean id="name" scope="request"
type="java.lang.String"
jsp:setProperty name="name" value="Word" /
/jsp:usebean
html
headtitleHello/title/head
body
h1
Hello %= name %
/h1
/body/html
---
On the other hand I do share Jon Stevens' views that
this syntax
is really not for page design people.
incze
__
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: You make the decision Velocity/Turbine vs. Struts/JSP
Yea! Great feedback! I will reply in more detail soon. -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html
Re: You make the decision Velocity/Turbine vs. Struts/JSP
Niall,
This is *excellent* feedback. I really appreciate it and look forward to
working with you on this. My replies are included below. I hope you enjoy.
I am currently queuing up a bunch of responses so that I can go through and
update the document with feedback like yours.
on 3/4/01 11:55 AM, "Niall Pemberton" [EMAIL PROTECTED]
wrote:
Jon,
http://jakarta.apache.org/velocity/ymtd/ymtd.html
I read your comparison of Turbine/Velocity and Struts/JSP and although you
state it your aim to be "fair and unbiased", I think you failed since most
of your examples, although sytanctically correct, were poor examples of the
use of Struts and Jsp. I only started getting into Jsp Struts a couple of
weeks ago but below are my comments on your article. I also copy this to the
struts mailing list as I am sure more experienced people may be able to
comment better.
Yes, I think I should clarify the "fair and unbiased". I will do so.
In your first example "Saying Hello" there is not need whatsoever in Jsp to
have any "out.println" statements. The example you gave could have been
coded in the following way:
html
headtitleHello/title/head
body
h1
% if (request.getParameter("name") == null) %
Hello World
% else %
Hello, % request.getParameter("name") %
/h1
/body/html
Thanks! I will update the current "right" example on the page to show your
code above.
On the subject of "Generation", I don't believe this is a big issue, since
1) its automatically handled by the servlet container and therefore not a
big issue to developers and 2) the performance issue is only relevant when
you change the application, its not like it happens every time you run the
jsp.
I specifically addressed your points #1 and #2 on that page by actually
agreeing with you. I think you missed the point of what I was trying to say.
I'm not saying that because of generation the system is slower or that it is
a big issue to have the servlet container do the work for you.
Sometimes, it takes explaining how the underlying system works in order to
explain the issues that are involved. In other words, as you go on to read
in the essay, quite a lot of the errors involved with working with or even
developing JSP are a result of the fact that JSP uses Generation in the
first place. The simple conclusion is that if you don't use Generation, you
don't have those issues.
Regardless of whether or not they are a "big issue" or not, they are still
an Issue and I see them come up quite a bit on the mailing lists.
(Note: My day job is to develop an Issue Tracking System, so I think I have
a pretty good understanding of what an Issue is. smile)
On the subject of "Error Handling", you are comparing Velocity only with
Jsp - the idea of Struts is that, it takes the need for Scriptlets out of
Jsp by providing custom tags (java classes) to deal with those situations.
What you quote here from Jason's books is only relevant to Scriptlets, not
well written Struts applications. The issues stated there are exactly why a
framework such as Struts was developed and an argument for using Struts.
100% True! I'm not suggesting otherwise. I have *always* said that if you
are going to use JSP, you should use Struts. Without Struts, JSP would be
even worse!
But, the point of what I am trying to say (and I will try to clarify it
further in the document) is that by using Struts and JSP there is *NO*
enforcement that requires you to not use scriptlets.
This goes back to the argument that says that embedding Java code in your
page is a bad thing. Of course it is! However, the fact of the matter is
that even in Struts own documentation, there is Java code embedded in the
page. If you go read the articles at Javaworld.com that talks about JSP,
each and every one of them does *something* wrong and it is actually
*harder* to code a page correctly than it is to do it incorrectly.
The final point being that I feel that developers (and users) should not
have to jump through hoops to do things correctly. Struts and JSP makes
people jump through hoops.
Again in the section of "JavaBeans" you are not comparing like-with-like.
Velocity/Turbine will have the same issues of "Scope" that any Web
Application has and from what I see of your Velocity/Turbine example, you
have just hidden this from the Web Designer.
YES! That is the *POINT*! Hide the hard parts from the web designer!
:-)
The same can be done in a
Struts application with Struts tags rather than the "jsp:useBean" tag.
Again your quote from Jason's book relates solely to Jsp and is not a fair
comparison to Struts.
In my opinion JSP == Struts (keep reading).
I'll ignore the sample app section, again its Jsp not Struts.
Again, how can you take a technology and build on top of it and then ignore
the foundations for which it is built upon? Especially given that there is
nothing truly hiding that foundation or preventing you from using it?
You extend a class to add functionality to the
Re: You make the decision Velocity/Turbine vs. Struts/JSP
I'm going through the document and making some changes based on yours (and others) suggestions and I have a question: on 3/4/01 11:55 AM, "Niall Pemberton" [EMAIL PROTECTED] wrote: I read your comparison of Turbine/Velocity and Struts/JSP and although you state it your aim to be "fair and unbiased" Where exactly do I state that? I see: "Therefore, a lot of effort has gone into this essay to state things as fairly and accurately as possible." Which is true and I don't think that should change. But, I don't see where I said "unbiased". :-) -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html
RE: You make the decision Velocity/Turbine vs. Struts/JSP
Your're right, my mistake, but I'm wasn't criticising your aim, just the acutal guts of the comparison, the aim's a good one :-) Niall -Original Message- From: Jon Stevens [mailto:[EMAIL PROTECTED]] Sent: 04 March 2001 21:47 To: Niall Pemberton Cc: [EMAIL PROTECTED] Subject: Re: You make the decision Velocity/Turbine vs. Struts/JSP I'm going through the document and making some changes based on yours (and others) suggestions and I have a question: on 3/4/01 11:55 AM, "Niall Pemberton" [EMAIL PROTECTED] wrote: I read your comparison of Turbine/Velocity and Struts/JSP and although you state it your aim to be "fair and unbiased" Where exactly do I state that? I see: "Therefore, a lot of effort has gone into this essay to state things as fairly and accurately as possible." Which is true and I don't think that should change. But, I don't see where I said "unbiased". :-) -jon -- If you come from a Perl or PHP background, JSP is a way to take your pain to new levels. --Anonymous http://jakarta.apache.org/velocity/ymtd/ymtd.html
Re: You make the decision Velocity/Turbine vs. Struts/JSP
Niall's revised example is *almost* right. Here's a fixed version of it:
html
headtitleHello/title/head
body
h1
% if (request.getParameter("name") == null) %
Hello World
% else %
Hello, %= request.getParameter("name") %
/h1
/body/html
The difference is that in order to print out the name parameter, you need to
use an expression rather than a scriptlet (i.e. %= ... % rather than %
... %).
Of course, with Struts, you could write this without scriptlets altogether:
html
headtitleHello/title/head
body
h1
logic:notPresent parameter="name"
Hello World
/logic:notPresent
logic:present parameter="name"
bean:parameter id="name" name="name"/
Hello, bean:write name="name"/
/logic:present
/h1
/body/html
Hope this helps.
--
Martin Cooper
- Original Message -
From: "Niall Pemberton" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Sunday, March 04, 2001 11:55 AM
Subject: You make the decision Velocity/Turbine vs. Struts/JSP
Jon,
http://jakarta.apache.org/velocity/ymtd/ymtd.html
I read your comparison of Turbine/Velocity and Struts/JSP and although
you state it your aim to be "fair and unbiased", I think you failed
since most of your examples, although sytanctically correct, were poor
examples of the use of Struts and Jsp. I only started getting into Jsp
Struts a couple of weeks ago but below are my comments on your article.
I also copy this to the struts mailing list as I am sure more
experienced people may be able to comment better.
In your first example "Saying Hello" there is not need whatsoever in Jsp
to have any "out.println" statements. The example you gave could have
been coded in the following way:
html
headtitleHello/title/head
body
h1
% if (request.getParameter("name") == null) %
Hello World
% else %
Hello, % request.getParameter("name") %
/h1
/body/html
On the subject of "Generation", I don't believe this is a big issue,
since 1) its automatically handled by the servlet container and
therefore not a big issue to developers and 2) the performance issue is
only relevant when you change the application, its not like it happens
every time you run the jsp.
On the subject of "Error Handling", you are comparing Velocity only with
Jsp - the idea of Struts is that, it takes the need for Scriptlets out
of Jsp by providing custom tags (java classes) to deal with those
situations. What you quote here from Jason's books is only relevant to
Scriptlets, not well written Struts applications. The issues stated
there are exactly why a framework such as Struts was developed and an
argument for using Struts.
Again in the section of "JavaBeans" you are not comparing
like-with-like. Velocity/Turbine will have the same issues of "Scope"
that any Web Application has and from what I see of your
Velocity/Turbine example, you have just hidden this from the Web
Designer. The same can be done in a Struts application with Struts tags
rather than the "jsp:useBean" tag. Again your quote from Jason's book
relates solely to Jsp and is not a fair comparison to Struts.
I'll ignore the sample app section, again its Jsp not Struts.
The "Taglibs" section is the first serious section which deals with
Struts and you start with cheap points about "cutting edge of a broken
wheel" - so tell me how is Velocity cutting edge then? - yet another
scripting language to handle presentation that a Web Designer needs to
get to grips with. The idea with Jsp/Struts is that it extends HTML in
the same "style" to what Web Designers are used to.
I would be the first to say the Struts documentation could be better but
the two examples that you listed from the Struts documentation were
small examples used to illustrate specific Struts features and not the
best way to develop Struts applications on the Model 2 architecture. The
first example using the logic:equal tag is poor because it
encapsulates the "business logic" (I know its simple) of the app in the
presentation and therefore shouldn't have been in the Jsp. Complex logic
shouldn't be in the presentation layer and so their use should be
limited. The "if. . . .else" logic of Velocity looks good to me, as a
programmer, but I think a Web Designer would be more at home with the
Tag Style they are used to.
In your second example from the Struts document which uses a Scriptlet
to define an ArrayList - this has clearly been done to make the example
simple (a point I seem to remember being made in the document, though I
couldn't find the example again) - it is a break from the MVC
architecture but its not how Struts should be used, this collection
would have been created in the "logic" java end and put into scope ready
for a Web Designer to use through Struts tags - as simple or simpler
than the Velocity example.
And finally - the example from "Jason Hunters" book which you say has
been entirely implemented as a Struts app - this is
Re: You make the decision Velocity/Turbine vs. Struts/JSP
A question I have... is it feasible at all to use Velocity as the presentation mechanism with a Struts MVC framework? Regards, James W. -- This e-mail is from Cards Etc Pty Ltd (ACN: 069 533 302). It may contain privileged and confidential information. It is intended for the named recipient(s) only. If you are not an intended recipient, please notify us immediately by reply e-mail or by phone on +61 2 9212 7773 delete this e-mail from your system. --
Re: You make the decision Velocity/Turbine vs. Struts/JSP
I think it might be. Basically, Velocity renders the output, and passes it back. When used with a WebApp, the Velocity engine gets wrapped in a servlet, which pipes the output to the browser. From Strut's viewpoint, it wouldn't be any different than rendering a PDF or GIF. You just pass null back to controller, and everybody's happy. In the Velocity demo app, there's a controller that uses a switch statement to choose a template. It would be cool seeing it use the Strut's ActionMappings instead. [EMAIL PROTECTED] wrote: A question I have... is it feasible at all to use Velocity as the presentation mechanism with a Struts MVC framework? Regards, James W. -- This e-mail is from Cards Etc Pty Ltd (ACN: 069 533 302). It may contain privileged and confidential information. It is intended for the named recipient(s) only. If you are not an intended recipient, please notify us immediately by reply e-mail or by phone on +61 2 9212 7773 delete this e-mail from your system. -- -- Ted Husted, Husted dot Com, Fairport NY USA. -- Custom Software ~ Technical Services. -- Tel 716 737-3463. -- http://www.husted.com/about/struts/
Re: You make the decision Velocity/Turbine vs. Struts/JSP
[EMAIL PROTECTED] wrote: A question I have... is it feasible at all to use Velocity as the presentation mechanism with a Struts MVC framework? The simple answer is "of course". The forward mechanism can easily forward to a servlet that displays the appropriate Velocity template, or your Actions can do so directly if they want to. However, you will want to research (at least) the following issues: * Velocity runs off of a "context" object to make things visible to the template. How does it deal with objects in all three relevant scopes (request, session, and application -- page scope is relevant only in a JSP environment)? * You would need to establish conventions for how to decide which template(s) should be selected for display, and what sets of attributes get exposed to them. * If you utilize the internationalization support of tags like bean:message, you will need to figure out an alternative strategy. * There is a synergy between the way that the form-based tags in Struts work together with the form bean auto-population of properties that you would give up, although I imagine there are workarounds to that. * I haven't looked real deeply, but does Velocity have an easy way to redisplay the current values of input fields like the Struts custom tags do? If not, and if this is important to your app, you will want to determine how to work around it. * There are lots of other conveniences (automatic URL encoding of hyperlinks, automatic filtering of HTML-sensitive characters, and so on) that the Struts tags do for you that you will need to work around if you utilize them. * Scriptlets and scriptlet expressions are not allowed in a Velocity template -- if you need to do something not supported by the Velocity language you will have to accomplish it some other way. * Beyond scriptlets, you gain the ability to perform the unique features of a Velocity template, and give up the ability to use all the unique features of JSP pages -- including giving up on the ability to utilize the smarter tags of future versions of Struts (for example, optional generation of client side JavaScript for field validation), or any other JSP custom tag library that is available. Regards, James W. Craig McClanahan
