Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Java Software Programming Apache

Velocity 1.4 Released 29

JohnA writes "After what seemed to be a 30 year beta period, the Apache Jakarta team has made available the final release version of Velocity 1.4. If you're not familiar with Velocity, it's one of the most powerful and popular templating engines around. And, as an added bonus, a DreamWeaver plugin was also released."
This discussion has been archived. No new comments can be posted.

Velocity 1.4 Released

Comments Filter:
  • by JPelzer ( 202626 ) * on Thursday April 15, 2004 @10:50AM (#8869064)
    Now we can finally start another Jakarta templating project that does almost exactly the same thing, but not quite, but our description of the project will claim our version is superior, with a name that has nothing to do with what the project does. How about "Project Platypus" ?

    Project Platypus Overview:
    "Similar to Velocity, but with some important differences: Mainly, we've added several reptilian characteristics which include using the same opening for reproduction and eliminating waste products, the ability to lay eggs, cervical ribs, and local ascorbic acid synthesis in the kidney. Also, Project Platypus can swim."
    • Re:About time... (Score:3, Interesting)

      by mhesseltine ( 541806 )

      Not trolling here: if Velocity is, as you say,

      "another Jakarta templating project that does almost exactly the same thing, but not quite, but our description of the project will claim our version is superior, with a name that has nothing to do with what the project does."

      Does that imply that there is a "standard" or in your opinion better templating project in the Jakarta project?

      I've been interested in learning Java/JSP/etc. and would love to hear your recommendation on a good engine to study.

      • Tapestry
      • Re:About time... (Score:4, Informative)

        by iroberts ( 672505 ) on Thursday April 15, 2004 @02:32PM (#8872571) Journal
        I would recommend Jamon [jamon.org], which is for Java what HTML::Mason [masonhq.com] is for Perl. Rather than "throwing variables over a wall" from java code to templates via a context object (basically a hash map), templates declare themselves to expect certain arguments, which are passed to them from Java code. For example, HelloWorld.jamon might contain:
        <%args>
        String name;
        </%args>
        Hello <% name %>!
        This would be called from java as
        new HelloWorld().render(System.out, "Taco");
        Any java types can be passed to a template (primatives and objects). Templates can both inherit from and call other templates. Everything is staticly type-checked at compile time. Automatic template recompilation is supported during development, and in production, no reflection is used.
      • You should definitely at least learn JSP first. For all its faults, it's still the standard templating mechanism for J2EE, and you can't really call yourself a Java web developer if you don't know it.

        Once you learn it and loathe it, then you can move on to others.

        I personally think GroovyPages [codehaus.org] looks like it could be a much better solution than anything else I've seen in the Java world. But then I like having the option to write powerful code in the presentation layer, while the whole point of Velocity i
  • Why? (Score:4, Insightful)

    by forsetti ( 158019 ) on Thursday April 15, 2004 @11:07AM (#8869360)
    Why do we need an alternative to JSP, that also works in a Java environment? I understand the use of JSP as an alternative to PHP or ASP (3 different platforms), but I don't understand why I need two solutions to (seemingly) the same problem on the same platform. Could someone enlighten me?

    • Re:Why? (Score:5, Informative)

      by HawkingMattress ( 588824 ) on Thursday April 15, 2004 @11:51AM (#8870048)
      Because JSP sucks.
      It is hard to debug, and encourages bad practices like putting some java code directly into the JSP, which then becomes a logic and presentation layer instead of just presentation. JSP is the thing you'd want to create a quick and dirty app, but it's sadly an enterprise standard. Now you can try to force everyone to use it as a sole presentation layer, but in many cases, it's very tempting to juste add a little scriplet, because it gets the job done. Then one day you realize your CMS or whatever has become very hard to maintain because there is logic everywhere and you have to recode the whole thing to keep the maintenance costs low.
      The problem is, that's exactly the type of problem that J2EE is supposed to address, but JSP makes it hard because it's too easy to shoot yourself in the foot.
    • Re:Why? (Score:5, Informative)

      by aminorex ( 141494 ) on Thursday April 15, 2004 @12:38PM (#8870809) Homepage Journal
      JSP is horrible because it is designed to produce badly designed code. Bad design, by design. You see, in JSP the crucial, central aspects of presentation and business logic tend to become increasingly intertwined, because there is Java code
      implementing business logic intertwingled with your presentation HTML, and vice versa contrariwise.
      This is not a happy peanut butter cup land.

      PHP and ASP have the same problem. PHP is actually even worse, because, although there are template engines for PHP, they lead to spaghetti objects, where a single aspect is smeared over umpty-booty-teen different class files. Good luck maintaining that when the project grows past 10kloc! (I won't even BEGIN to address the death-march misery that is ASP.NET.)

      Struts, Velocity, and JSF together make a beautiful system, in which the classic MVC patterns apply, aspects are colocated, and presentation is sharply segrated from business logic. Now that, my friend, is a real step ahead of the competition. Websphere is the only commercial environment that really supports this stuff right now, although I expect WebLogic to catch up soon. The Dreamweaver support is velly intelesting to me as well.

      It's a good time to be alive.
      • I think Tapestry (now adopted by jakarta too) is a better replacement for JSP. It's a lot easier to use than Struts, requires less configuration, has a nice plugin for Eclipse (spindle), and has a very elegant design, that allows for a lot of extensibility and reuse while keeping presentation separate from logic. The only drawback, really, is that's it not JSP and some people have a problem with that. Struts as I see it is a patch on top of JSP. JSF, JDO, and some other initiatives by Sun are just attempts
        • by Anonymous Coward
          JSP with Struts looks a lot like HTML. That's a big advantage. Give it to a web guy, and tell him to use instead of , etc., and he can do the view work for you while you focus on model and controller.
          • Well, Tapestry looks EXACTLY like HTML. You don't really use any special tags (forget about <%tags%> and <jsp:whatever> and such), you just use a special attribute in the tags you want to process as Tapestry objects, for example you can do <a jwcid="@PageLink" page="SomePage">this</a> for a page link.
            You can easily write your own components and have them contain other components, etc. It's really versatile and powerful. You can also get the html from a web guy, add the jwcid attribut
      • Re:Why? (Score:2, Informative)

        PHP is actually even worse, because, although there are template engines for PHP, they lead to spaghetti objects

        Smarty [php.net], the most popular PHP template engine, is actually very similar to Velocity. Velocity has a more pleasant syntax, while Smarty has more features (esp. caching). One is certainly a knock-off of the other. I don't know which was first, though.

      • JSP is not *designed* to produce crappy code, even if a lot of people produce crappy code with it. Hell, the same goes for PHP, although the latter's genesis as an HTML-embedded language does, I believe, expose it to that sort of charge.

        There are reasons for servlet forwarding and tag libraries; they let you do the heavy lifting in servlets and tag handlers, and just handle display in JSPs.

        I say this as the author of several JSPs (some deployed in production on reasonably high-profile sites) with buttlo
      • Re:Why? (Score:3, Informative)

        by wglass ( 471248 )
        A big advantage of Velocity is that it combines a flexible templating language with ease of integration into existing applications and frameworks. Because of this, a lot of java-based web frameworks include Velocity support. Struts, WebWork, Turbine, Maverick, Spring, to name a few. Using Velocity it's also possible to roll your own web markup language with Velocity as a base, as the folks on the Roller [rollerweblogger.org] team have done.

        In addition, Velocity is more than just a web scripting language. (as opposed to JSP
      • You see, in JSP the crucial, central aspects of presentation and business logic tend to become increasingly intertwined, because there is Java code
        implementing business logic intertwingled with your presentation HTML, and vice versa contrariwise.


        I'll admit my exposure to JSP is limited, but this isn't a problem I had with it when using it.

        You just need to think about your application design before sitting down and coding it.

        Separation of presentation and logic is simple to achieve using standard practis
      • I've spent most of the past 5 years doing Java-based web development. I fully agree that PHP is a nightmare compared to (insert favorite combination of Java frameworks and toolkits here).

        However, I think ASP.NET is better. It's a huge shift from ASP; you could say ASP to ASP.NET is like PHP to JSF. (In fact, I believe JSF was created entirely as a response to ASP.NET, though they didn't do nearly as nice a job.) ASP was (iirc) a fully interpreted HTML embedded language. ASP.NET pages are precompiled

      • ...intertwingled...

        ...vice versa contrariwise.

        ...happy peanut butter cup land.

        ...spaghetti objects...

        ...umpty-booty-teen...

        ...10kloc!

        ...death-march misery...

        There has got to be some creative language usage award I can nominate you for, and if not, I move that we create one...

    • Re:Why? (Score:2, Informative)

      by Anonymous Coward
      It's handy for things that aren't going to be webpages too. I use it for templated SQL queries, XML documents and so on.
    • Re:Why? (Score:3, Interesting)

      by mmcshane ( 155414 )
      The most important difference for me is that Velocity is not tied to server side servlet processing. JSP templates cannot be used outside of a servlet container (they are in fact compiled into servlets at runtime) however Velocity templates can be used in any context. I personally have used Velocity to do source code generation and offline report generation.
    • Re:Why? (Score:2, Informative)

      by mrtom852 ( 754157 )

      One of it's advantages is that it can be used outside of a JSP server - so normal applications can use it as a light weight template engine.

      Personally I don't like Velocity, but I think it's because I'm in a very XML based environment. As a web presentation layer I use JSTL/taglib and avoid the old school JSP code 'tags'. This way it's closer to XML but I still wish the spec made it fully XML compliant.

      When JSPs don't make sense I will always use XSL because the templates can be run on any platform.

  • by osewa77 ( 603622 ) <naijasms@NOspaM.gmail.com> on Saturday April 17, 2004 @04:42PM (#8893492) Homepage
    Is that, unlike technologies like JSP, Velocity works simply as a component, a module, which you can adapt for various purposes in your application. I don't believe in frameworks, I believe in modules which have their source code available.
    - A Small-time Nigerian Weblog Publisher [afriguru.com]
  • by MCRocker ( 461060 ) on Saturday April 17, 2004 @06:47PM (#8894181) Homepage
    WebMacro [webmacro.org] has moved into the beta phase of release 2.0!

    WebMacro is the original templating engine that velocity is based on. Unfortunately, due to licensing issues, they were never able to merge and have now diverged enough that they are now quite different despite the base similarities.

    Version 2.0b1 of WebMacro has new and exciting features as well as efficiency gains. One of the most interesting new features is actually a result of the improvements in Java technology itself. The older versions had a lot of factories and contexts in order to get around the inefficiencies of object creation and clean-up, but now, much of this has been removed or hidden because of improvments in Java garbage collection has made them supurflous.

What is research but a blind date with knowledge? -- Will Harvey

Working...