FreeMarker 2.2 Released

Home

News: FreeMarker 2.2 Released

  1. FreeMarker 2.2 Released (27 messages)

    Greetings,

    I am pleased to announce the first release of FreeMarker 2.2 labelled production/stable. For those who don't know, FreeMarker is a well known, tried and true tool for doing page templates in Java -- i.e. including dynamic content in text output. In practice, it is mostly used in the web space to get data from Java servlets into HTML pages.
    The design goal is to separate the details of your presentation logic from the underlying application logic.

    FreeMarker 2.2 represents a major leap in terms of functionality. Probably the most important new feature is the namespace support. This makes FreeMarker a much more appropriate tool for very large-scale projects, since it allows different pages to share macros and variables without any fear of namespace conflicts.

    Macros have become much more powerful because they can be invoked with optional bodies. Also, macros are first-class variables now and can be passed to other macros. Macros and transforms (text filters defined on the java side) are now invoked via a unified syntax, so that, actually, despite FM 2.2 being so much more powerful, it is actually
    simpler and more coherent for people writing templates.

    Another extremely appealing feature introduced in FM 2.2 is that FreeMarker can make use of JSP taglibs written by third parties.

    For those of you looking for a tool to maintain a good model-view separation in web applications, you should really take a close look at FreeMarker. You can do all the same things with FreeMarker that you can do with better-known tools in this space, such as JSP, XSLT, or
    Velocity, but without the same headaches and annoying limitations that these other tools occasion.

    View new features in FreeMarker 2.2.

    For more information, see the FreeMarker site:

    http://freemarker.org

    or

    FreeMarker project page on Sourceforge

    Enjoy,

    Jonathan Revusky
    --
    Lead developer of FreeMarker
    http://freemarker.org/

    Threaded Messages (27)

  2. JSP x FreeMarker[ Go to top ]

    From the FAQ in freemarker.org:

    "JSP undertakes wider range of tasks by design, but because of this, it is not really suitable as an MVC view component."

    I would recommend you have a look at JSP. The upcoming JSP 2.0 will provide about the same ease of use as alternatives such as FreeMarker or Velocity. And there is no doubt in my mind that it is perfectly suitable as an MVC view component. The only thing you need to add to JSP 2.0, in order to have full MVC, is an input controller mechanism. For example, using Servlets to carry out user actions (such as in Struts), or better yet, plain old Java objects to which requests are delegated (by a JSP custom tag, or a Servlet 2.3 Filter).

    In my opinion, once JSP 2.0 is in widespread use, there will be very little, if any, incentive or need to use such non-standard alternatives.

    Rogerio
  3. JSP x FreeMarker[ Go to top ]

    The main feature of JSP 2.0 that I think you are refering to is the JSTL (which you can use now - don't have to wait for JSP 2.0). The JSTL is good, I have used it, but I think there are still a couple of reasons for FreeMarker, Velocity and others like it to live on. I have used Velocity so I can only specifical address it (my appologies to main poster ;-).

     - JSTL uses XML tags. XML, in my opinion, makes a crappy scripting language. If that were not that case we would probably all be using XSLT by now (but instead XSLT has proved to be horribly complicated). Doing simple things like if-then-elseif-end branches or dynamically setting attribute values are very clunky in XML, requiring cooperating tags and extra complexity. In some cases there are things you can not do. You can not have a tag inside a tag (inside the angle brackets I mean), that is not valid XML. This means you can not dynamically set a tag attribute if the tag has not been explicitly setup to work with cooperating 'param' type tags. In these cases (where cooperating tags have not been set up) you must escape out to JSP scriptlet code. Also with Velocity and FreeMarker there is just less typing because of the cleaner dedicated syntax

    JSTL:

    Hello
    <c:if test="${not empty user}">
      <c:out value="${user.firstname}/> <c:out value="${user.lastname}/>
    </c:if>
    <c:choose>
      <c:when test='${not empty user}'>
        Stuff here
      </c:when>
      <c:otherwise>
        other stuff here
      </c:otherwise>
    </c:choose>

    Velocity:

    Hello $!user.firstname $!user.lastname
    #if($user)
      Stuff here
    #else
      other stuff here
    #end

     - There is no mechanism in the JSTL to call methods on regular Java objects. You can only call 'get' methods. Velocity allows you to call any method and pass data to arguments to it, etc. I assume FreeMaker is similar.

    - The JSTL requires a JSP engine to run. There is no easy way (that I know of) to setup Ant to pre-generate HTML pages using JSTL, for example. Velocity and FreeMaker are lightweight template engines that you can embed in any application and there are a couple of projects setup for exactly the above scenario (Ant generated HTML/XML files).


    The JSTL is good, but overall the Velocity and FreeMarker are easier to use and more flexible and they will be around for a while longer yet in my opinion.
  4. <snip>

    >
    > - There is no mechanism in the JSTL to call methods on regular Java objects. You can only call 'get' methods. Velocity allows you to call any method and pass data to arguments to it, etc. I assume FreeMaker is similar.

    By default, FreeMarker is more restrictive, but it also allows you to expose objects via reflection in the same way. There are different levels of exposure you can configure, one of which is the full exposure you have in Velocity or Webmacro.

    >
    > - The JSTL requires a JSP engine to run. There is no easy way (that I know of) to setup Ant to pre-generate HTML pages using JSTL, for example. Velocity and FreeMaker are lightweight template engines that you can embed in any application and there are a couple of projects setup for exactly the above scenario (Ant generated HTML/XML files).
    >
    >
    > The JSTL is good, but overall the Velocity and FreeMarker are easier to use and more flexible and they will be around for a while longer yet in my opinion.

    Anick, thanks for the above examples and saving me the time in making the points you make so well.

    One additional point about FreeMarker (as opposed to Velocity/Webmacro) is that, as of FM 2.2, FreeMarker supports JSP taglibs. So, you can even use JSTL within FreeMarker! Of course, that would just be masochism, given the relatively clumsy syntax. But you could. The real attraction of the JSP taglib support is that there are now powerful 3rd party components like Cewolf and so on that are rolled up as JSP taglibs and you can use them just as well from FM as from JSP.

    In fact, one user who raved about a preview release of FM 2.2 said he was amazed that it was actually easier to use JSP taglibs from FM than from JSP!

    So, really, you get the best of both worlds with FM now. As far as I know, FM is the only template engine with this feature.

    You might be interested in this comparison with Velocity.
  5. \Revusky\
    One additional point about FreeMarker (as opposed to Velocity/Webmacro) is that, as of FM 2.2, FreeMarker supports JSP taglibs. So, you can even use JSTL within FreeMarker! Of course, that would just be masochism, given the relatively clumsy syntax. But you could. The real attraction of the JSP taglib support is that there are now powerful 3rd party components like Cewolf and so on that are rolled up as JSP taglibs and you can use them just as well from FM as from JSP.
    \Revusky\

    I think embedded in your reply above is one of the most attractive features of frameworks like FreeMarker, which hasn't been explicitly highlighted here yet: notational convenience. A visually clean and easy to understand syntax has a surprising effect on development time, hunting down bugs, and making enhancements. I've always found systems like JSTL onerous to use, because it's so hard to visually parse. I've gone as far as creating my own little macro template languages and purposely avoiding XML-like tag syntaxes because the XML tags always got in the way more than they helped (I didn't know about FreeMarker at the time).

    In all, I think frameworks like FreeMarker are very viable alternatives to JSPs (or can be very fruitfully combined with small JSP wrappers).

        -Mike
  6. Yes, JSTL will a part of JSP 2.0. Note however that the EL is directly supported in JSP 2.0, so you can just write ${user.firstname} instead of the more verbose <c:out value="${user.firstname}"/>.

    JSP 2.0 will use JSTL tags for loops and conditionals, which are certainly not as easy to type or read than with the FreeMarker/Velocity syntax. However, I think this is relativelly unimportant. The way I see it, if you are writing lots of if/elses in a page, then you are not properly using MVC. You can always move the boolean expression to a Java bean, and then use an appropriate JSP custom tag. For example, you could have something like the following, for selecting one of many alternative page fragments:

    <x:alternative id="1">
      content for alternative 1
    </x:alternative>
      ...
    <x:alternative id="n">
      content for alternative n
    </x:alternative>

    My point is that the need for such constructs does not arise that often in a typical web application. When it does, you have several ways of expressing them, some more readable than others, and even though the non-XML syntax is easier, it tends to encourage an excessive amount of application logic to be embedded in the web page. With JSP 1.2 and even more with JSP 2.0, it's possible to forbid the use of Java scriptlets in a page, and also limit the set of JSP tag libraries that can be used. There is no such thing with FreeMarker or Velocity.

    My impression from JSP 2.0 is that it provides (or tries to provide) more incentive for using MVC than the templating alternatives (even though no MVC framework is defined by JSP 2.0 itself, which is probably a good thing).

    And considering that tool support for JSP (such as Dreamweaver MX) is much more likely to be available to the developer and web content authors, the advantages of the simpler syntax in the templating alternatives are more than compensated for.
  7. Certainly, the appearance of JSP 2 will be the dead of Vel. and FM; I mean, the need for those tools will substantially decrease. But not because JSP 2 is superior to the other alternatives, but because it will become known very quickly, as it is "JSP", which is "standard", and it is under the umbrella of well known big IT companies, etc. The chance of alternative engines on the Web field was that JSP 1 is utterly bad for MVC.

    As of the Dreamweaver support, and other 3rd party tools... if a templating alternative becomes more popular, then there will be more and more third party support. But until there is no third party support, people do not want to use the alternative, so it will not become popular. This is such a deadlock.
  8. Well Vel and FM also offer other advantages which will not make them obsolete. You can use ANY input source for your template. It could be a webservice, database or anything you can get from an input stream. This is a very useful ability. This is not possible in JSP's because they must be compiled.
    Also, as one other poster has mentioned, I have actually found vel and fm to not only be on par with JSP's in performance, but often faster.
    Finally, vel and fm can be used outside the web environment, and it is very nice to use the same toolset for multiple applications when you become familiar with it.
  9. And even more, FM has this pluggable object wrapper facility, that enables you to expose any object in a simple, tailored way for templates, etc etc. So obviously they have the use cases, I did not meant to say that they have not. Just that people is such sheep, and... so if JSP 2 will not be very bad for their purposes (as MVC V), they will ignore the other alternatives.

    As of the performance, Is this really an important factor in an MVC system? Because, the templates are simple, so I can't believe that their rendering time is that significant among the resource consumption of other components, such as DB. Maybe some experts here will tell me that I'm mistaken.
  10. Yep, performance is usually not a significant factor of the presentation because your backend DB or whatever is going to be the bottleneck. However, if you are running a high volume site, your backend is going to be cached and the presentation will make a real difference in your hits/sec capacity. Its always a pleasant bonus if you are running a high volume site to not have to buy more servers :-)
    Anyway, the most important thing is that many people think template type frameworks are slow because they are not compiled, just want to help destroy that myth where I can.
    I am uncertain if JSP 2 will cause a great shift away from Vel or FM. You already have template frameworks for JSP's and still there are many who prefer vel and FM. After doing a lot of development in vel, I myself would never want to go back to JSP's even with the additions of JSP 2. However, FM ability to use taglibs may just be the edge it needs to continue on as a stronger alternative.
  11. JSP x FreeMarker[ Go to top ]

    I have a limited knowledge of these MVC frameworks.

    But what about TILES and STRUTS... isnt enough ? I've made some things with it. And its really powerful.
  12. JSP x FreeMarker[ Go to top ]

    I have a limited knowledge of these MVC frameworks.

    >
    > But what about TILES and STRUTS... isnt enough ? I've made some things with it. And its really powerful.

    Sure they are great too, but they are still not as easy as Velocity / FreeMarker, especially when it comes to loops and branching type operations. Also Struts is moving towards use the JSTL (the only thing left is the html tags for forms handling)

    "Note: - Many of the features in this taglib are also available in the JavaServer Pages Standard Tag Library (JSTL). The Struts team encourages the use of the standard tags over the Struts specific tags when possible."

    So Struts is now basically just a controller now. The JSTL is XML tags and you have all the associated XML difficulties that I mentioned in a previous post. Does it all work? Of course. It's all good. But if you really want to seperate front-end development (i.e. HTML and such) from back-end development (i.e. database access and stuff) then you need a template language that is simple enough for HTML authors to use and that is sufficiently 'decoupled' from the backend to allow parrallel development. Struts and JSTL does not quite accomplish this in my opinion, but if the people doing the HTML and Java are the same people (smaller projects, etc) then it doesn't really matter.
  13. Struts can use Velocity[ Go to top ]

    Just to clarify, you can use velocity as your presentation technology with Struts. Struts really is presentation technology agnostic, even though most people use JSP with it.
  14. Struts can use FreeMarker[ Go to top ]

    See here for details on how to use FreeMarker with Struts.

    There is also a full example in the distro. Another point worth noting is that, unlike Velocity, FM can make use of third-party JSP taglibs, so you really don't sacrifice any possibilities, as you would opting for Vel over JSP in the same context.

    In general, FreeMarker is much more powerful than Vel. See here for a comparison. Also, it subsumes JSP taglib functionality, so, in my not-so-unbiased opinion, it is well worth looking at.
  15. Struts can use FreeMarker[ Go to top ]

    In general, FreeMarker is much more powerful than Velocity.


    What do you mean about this? Do you mean that Freemarker has a far more features built in compared to Velocity? Or do you mean that Freemarker is faster than Velocity? I have thought this a little bit and I have not found a single thing that you cannot do with Velocity that you can do with Freemarker. Of course with Velocity you have to build your "utility tools" and custom macros to get the same features that are built in Freemarker. Personally I like simplicity more, and that is what Velocity provides to me.
  16. Struts can use FreeMarker[ Go to top ]

    In general, FreeMarker is much more powerful than Velocity.

    >
    > What do you mean about this? Do you mean that Freemarker has a far more features built in compared to Velocity? Or do you mean that Freemarker is faster than Velocity?

    I meant the former. Speed is probably about comparable.

    > I have thought this a little bit and I have not found a single thing that you cannot do with Velocity that you can do with Freemarker.

    Well, I posted a link to a comparison that explains most of the capabilities that FreeMarker has that Vel lacks.

    Here is a (probably incomplete) rundown:

    FreeMarker (as of version 2.2) can use 3rd party JSP taglibs. No competing template engine currently offers this, as far as I know. See here for more details.

    FreeMarker has directives for fine control of whitespace. (Something that is complained of constantly on the Vel lists.) See here for more details.

    FreeMarker has support for decimal number literals and arithmetic operations on integers and decimal numbers( velocity only supports integers.) Also, you can maintain separate templates for different languages/locales and the number formatting (2.3 vs. 2,3) happens correctly and transparently depending on the locale. You can also override the number_format setting for different parts of your template, so as to display scientific notation or whatever number format you want for the numbers in that part of the template. See here for more details.

    You can define variables and macros in separate name-spaces so that different people can work on different pieces without any possibility of naming clashes. See here for more details.

    You can define transforms (or filters) that that arbitrary blocks of template output can be passed through. See here for more details.

    FreeMarker macros are much more powerful. Macros can forward reference other macros. Macros can contain local variables, thus avoiding naming clashes with possible variable names outside the macro. FreeMarker macros can have default parameters. There is also the possibility of associating a template block with a macro invocation. See here for more details.

    FreeMarker interoperates very cleanly with Jython. See here for more details.

    >Of course with Velocity you have to build your "utility tools" and custom macros to get the same features that are built in Freemarker.

    Frankly, I do not believe that this makes your life more simple. An underpowered tool makes your life more complicated because you are constantly re-inventing the wheel. OTOH, if you use the subset of functionality that Velocity offers from within FreeMarker, life is just as simple. But your project will not so easily outgrow FreeMarker as Velocity.

    > Personally I like simplicity more, and that is what Velocity provides to me.

    Well, regarding this, here is a direct quote from our comparison page that addresses the above argument:

    "However, we think that for most applications, working with FreeMarker is simpler than working with Velocity, since with Velocity you have to find custom tools and find various other workarounds to solve typical template authoring tasks again and again, and you end up losing much more time in the long run than you have won on the quick starting. Also, the result of solving something with tools and workarounds is most probably not that terse and efficient than the solution in the engine core. Furthermore, according to Velocity list archives, the workaround often means extensive direct usage of Java object methods in the Velocity template (this violates the idea of simple, non-programmer HTML-designer friendly templates) or the movement of presentation tasks into the controller code (this violates the MVC idea). And, after all, if you use FreeMarker only for what Velocity can do out-of-the-box, it is as simple as Velocity."

    I hope the above goes some way to clear up what I meant in the previous post. Thank you for providing me the opportunity to explain in more detail.
  17. Here is how you do things you mentioned in Velocity:

    > FreeMarker (as of version 2.2) can
    > use 3rd party JSP taglibs. No competing
    > template engine currently offers this,
    > as far as I know.

    You can always write JSP tag tag has other templating technology as a content.

    > FreeMarker has directives for fine control
    > of whitespace.

    1. Write a tool
    2. Write a macro that uses the tool
    3. Use the macro

    > FreeMarker has support for decimal number
    > literals and arithmetic operations on integers
    > and decimal numbers...

    Look at previous answer.

    > You can define variables and macros in separate
    > name-spaces so that different people can work
    > on different pieces without any possibility of
    > naming clashes.

    That sounds great, but namespaces seems to be difficult to understand for many people (not for me thought :-)). In velocity you maybe need to use some naming convention.

    > You can define transforms (or filters) that
    > that arbitrary blocks of template output can
    > be passed through.

    I'm not sure what this means, but maybe you can do the same with Velocity macro.

    > FreeMarker macros are much more powerful...

    Yes, they seem more and more like a scripting language. In velocity your macros can be as limited as a Java language (just write a simple class and use it from the macro -> everything you can do with Java, you can call it from Velocity).

    > FreeMarker interoperates very cleanly with Jython.

    Don't know about that, but I trust that your statement is correct because there is no special support fot Jython in Velocity.

    > I do not believe that this makes your
    > life more simple

    I didn't say that it makes my life simpler. I only said that the approach is clean and simple. I see a problem with these feature rich templating languages. They grow and grow, and finally they are just like any other scripting language. Many times this leads to a situation where you are trying to do most of your work with the templating language, and try to find a ways to workaround the limitations - write a hack here and there. Velocity has very limited feature set (maybe there should be map and some white space gobbling support included directly in the core). You already know that velocity provides you just the basic. When you need something more advanced features (e.g. number format support) you already know that it is not supported in Velocity that means that you have to write that in Java. Then you can write a macro and say to designer that he/she can use that. This also decouples the number format implementation from templating language that is IMHO good. You can change the implementation any time (that is not a case when you use Freemarkers numberformatting that is build in core of Freemarker). Maybe this was not a good example, but I'l think that you'd get the idea.

    > But your project will not so easily
    > outgrow FreeMarker as Velocity.

    How can my project overgrow Velocity if I can use Java to do the things that are not builtin Velocity?

    > I hope the above goes some way to clear up what
    > I meant in the previous post.

    Thanks. The response was clear and well argumented. I know that there is a place for tools like Freemarker and that everything you can do in Velocity you can do in Freemarker. But I also think that there is a place for tools like Velocity and I still think that everything you can do with Freemarker, you can do with Velocity+POJOs too.

    You also talk about reinventing a wheel. The features e.g. white space handling and number formatting support (with locale support) are implemented in many many projects and tools already. That means that you have also reinvented that in Freemarker. These tools are also very simple to build, so it does not make my life that much harder if I reinvent them. And maybe you need to reinvent them with Freemarker too, if you are not happy with Freemarker's implementation.

    > Thank you

    Thank you too.
  18. I see a problem with these feature rich templating languages. They grow and grow, and finally they are just like any other scripting language.

    I'm a big fan of Freemarker because it was a simple and neat template engine without any dependencies. We use Freemarker 1.7 for all sort of HTML, Java code, email generation. However, since 2.0, Freemarker really seems to grow and to loose its simplicity (which was one reason why we choose it).

    -- Andreas
  19. Simplicity?[ Go to top ]

    I do not understand the reasoning like this. If you use only the same features of FM 2.2 that was already present in 1.7, then the templates will remain as simple as before. In general, just because something is powerful, does not means that you *have* to use all fancy features of it. Use just what you need. Well, OK, if somebody has to read the Designer's Guide, then it is longer... but, almost all fancy things (such as name-spaces or user defined directives) are described in the Miscellaneous chapter, and you have to read a section there only if that is interesting for you. The "obligatory" part of 2.2 Manual is not that more complicated than the Manual of 1.7 would be (but there was no complete documentation for 1.7, so it is not possible to really compare them...).
  20. I see a problem with these feature rich templating languages. They grow and grow, and finally they are just like any other scripting language.

    >
    > I'm a big fan of Freemarker because it was a simple and neat template engine without any dependencies. We use Freemarker 1.7 for all sort of HTML, Java code, email generation. However, since 2.0, Freemarker really seems to grow and to loose its simplicity (which was one reason why we choose it).

    Well, actually, I would say that FM >2.1 is easier to use for beginners than FM 1.x was. The reason is that you can use standard java.util containers such as HashMap and ArrayList directly. In FM 1.x, you had to be aware of things like SimpleHash and TemplateHashModel and TemplateListModel and so on.

    Now, OTOH, FM 1.x had some terrible limitations. I mean, consider the lack of any kind of numerical support, not even integers. It is very very hard to do certain kinds of complex layouts without integer arithmetic. And of course, the lack of support for decimal numbers made all kinds of things in typical e-commerce apps unnecessarily difficult. (As is still the case with Velocity.)

    It's okay if you have no need for those things, and it is also true that there were various workarounds for the lack of those features, but really, the advantages of simplicity can easily be oversold. As Einstein said, things should be as simple as possible, but no simpler.




    >
    > -- Andreas
  21. You said that FM seem more and more like a scripting language... well, that true. However, the question comes if how much should we try to prevent people to shoot themselves on foot. FreeMarker provides convenient syntax and semantic to write terse templates (such as ${var} <#list foos as foo>...</#list>), and in this sense, it is a template language. Because, it is convenient for writing clean MVC templates. Also, it has features that are rather the typical of scripting languages. But there are cases where you are right to use them, say, I don't think that just because I want a damn-poor local variable in a macro, I follow bad practice. But, of course, this holds the danger that one can use this "scripting power" badly. So, for me, the real question is: how to handle human stupidity :), or should we chain up people who knows what he does, only because some other people have bend for suicide?

  22. > > FreeMarker (as of version 2.2) can
    > > use 3rd party JSP taglibs. No competing
    > > template engine currently offers this,
    > > as far as I know.
    >
    > You can always write JSP tag tag has other templating technology as a content.
    >

    While we have that too, it's not what we emphasize when talking about JSP taglib integration, rather that you can do it other way round. We emphasize the fact that you can invoke any 3rd party JSP custom tag from a FreeMarker template.

    (BTW, due to FreeMarker's highly flexible data model paradigm, this was implemented as a cleanly separated module - a custom data model - with no changes required to the engine core).
  23. You can define variables and macros in separate

    > > name-spaces so that different people can work
    > > on different pieces without any possibility of
    > > naming clashes.
    >
    > That sounds great, but namespaces seems to be difficult to understand for many people (not for me thought :-)). In velocity you maybe need to use some naming convention.

    The reason we introduced the namespace feature is that we wanted to make it feasible for people to share macro libraries that do common, useful things. If you reuse a macro library that was written for another project, how do you make sure it follows your naming convention? There is no easy answer, and that's why namespaces are an important feature for large-scale projects.

    >
    > > You can define transforms (or filters) that
    > > that arbitrary blocks of template output can
    > > be passed through.
    >
    > I'm not sure what this means, but maybe you can do the same with Velocity macro.

    I think this is a feature that Velocity simply does not have. See here for a description of transforms (aka filters) in FM.

    > > But your project will not so easily
    > > outgrow FreeMarker as Velocity.
    >
    > How can my project overgrow Velocity if I can use Java to do the things that are not builtin Velocity?

    Well, maybe you can use Java to compensate for things that are missing in the template language, but the whole raison d'être of these template languages is a division of labor. The person who works on a template is not supposed to be a java programmer. And certainly, some of the things we are talking about, for example, formatting decimal numbers, are clearly presentation-side issues that the person in charge of the template should be able to control. Without calling upon the java programmers on the team for help.

    So, I reiterate that FreeMarker is a more powerful tool than Velocity. It gives the programmer more power (see things like the transforms) and it gives the person editing the templates more power, such as the ability to control number formatting built-in and things like that. These are things that we know, from end-user feedback, are really needed in real-world apps out there.
  24. Could be simpler[ Go to top ]

    Thank you. But two things do not look good for me.
    1. <$xxx$> tags are not WYSIWYG html editor friendly.
    2. Handle the tags at run-time brings performance penalty.

    I recommand to introduce something like
    <!--*<c:out="user.username">*--> to make the templates editable in Dreamweaver or FrontPage. Then use a super simple program to remove <!--* and *--> before put into action. No run-time translation needed at all.
  25. Could be simpler[ Go to top ]

    Thank you. But two things do not look good for me.

    > 1. <$xxx$> tags are not WYSIWYG html editor friendly.

    I think it depends on the editor. I'm not an expert on Dreamweaver or other WYSIWYG HTML editors, but you should be able to configure them to ignore tags with that specific pattern. It's not essentially any different from the <%...%> typical in other sorts of things.


    > 2. Handle the tags at run-time brings performance penalty.

    FreeMarker compiles the template into a tree and caches and reuses the compiled template. FreeMarker is really quite fast in practice. I can assure you that performance is basically not a problem for typical web apps. JSP is compiled down to bytecode, so it's faster, but only a little bit faster in practice.





    >
    > I recommand to introduce something like
    > <!--*<c:out="user.username">*--> to make the templates editable in Dreamweaver or FrontPage. Then use a super simple program to remove <!--* and *--> before put into action. No run-time translation needed at all.
  26. Velocity vs. JSP[ Go to top ]

    I have implemented the same dynamic pages with Velocity and Struts Taglib and tested performance: Velocity was approximately 30% faster than JSP. (Of course time to compile JSP was subtracted, so the comparison was between Velocity(no cashe) and compiled JSP)
  27. Another template option.[ Go to top ]

    I've mentioned this before but... most templating systems don't match the 'normal' workflow for building sites. Usually a static mockup is built, then static html, then its converted to dynamic content. Most templating languages (with the conspicuous exception of XMLC) require you to alter or discard the static html in order to get to a dynamic site. To maintain the site, we require the html designers to become skilled in some template language or other, often with no visual tool support.

    In our shop, we decided against this course. The html designers were working with Dreamweaver templates already, its criminal to throw away this work to use eg struts tiles. Instead we wrote our own templating engine which understands the .dwt, .lbi files directly, and use the static html as the template for the dynamic site. We use a tiles-like tag library to base JSPs on the htm files.

    The upshot is, the html designers can WYSIWYG-create the site in DW, we keep these artifacts, add some more for the dynamic content, and the html designer can /still/ WYSIWYG-edit the site.

    Freemarker is good at what it does (and clearly what I'm describing isnt a generic templating solution like FM), I'm just pointing out that there is an alternative to writing the perfect template language and waiting for tool support to appear - design your template engine so that its already supported by your toolset.

    -Baz
  28. As far I am concerned, no framework separates the view like Barracuda. Ufortunately development stagnated and it hasn't realized its potential but it seems to be coming back at a new location,http://barracudamvc.org/Barracuda/index.html.