Hi Jon, you may know my biases, but in the interests of keeping the article even handed, I have some comments to make. Say Hello --------- * e.g. "The primary difference between the two is the way that output is performed. With JSP, one needs to embed "code" within <% %> tags and for Velocity, one does not need to do that." But with Velocity, one needs to embed "code" (special tags, e.g. #if ($request.getParameter("name") == null) )into the page. It's not clear from the essay that #if isn't just text being displayed, or what the rules are for determining when #xxx is a velocity directive, e.g. in a <a href="#if">if statement</a>. * The examples provided are not examples of using Struts at all. In the spirit of "What we do here (that Jason couldn't do in the book) is put JSP/Struts and Velocity/Turbine on the same page together for a direct side-by-side comparison." this isn't happening. * "Of course, people in the know, would recommend that we write JSP like this:..." most of the people in the know I know, would frown heavily on the snippet provided. * "There is also a bit of a disconnect as to when the ";" needs to be added and when it does not.". Ditto goes for $ and # * "However, in more complex examples (like with a for/foreach loop) it becomes much more clear why it can be advantageous to see the logic in the page.". In deference to the MVC mentions, this really should point out that only 'view' logic is advantageous, although this might be stating the obvious, I'm not understimating anyone's intelligence, IMHE it's usually not a great idea. Generation ---------- * "A major problem with the generated code is that it does not check to make sure that the output stream is still open before attempting to write to it. It also has the issue that if the stream is closed or an IOException is thrown while attempting to output to the stream, there is no way to catch it without using a specially defined error handler.".- Choosing ONE jsp compilers bug and treating it as a generic JSP/Struts design issue is a stretch. * "One final problem in the design shown below is that the JSP page only catches Exception's". Again these are specifics of Jasper, not JSP/Struts. Error Handling -------------- * "Again, Velocity does not suffer from these same problems because there is no intermediate step and no layers of abstraction." What's the AST mentioned in generation if not a alyer of abstraction? * The examples given here are again not relevant to typical Struts/JSP usage. * There do not seem to be any examples provided of Velocity error messages. To be fair you should at least show how great they are. * Some JSP compilers will directly specify line# in the .jsp file, rather than in the generated servlet. See Orion's appserver for a great example. * "JSP also allows one to define an error page that is used if an Throwable exception is thrown during the processing of a page. Doesn't this again break the MVC model?". This could do with an explanation. Rhetoric is not as persuasive as proof. How does providing an error page (view) break MVC? What does Velocity do in these circumstances: See the last paragraph of the page "The Exception will contain the line number and column number in the .vm file of where the error happened" - Sounds suspicously like an error page to me. * "VelocityServlet" - is this an intermediate step? So far the article has revealed a template file (.vm), a "parser", an AST and a servlet. I feel there is a double standard being applied, or at least hidden. * " For example, this VTL defines a String $foo and then attempts to call its substring() method on it would throw an IndexOutOfBoundsException:" This is in direct conflict with an earlier statement "Velocity does not have of these same problems because it does not allow the author to place any Java code within a template". This means that comments about "Debugging an error like this often requires a programmer to look at the generated code to reconstruct what caused the error." also apply to Velocity. Putting myself in the shoes of "someone who has never written or seen a line of Java code", an IndexOutOfBoundsException is enigmatic. JavaBeans --------- * " the first thing that pops up right away is the use of the scope attribute " which is not needed in almost all cases in Struts. * "Above, we have a very simple example of using a bean in a page." You could at least use a Struts example here of using the bean:write tag * "On some servers (including Tomcat 3.2) if you have a bean with a scope of "session" or "application" and you change the bean class implementation, you may get a ClassCastException on a later request" What does Velocity do in these circumstances? The assumption here is that Velocity/Turbine doesn't allow reloading of classes when they change which is not very friendly for developers. Sample Application ------------------ * "This goes back to the statement that says that embedding Java code in your page is a bad thing. Yes, we all know that now." How about issues that are directly related to a template language? * parse ("header.vm") - What is this doing in a View component? * $toolbean.setToolsFile($application.getInitParameter("toolsFile")) - What is a view component doing reading a properties file? This snippet looks suspiciously like java code, without actually being java code. Why is java code like getInitParameter being embedded in a template? * What happened to the equivalent functionality being provided by the JSP - e.g. a custom error page? What sort of output is produced if toolsFile doesn't exist? Taglibs ------- * "This really falls into a preferences situation. In other words, which syntax would someone prefer to use?" What about familiarity for HTML developers/ non-Java developers as was declared in the section on Error Handling? * "#set ( $list = ["First", "Second", "Third", "Fourth", "Fifth"] )" is embedding template code into a page. This is as bad as embedding java code. * The sample application has been very simply rewritten in Struts. A tool and toolList tag would be far more appropriate. * "JSP and Struts into simply being a tool for creating only dynamic HTML code" This is simply false. What about producing XML, WML etc? Embedded Usage -------------- * No comment Implementation -------------- * Putting down JSP as a specwhen Velocity doesn't yet have one seems a bit rich. * "Velocity is actually a more reliable implementation than JSP because there is currently only one implementation" This says nothing to quality, adoption or choice. It is also a strawman as Velcity can't be a reliable implementation of a non-existent spec, and how can a single implementation be considered more 'reliable' than all other implementations of JSP? This is mere speculation. Hosting ------- * " and the entire server will suddenly become useless, " What is a 'server' in this context? A single machine? A single VM? This statement is making some basic assumptions which may not hold for various 'hosting' environments. * "Velocity does not have this issue because there is no while loop in the Velocity Template Language" but of course I'm free to provide my own via various extension methods, true? Conclusion ---------- * A very one sided and almost Struts-less comparison. -- dIon Gillard, Multitask Consulting Work: http://www.multitask.com.au NetRexx: http://www.multitask.com.au/NetRexx.nsf