FreeMarker as an alternative to XSLT

Discussions

News: FreeMarker as an alternative to XSLT

  1. FreeMarker as an alternative to XSLT (31 messages)

    FreeMarker is a 100% java library of some vintage. It was originally designed for the java servlet space, to keep presentation logic (HTML stuff) separate from the back-end application logic. However, it is a very useful tool for any application that needs to generate text. Other well-known tools in this space are Velocity and WebMacro.

    FreeMarker 2.3 introduces some powerful new XML processing functionality that should make it an appealing alternative to XSLT for many people. We have introduced some new directives -- <#visit> and <#recurse> -- that provide functionality roughly equivalent to the <xsl:apply-templates/> functionality.

    We believe that FreeMarker will be a lot easier for most people to learn and use than XSLT. The basic programming language available in FreeMarker templates is much more readable (less verbose) than XSLT and the underlying procedural logic will come more naturally to most people than the declarative/functional programming model embodied by XSLT.

    We don't have rigorous benchmarks ('rigorous benchmarks' may be an oxymoron anyway) but initial indications are that FreeMarker is a lot faster than XSLT. And I mean a lot faster. For example, FreeMarker's manual is maintained in a canonical Docbook XML format. Previously, we generated the final HTML output using using some XSLT stylesheets by Norman Walsh. The XSLT transformation was rewritten in FreeMarker, and runs 15x faster than the previous XSLT-based system using Saxon. Also, the FreeMarker templates are less verbose and seem more maintainable than the XSLT stuff was. You can see the FM-generated FM manual here.

    Though the latest version is still labelled a preview, the codebase is really quite solid at this point. The main reason for the preview label is that we are still more open at this stage to changes and proposals than we would be if this were labeled release candidate or final. We are *very* interested in feedback from hard-core XML and XSLT type people. This is your chance to have some input into how an XML transformation tool should work. (I suppose most of you never got any input into how XSLT works. :-))

    Best Regards,

    Jonathan Revusky
    --
    lead developer, FreeMarker project
    XML transformation with FreeMarker

    Threaded Messages (31)

  2. I looked at the how-to the other day. The title "FreeMarker as an alternative to XSLT" made me bite (BTW, I saw the link on another site). Why? Because having done enough xslt, I'v realized that anything would be better and I am looking for it. At first glance - Very cool and MUCH more readable than XSLT.
  3. FreeMarker as an alternative to XSLT[ Go to top ]

    I think this FreeMarker feature and other similiar technologies are trying to fill a gap left by XSLT for those that need simplier XML transformations than what XSLT provides. Many people just need to take XML, pull out what they need, and combine it with static text. XSLT provides more complicated features like sorting, combinable templates with priorities, etc. that I think are necessary to make it a more complete XML transformation technology.

    The problem is not everyone needs that level of sophistication and the computational costs that come with it. Web pages that use XML, for example, who have static text and need to insert values from an XML document should use something like FreeMarker or Anakia (Velocity XML extensions) which is more suited to simple XML access and transformations.
  4. So you can't say that "FreeMarker is a lot faster than XSLT" (quoted verbatim from your message). I would much prefer if you showed theoretical arguments as to why XSLT cannot be implemented as efficiently as your own template language (after all the XSLT world is not limited to Saxon or Xalan, everybody is allowed to implement XSLT, which has been a W3C Recommendation since 1999).
  5. So you can't say that "FreeMarker is a lot faster than XSLT" (quoted verbatim from your message). I would much prefer if you showed theoretical arguments as to why XSLT cannot be implemented as efficiently as your own template language (after all the XSLT world is not limited to Saxon or Xalan, everybody is allowed to implement XSLT, which has been a W3C Recommendation since 1999).

    Totally. Has that dude ever heard of Sun/Apache's XSLTC?
  6. So you can't say that "FreeMarker is a lot faster than XSLT" (quoted verbatim from your message).


    I wrote those words, but you are quoting a sentence fragment. Here is the complete sentence I wrote:

    <em>We don't have rigorous benchmarks ('rigorous benchmarks' may be an oxymoron anyway) but initial indications are that FreeMarker is a lot faster than XSLT.</em>

    I then went on to say that our basis for believing this was that we ported our manual generation that was previously using the Norman Walsh XDocbook stylesheets to using FreeMarker and we had a 15x speedup.

    I recognize that one's mileage may vary and that this may not be indicative. I also recognize that there are alternative XSLT implementations that may be faster. Basically, my initial post was advocacy material to try to get people's interest, but I still try not to say things that are too outrageous. :-)

    Frankly, I doubt that any alternative XSLT implementation would run that trnasformation 15 times (!) faster than Saxon. Even if Xalan or some other XSLT processor is 2 or 3 times faster than Saxon, say... we're still a lot faster. So, at least for this specific task, I think it's probably safe to say that FreeMarker is a lot faster.

    >I would much prefer if you showed theoretical arguments as to why XSLT cannot be implemented as efficiently as your own template language (after all the XSLT world is not limited to Saxon or Xalan, everybody is allowed to implement XSLT, which has been a W3C Recommendation since 1999).

    Well, I'm a practitioner in the field, not a theoretician, Eric. It does me no good if the popular XSLT specifications are dog-slow, yet it is theoretically possible to write far faster ones. As a practical matter, the current state of the art of XSLT implementations is what counts. And, as I say, our initial results strongly suggests that FreeMarker is a lot faster than XSLT, as currently implemented. I would be very interested in whatever other benchmarks people could eventually provide.

    Thanks,

    Jonathan Revusky
    --
    lead developer, FreeMarker project
    XML transformation with FreeMarker
  7. FreeMarker as an alternative to XSLT[ Go to top ]

    I am looking at alternatives to XSLT right now, so this is good to know about.

    What do you see principally differentiating FreeMarker's approach to XML transformation from Velocity's DVSL (Declarative Velocity Style Language)?

    The two look like similar approaches, though I don't know how much effort is going into DVSL at this point.

    Jay Fienberg
    the iCite net
  8. Velocity as an alternative to XSLT[ Go to top ]

    Looks like Velocity has recent activity. Last release on 1 Apr 2003 version 1.3.1
  9. Looks like Velocity has recent activity. Last release on 1 Apr 2003 version 1.3.1


    This is deceptive. Actually, there is a public record of CVS commits on the velocity-dev mailing list and you can examine this and see that the core Velocity project has, to all intents and purposes, had no developer activity in about a year.

    The 1.3.1final release they put out was essentially identical to the 1.3.1rc2 release of last July.

    Over this period, FreeMarker has gone through 3 major release cycles, 2.0, 2.1, 2.2, and is now in the 2.3 cycle. We've added and continue to add a lot of interesting features. Meanwhile, over the same time period, Velocity has been, to all intents and purposes, a dead project.

    Regards,

    Jonathan Revusky
    --
    lead developer, FreeMarker project
    FreeMarker-Velocity comparison page
  10. Velocity project has, to all intents and purposes,

    > had no developer activity in about a year.
    >
    > Over this period, FreeMarker has gone through 3
    > major release cycles, 2.0, 2.1, 2.2, and is now
    > in the 2.3 cycle. We've added and continue to add
    > a lot of interesting features.

    Yep, but the whole point is not there. Maybe Velocity has managed to reach it's main goal (simple, small, and effective templating language)? Meanwhile Freemarker CVS has been broken several times and the last thread on Freemarker developers list talks about your attitude. Also you have managed to get many "friends" from Velocity list. Is there anyone who still takes you seriously?

    Freemarker's main developers are now talking about:

    "I'm not talking about the usage of CVS. I'm talking about chaotic evolution of FM. It's not planned enough." -- Daniel Dekany
  11. Velocity project has, to all intents and purposes,

    > > had no developer activity in about a year.
    > >
    > > Over this period, FreeMarker has gone through 3
    > > major release cycles, 2.0, 2.1, 2.2, and is now
    > > in the 2.3 cycle. We've added and continue to add
    > > a lot of interesting features.
    >
    > Yep, but the whole point is not there. Maybe Velocity has managed to reach it's main goal (simple, small, and effective templating language)?

    That's definitely an overly generous interpretation. Velocity is basically an abandoned project at this point. It is not just that they are conservative about adding features in the desire to keep things simple; that would be justifiable in the terms you state. It is simply that there is no developer activity of any sort -- no bug-fixes, no CVS commit activity in a year.

    >Meanwhile Freemarker CVS has been broken several times and the last thread on Freemarker developers list talks about your attitude.

    Oh, the stuff about me being rather sloppy at sysadmin stuff and often screwing up in CVS??? Yeah, there was some ribbing of me about this stuff recently, that's true. But so what?? People screwing up at CVS and other assorted sysadmin type stuff is very commonplace on open-source projects. (And non-open-source too, come to think of it.) There's nothing very significant about that.

    Of course, there have not been similar screw-ups in CVS in Velocity, at least not for a good while. But this is simply because there has been no developer activity. The only absolutely guaranteed way of not screwing up is simply to do nothing. And that is hardly any great achievement.

    > Also you have managed to get many "friends" from Velocity list. Is there anyone who still takes you seriously?

    Could you clarify what you mean by this? I don't get what you're saying. Do you have any technically relevant point or is this (as I suspect) just some kind of incoherent ad-hominem attack?

    >
    > Freemarker's main developers are now talking about:
    >
    > "I'm not talking about the usage of CVS. I'm talking about chaotic evolution of FM. It's not planned enough." -- Daniel Dekany

    <sigh>

    First of all, Daniel would say similar things in any project he would be involved with. And he would probably be right in each case. It is typical that open-source projects evolve in a somewhat chaotic manner. None of this, however, provides any argument that justifies the abandoned state of the Velocity project. To solve the problem of chaotic evolution by simply having no evolution, no ongoing development -- that is not really a valid solution in my view.

    Now, in the FreeMarker community, we have a very open, forthright culture. People rib each other about one another's screw-ups in our community. Also, ideas presented are subject to ruthless criticism and debate and so on.

    You are taking certain criticisms of me or of the project out-of-context, and seem to be twisting and distorting these things to imply that people are fed up with me and on the verge of mounting some kind of rebellion against me in that community.

    That is simply not the case.

    As for the business of "taking me seriously" and more importantly, taking the FreeMarker project seriously, just look at the sheer level of energy that Daniel has put into the project (he is now co-admin) and that he continues to put into it. That says that he takes the project quite seriously. I think it's also safe to say that he respects me, as do all the other people with whom I collaborate on open-source endeavors.

    I'm sorry that most of the above is non-technical personality stuff. I suppose most people aren't interested. But there are various pointed brought up by Aapo that needed to be responded to.

    Jonathan Revusky
    --
    lead developer, FreeMarker project
    FreeMarker-Velocity comparison page
  12. FreeMarker as an alternative to XSLT[ Go to top ]

    I am looking at alternatives to XSLT right now, so this is good to know about.

    >
    > What do you see principally differentiating FreeMarker's approach to XML transformation from Velocity's DVSL (Declarative Velocity Style Language)?

    Well, the truth about DVSL is that it is basically a weekend project written by one guy that solved that one guy's problem and was never much developed from that point. I don't think any work has gone on in that subproject for the better part of a year.

    These new XML transformation features in FreeMarker were the result of a lot of give-and-take back and forth in our community. You can look at our mailing list archives to see all the discussion. I mean, at this point there is really a much much bigger investment of effort in the FreeMarker XML transformation stuff than in DVSL. It's the result of a process where a lot more critical eyeballs were brought to bear.

    The other thing about DVSL is that it is based on Velocity, and I have serious doubts, given some of Velocity's limitations, that you can build a serious XSLT alternative on top of that technology.

    For one thing, Velocity basically has no notion of namespaces. Everything exists in the same big global namespace. There is not even any real notion of local variables in macros and so on.

    FreeMarker has a namespaces feature, where macros can be imported into different namespaces. See here for more details. Basically, we leverage this to be able to do customization layers, things like:

    <#import 'myMacros.ftl' as myMacros>
    <#import 'yourMacros.ftl' as yourMacros>

    and then there might be a macro called displayFoo that exists in both namespaces, and you disambiguate via:

    <@myMacros.displayFoo/> vs. <@yourMacros.displayFoo/>

    and this is leveraged in the XML processing stuff, where you can provide a sequence of macro libraries that provide customization layers:

    <#visit docRoot using [myMacros, yourMacros]/>

    This kind of basic infrastructure is just not present in Velocity, which has a much poorer, less expressive template language. The other thing that will probably drive you nuts when trying to use Velocity in this space is the lack of control over superfluous whitespace.

    In any case, if you look at the FreeMarker documentation, you should note that it is generated by FreeMarker using the new XML transformation capabilities. And we have autogenerated TOC and index, and cross-references and so on. It's serious docs. I do not believe that anybody has undertaken a similar documentation generation task using Velocity-based stuff -- Anakia or DVSL.

    So, in conclusion, we have some real proof of concept that FreeMarker can scale up to some very complex XML transformation tasks. Also, our product is currently developed and maintained. DVSL (and Anakia) are basically abandoned in whatever state they are currently in.

    I hope these (rather biased) comments are helpful.

    Cheers,

    Jonathan Revusky
    --
    lead developer, FreeMarker project
    XML transformation with FreeMarker


    >
    > The two look like similar approaches, though I don't know how much effort is going into DVSL at this point.
    >
    > Jay Fienberg
    > the iCite net
  13. Regarding the comparison of Freemaker versus Velocity. The one thing that turned me off Freemaker (about 6mths ago) was that I couldn't call Java methods directly in the template. As a Java web developer this is a big hassel, I don't want to have to write a wrapper object every time I need to call an Java method in a template.

    I acknowledge the separation of tiers stuff MVC, which everyone carries on about, but I dont really buy it. MVC as its discussed in web apps is Pattern abuse. Look at a traditional GUI component, and it is usually the Model, the View and the Controller in the same object. Make my life easier please, not harder.

    Anyway beside this issue I thought the Freemaker stuff looked great. Very impressed with the doco.

    regards Malcolm
  14. Regarding the comparison of Freemaker versus Velocity. The one thing that turned me off Freemaker (about 6mths ago) was that I couldn't call Java methods directly in the template. As a Java web developer this is a big hassel, I don't want to have to write a wrapper object every time I need to call an Java method in a template.


    No, you don't have to write your own wrapper object to expose all of a method's java objects. See here for information about the BeansWrapper, which can automatically wrap any java object so that the various beans properties and methods are exposed to a template.

    You can even set the BeansWrapper as the default object wrapper, in which case, it just always happens transparently by default, i.e. Configuration.getDefaultConfiguration().setObjectWrapper(ObjectWrapper.BEANS_WRAPPER);

    What is the case is that, in its default configuration, the beans wrapping did not occur -- you had to explicitly do the BEANS_WRAPPER.wrap(myObject) thang.

    Now, actually, in FreeMarker 2.3.x, we changed the default behavior. The default behavior is now to fall back on the beans wrapping behavior when it encounters an object that it doesn't "know about". So any objects of your own that you drop into a template processing context would automatically get beans-wrapped as described, even in the out-of-the-box configuration.

    So, really, note that, not only do we have what Velocity offers in this regard, but we also have a much more security-minded flexible approach. You have the flexibility to expose to the template layer exactly the stuff you want to expose -- like just the getXXX/setXXX beans properties, all methods, or so on.

    >
    > I acknowledge the separation of tiers stuff MVC, which everyone carries on about, but I dont really buy it. MVC as its discussed in web apps is Pattern abuse. Look at a traditional GUI component, and it is usually the Model, the View and the Controller in the same object. Make my life easier please, not harder.

    I agree. MVC is turning into a dogma. However, I think you misunderstood how "prescriptive" FreeMarker is in this regard. It isn't very... You have the flexibility to enforce more Model-view separation if you want for large-scale architectures, but you also can just use the beans wrapper throughout and access your own java API's directly. FreeMarker is a tool with a pragmatic philosophy. Different strokes for different folks.

    >
    > Anyway beside this issue I thought the Freemaker stuff looked great. Very impressed with the doco.

    Thanks for the kind words. Now that you know that you can expose your java API transparently to the templates (just like in Velocity or WebMacro) maybe you'll give it a shot!

    Regards,

    Jonathan Revusky
    --
    lead developer, FreeMarker project
    FreeMarker-Velocity comparison page

    >
    > regards Malcolm
  15. Very impressive[ Go to top ]

    Hello Jonathan,

    haven't explored your product in depth yet, but at first glance i must say that i am extremely impressed with both the quality and comprehensiveness of the documentation that is provided on the site...

    an index!
    a glossary!
    the writing is literate!
    grammatically correct!
    technically detailed and precise!
    readable!

    forgive the abuse of exclamation marks, but this is sooo depressingly rare in open source...


    this is always the true test of an open source project, any project really, the docs...

    it's what i look at first, because it allows me to separate the wheat from the chaff very quickly, and thereby save time...

    you guys have not skimped on the docs, in fact you have excelled, so congrats, i know how much work it is :-).


    based on the quality of the docs, i am very confident of finding a well designed architecture and high quality source code...

    in my experience, the correlation between high qualtiy docs and high quality design/source is just left of 100%...



    anyone have thoughts on this?


    Peter


    PS. i would be very interested to hear how you generated your docs using FreeMarker, maybe a high level treatment of the components, and the workflow?

    that would be something i could take to the "higher ups"...for architectural integration consideration.
  16. Very impressive[ Go to top ]

    [snip]
    > based on the quality of the docs, i am very confident of finding a well designed architecture and high quality source code...
    >
    > in my experience, the correlation between high qualtiy docs and high quality design/source is just left of 100%...
    >
    > anyone have thoughts on this?
    [snip]

    Yes... about the correlation between high qualtiy docs and high quality design/source. The author of the docs is me, the main author of the FM core is Jonathan. And we are very different characters in professional fields... :) Jonathan is a smart and energetic coder, but also he tends to be loosie about theoretical correctness and design in general (and about JavaDoc comments ;)). I'm the opposite (slow and bad coder, but etc.). Also, FM has grown in an incremental, ad-hoc way; it's history was bumpy (lead developers were changed...). BUT, it works. Really works, in the reality. I would call it a *practical* stuff.

    > PS. i would be very interested to hear how you generated your docs using FreeMarker, maybe a high level treatment of the components, and the workflow?

    High level treatment of... huh? ;) No magic here... If you check out the docgen sub-module of the freemarker CVS (on the SF.net), you will see that there is a HTML template for pages as "part", "chapter", "index", "glossary", etc. and these templates will be invoked form a little Java program that drives the whole HTML producing process (FM is just a template engine, a "library". It can't do anything alone). Also, there is a big-tedious template that contains the handler-macros for the many-many common XDocBook elements (para, emphasis, programlisting, etc.). It uses the "Declarative XML processing", as it was described in the documentation.
  17. Very impressive[ Go to top ]

    Hello Jonathan,

    >
    >
    > this is always the true test of an open source project, any project really, the docs...
    >
    > it's what i look at first, because it allows me to separate the wheat from the chaff very quickly, and thereby save time...
    >
    > you guys have not skimped on the docs, in fact you have excelled, so congrats, i know how much work it is :-).

    Thank you very much for the kind words, Peter. It's really Daniel Dekany who is the main author of the documentation. And it's quite a heroic effort he has made since English is not his first language.

    >
    > PS. i would be very interested to hear how you generated your docs using FreeMarker, maybe a high level treatment of the components, and the workflow?
    >
    > that would be something i could take to the "higher ups"...for architectural integration consideration.

    Well, if you want to see how we generate our docs, you can check out the appropriate module from our CVS. That's the docgen module. You pick that up and if you run "ant" from the top-level directory, it should just work.

    The intention is that the docgen stuff will eventually be a separate downloadable distro, a complete example of using FreeMarker's XML transformation capabilities for a complex docs generation task.

    There is still some way to go in this regard, since we don't have a clear separation between what is specific to our docs and generally reusable stuff. IT requires some polishing. That said, if you are looking for something like this, you could certainly use our docs generation stuff as a starting point. And we would be pretty helpful, since we are very interested in feedback and so on.

    Thanks,

    Jonathan Revusky
    --
    lead developer, FreeMarker project
  18. This are good news. What hold me back using Cocoon was that I am quite forced to use XSLT.

    Does Freemarker work with Cocoon ?

    j.rebhan@web.de
  19. This are good news. What hold me back using Cocoon was that I am quite forced to use XSLT.

    >
    > Does Freemarker work with Cocoon ?

    Currently, we have no Cocoon bridge code. It might be an attractive thing. I have not investigated how difficult this would be to do.

    FreeMarker does work with various other web app frameworks, such as Struts, and JPublish and also is the view of choice in Open For Business. There is a list of the frameworks that interoperate with FreeMarker here.

    Regards,

    Jonathan Revusky
    --
    lead developer, FreeMarker project
    XML transformation using FreeMarker

    >
    > j.rebhan@web.de
  20. I would agree that there is a learning curve involved with XSLT, but once the initial shock wears off, XSLT can fit the bill nicely in some simple ways (i.e. not all templates are complex or have to be). I would say though one key thing to making XSLT really fast in this environment is 1) localizing DTD, or making a DTD that only contains the entities you absolutely need, 2) Don't validate unless you absolutely need to.

    It's possible to really mess up even with the simplest languages, and XSLT is no different. Liberal use of // in XPath expressions can lead to needless traversal of the source tree.

    As for benchmarking, I would have to see several comparisons against different types of pages, each with varying levels of complexity.
  21. We don't have rigorous benchmarks ('rigorous benchmarks' may be an oxymoron anyway) but initial indications are that FreeMarker is a lot faster than XSLT. And I mean a lot faster. For example, FreeMarker's manual is maintained in a canonical Docbook XML format. Previously, we generated the final HTML output using using some XSLT stylesheets by Norman Walsh. The XSLT transformation was rewritten in FreeMarker, and runs 15x faster than the previous XSLT-based system using Saxon.
    1. Is Freemaker a single-pass transformation engine or not?
    2. How it can be compared in terms of performance to single-pass transformation engines (see http://stx.sourceforge.net/, "Implementations" sections)?
    3. How about producing multiple output documents (supported by Saxon 6.x extensions / part of XSLT 2.0 standard)?

    My pardons, I'm too lazy to go through on-line FreeMaker documentation :-)


    WBR, VS
  22. We don't have rigorous benchmarks ('rigorous benchmarks' may be an oxymoron anyway) but initial indications are that FreeMarker is a lot faster than XSLT. And I mean a lot faster. For example, FreeMarker's manual is maintained in a canonical Docbook XML format. Previously, we generated the final HTML output using using some XSLT stylesheets by Norman Walsh. The XSLT transformation was rewritten in FreeMarker, and runs 15x faster than the previous XSLT-based system using Saxon.

    > 1. Is Freemaker a single-pass transformation engine or not?

    I'm actually not sure what the definition of a single-pass transformation engine is. I think it's not. I assume you mean something that uses an event-driven API like SAX and transforms the XML thing on-the-fly without any intermediate tree-building step. A FreeMarker XML transformation builds a DOM tree and acts on that.

    OTOH, if the main motivation of a single-pass transformation is performance, as I said, the initial indications are that FreeMarker is a lot more performant than XSLT, both in CPU and memory usage.

    > 2. How it can be compared in terms of performance to single-pass transformation engines (see http://stx.sourceforge.net/, "Implementations" sections)?

    How can it be compared?

    Well, I guess by comparing it! :-) We haven't performed any such comparisons, but would be interested in any information that anybody provides.

    > 3. How about producing multiple output documents (supported by Saxon 6.x extensions / part of XSLT 2.0 standard)?

    What do you mean by this exactly? Offhand, that doesn't seem like much of a problem. You would just process the templates multiple times with somewhat different data in the data model, I guess. But maybe you mean multiple output formats? Then you would need different templates.

    >
    > My pardons, I'm too lazy to go through on-line FreeMarker documentation :-)

    Well, I've answered you about as well as I can offhand. If you have any more questions or comments, you can do so on the FreeMarker mailing lists. As I said, we are very interested in receiving feedback on this.

    Jonathan Revusky
    --
    lead developer, FreeMarker project
    XML transformations with FreeMarker
  23. I'm actually not sure what the definition of a single-pass transformation engine is. I think it's not. I assume you mean something that uses an event-driven API like SAX and transforms the XML thing on-the-fly without any intermediate tree-building step.

    Your guess is completely correct. It's almost a definition of single-pass (or streaming) transformation.

    [about comparision to http://stx.sourceforge.net/ implementations]
    How can it be compared?
     
    Well, I guess by comparing it! :-) We haven't performed any such comparisons, but would be interested in any information that anybody provides.

     
    Yes, this information will be really interesting. Streaming transformation is a real competitor to XSLT. There are a lot of transformation tasks that doesn't require complex XPath navigation (especially, so lovely "//myElement" expressions :-), where STX (possibly FreeMaker[?]) is an optimal choice because of it efficiency.

    [about multiple output documents]
    What do you mean by this exactly? Offhand, that doesn't seem like much of a problem. You would just process the templates multiple times with somewhat different data in the data model, I guess. But maybe you mean multiple output formats? Then you would need different templates.

    I mean the following scenario: one input document -> transformation -> several output documents (possibly in different formats).
    For example, in my recent project we have:
    1. SAXSource built around java.sql.ResultSet with log messages from several servers (input document)
    2. XSLT transformation (Saxon 6.5)
    3. several XML reports (every report with messages groupped per server) + plain text SFTP script to upload the reports to Web server

    The key point here is that several output documents produced by single transformation.

    WBR, VS
  24. [about multiple output documents]

    > What do you mean by this exactly? Offhand, that doesn't seem like much of a problem. You would just process the templates multiple times with somewhat different data in the data model, I guess. But maybe you mean multiple output formats? Then you would need different templates.
    >
    > I mean the following scenario: one input document -> transformation -> several output documents (possibly in different formats).
    [snip]
    > The key point here is that several output documents produced by single transformation.

    It is possible. However, FreeMarker itself will not do that. FreeMarker is just a "library", a component that you can integrate with "frameworks". It just merges text templates with a set of variables (the data model), and writes the resulting text into a java.io.Writer. In FreeMarker 2.3, you can put XML documetns (actually, org.w3c.dom.Node-s) into the data model.

    So, if you want to produce any output files, you need a tool that uses FreeMarker. For example, FMPP (disclosure: I'm the author) deals with file production with FreeMarker templates, and it can "produce multiple output files by single transformation". There are working examples included in the latest FMPP release, that do this.
  25. When comparing FreeMarker´s data model and template language to the J2EE 1.4 alternative (JSP 2.0 and JSTL 1.1), I don´t see any significant advantages.

    FreeMarker´s template syntax is only slightly easier than JSP syntax.
    Maybe an advantage would be the ease with which FreeMarker can be embedded in any Java application, not just a JSP-based web app. Tomcat can also be embedded, but it´s probably harder to do.

    So, what am I missing?
  26. When comparing FreeMarker´s data model and template language to the J2EE 1.4 alternative (JSP 2.0 and JSTL 1.1), I don´t see any significant advantages.

    >
    > FreeMarker´s template syntax is only slightly easier than JSP syntax.
    > Maybe an advantage would be the ease with which FreeMarker can be embedded in any Java application, not just a JSP-based web app. Tomcat can also be embedded, but it´s probably harder to do.
    >
    > So, what am I missing?

    Well, the question can be put reversed: Why is JSP 2.0+JSTL 1.1 better than FreeMarker? :) After all, FreeMarker is the senior. ;) But seriously... I know the new JSP/JSTL version only very marginally, but it will cleanly decrease the demand for template engines than FreeMarker, Velocity of WebMacro (the new ${exp} stuff is cool... I mean, new in JSP; it has existed in FreeMarker from the beginning). Even if JSP is technically inferior (e.g.: its syntax is more ugly and verbose, it has no such flexible object-wrapper, it has no automatic HTML/XML/whatnot escpaing (or has it? I don't know...), it is slower when you change/reload the JSP page, etc.), it will be the "standard" on the Web field, with tons of 3rd pary support... life is cruel. The technologies of IT giants trample down other alternatives.
  27. FreeMarker x JSP 2.0+JSTL[ Go to top ]

    the new JSP/JSTL version only very marginally, but it will cleanly decrease

    > the demand for template engines than FreeMarker, Velocity of WebMacro

    template engines as FreeMarker, Velocity *or* WebMacro... sorry.
  28. When comparing FreeMarker´s data model and template language to the J2EE 1.4 alternative (JSP 2.0 and JSTL 1.1), I don´t see any significant advantages.

    >
    > FreeMarker´s template syntax is only slightly easier than JSP syntax.
    > Maybe an advantage would be the ease with which FreeMarker can be embedded in any Java application, not just a JSP-based web app. Tomcat can also be embedded, but it´s probably harder to do.
    >
    > So, what am I missing?

    Well, FreeMarker still has a lot of things over JSP. Just look at FreeMarker's macro capabilities or compare the ease of writing a FreeMarker transform (a.k.a. filter) with writing a JSP taglib. See here for more information on transforms.

    Also, FreeMarker has gone a lot further in terms of solving very typical web design problems. Look, for example, at the block-escaping kinds of features.

    FreeMarker really is still a lot more flexible than JSP. For example, a fairly well-known project, Open For Business recently decided to undertake a big migration from JSP towards FreeMarker, and one of the lead developers commented that it was such a relief to get away from JSP.

    Also, since you bring up JSP, I should point out that FreeMarker supports the use of third-party JSP taglibs from within a FreeMarker template, so in fact, you don't lose the option of using well-designed 3rd party taglibs, like SiteMesh nad CeWolf and so on, if you opt for FreeMarker over JSP.

    Now, as Daniel pointed out, the facts of IT life are such that JSP will always have a lot more users than we do -- it's due to placement and marketing hype. But FreeMarker nonetheless has a lot to offer. I can't say much more now. Give it a try!

    Regards,

    Jonathan Revusky
    --
    lead developer, FreeMarker project
  29. Yes, FreeMarker has a lot of great features, which are not available in the current versions of JSP (1.1/1.2). JSP 2.0, however, is a huge step forward for JSP, and JSTL is the best JSP tag library I know of.

    FreeMarker's macro feature seems equivalent to JSP 2.0's <em>tag files</em> (chapter 8 in JSP 2.0 PFD3). The transforms would correspond to JSP 2.0's <em>simple tag handlers</em> (see JSP.7.1.5). Concerning XML/HTML escaping, though, there is only the JSTL 1.0 <c:out ... escapeXml="true|false"/> tag (apparently, there were some rules for escaping XML in EL expressions, but they were removed in PFD3).

    I think it would have been great if someone from FreeMarker's dev group was in the JSP 2.0 Expert Group, since FreeMarker's design shows a lot of good ideas. The #escape directive, for example, is something I would like to see in JSP.
  30. Yes, FreeMarker has a lot of great features, which are not available in the current versions of JSP (1.1/1.2). JSP 2.0, however, is a huge step forward for JSP, and JSTL is the best JSP tag library I know of.

    >
    > FreeMarker's macro feature seems equivalent to JSP 2.0's <em>tag files</em> (chapter 8 in JSP 2.0 PFD3). The transforms would correspond to JSP 2.0's <em>simple tag handlers</em> (see JSP.7.1.5).

    Approximately, yes. However, the JSP equivalents seem much heavier to use and less flexible than the FreeMarker equivalents. At least, that is my initial reaction. It looks like it is much easier to write FreeMarker macros or transforms than JSP taglibs. Also, the resulting syntax is much more readable and pleasant to work with.

    Also, I think FreeMarker is more powerful in this regard, since FreeMarker macros and transforms are simply variables that can be assigned or even put in sequences and hashes and so on. Another powerful feature in FreeMarker, available as of 2.2, is the namespaces feature. This is very powerful in terms of implementing customization layers and is put to very good use in our XML transformation functionality.

    >Concerning XML/HTML escaping, though, there is only the JSTL 1.0 <c:out ... escapeXml="true|false"/> tag (apparently, there were some rules for escaping XML in EL expressions, but they were removed in PFD3).

    Well, the escaping is not just HTML/XML escaping, but that you can set some rules for how any variable is dealt with on being output. A silly example.

    <#assign foo="Hello">
    <#assign foo="World">

    <#escape x as x+ " " + x>
       ${foo}
       ${bar}
    </#escape>

    would output:

        Hello Hello
        World World


    >
    > I think it would have been great if someone from FreeMarker's dev group was in the JSP 2.0 Expert Group, since FreeMarker's design shows a lot of good ideas. The #escape directive, for example, is something I would like to see in JSP.

    Well, at the moment, if you want to get the benefit of our community's good ideas, you'll just have to use FreeMarker. Or wait until there's a JSP 3.0 that appropriates FreeMarker's more current innovative ideas, I guess. :-)

    Again, note that JSP taglibs, including JSTL, can be used from FreeMarker. So you don't cut yourself off from that whole world anyway.

    Regards,

    Jonathan Revusky
    --
    lead developer, FreeMarker project
    Use JSP taglibs from FreeMarker
  31. I read the description of FreeMarker and the discussion in this thread. Quick question how does it support converting XML data to various different output like HTML, XML, WML, PDF, etc. Do we need to write scripts (templates) in FreeMarker's language or there are some existing templates we can extend?

    Thanks,
  32. Performance with XSLT[ Go to top ]

    My application extensively uses XSLT for reporting purpose(HTML,PDF,.doc). XSLT(processor) performence is a major concern for me due to large size of XML documents. I am constantly looking for an alternative.
    The other problem with replacement is that my clients can use their own stylesheets for differnet reports which I dont have control.
    So can freemaker provide following

    1) Excellent performance compare to XSLT processors
    2) What is the learning curve to learn freemaker.? I mean does freemaker script have any resemblance with XSLT script so that my clients can learn quickly.

    regards,
    Ranjan