Justin
Be it WebMacro or FreeMarker, an average developer like me (trying to be
modest :-) will surely find them quiet useful when developing dynamic web
pages. I guess, the issue that is of concern of is the one that you left out
(I'm not sure if that was intentional) i.e. the license. I'm not sure about
others but that was the ONLY factor I considered going for FreeMarker
instead of WebMacro. I wasn't having adequate insight into any of these to
have figured out the REAL difference between the two, anyway.
Nishi
--People who live in windowed environments shouldn't cast pointers--
mailto:[EMAIL PROTECTED] http://www.c3ipros.com/nkapoor
-----------------------------------~~~------------------------------
> -----Original Message-----
> From: Justin Wells [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, June 04, 1999 12:30 PM
> To: [EMAIL PROTECTED]
> Subject: Re: WebMacro versus FreeMarker
>
> Hi Alex, many of your comments about WebMacro were not accurate:
>
> Quoting Alex Smith ([EMAIL PROTECTED]):
>
> > 1) Freemarker is template-only package whereas WebMacro tries to go
> beyond
> > that with the resource broker(s), template providers and other possibly
> nice
> > but unnecessary (in my case) stuff. I wanted nothing more than a way to
> say
> > Template t = new Template(new File("foo.template"));
> > t.output(req.getOutputStream());
> >
> > To do this, I had to write my own provider for WebMacro that would pick
> up a
> > file based on the filename rather than search for it in the classpath
> > (default). Freemarker didnt need this as it's a simpler system based on
> > files and the above is what it was explicitly designed for.
>
> Actually, you can just write
>
> Template t = new FileTemplate(fileName);
>
> the advantage in using the provider is that it caches the compiled
> template,
> whereas loading it fresh each time re-invokes the compiler.
>
> > 2) Freemarker has a simple script syntax whereas WebMacro is more like
> Perl.
> > Hidden in this seemingly innocuous statement is the implementation
> detail
> > that greatly affects the performance of the package: WebMacro uses
> > introspection extensively to find the data in the supplied context
> whereas
> > Freemarker opts for an adapter approach where the template writer has to
> > write an explicit query for a piece of data based on the supplied
> context
> > key. That is, if you have
> > the following line in your template:
> >
> > <input type="text" name="name" value="$foo.bar.baz">
> >
> > WebMacro will look for bar and baz (and possibly foo) using Reflection
> > whereas Freemarker will force you to write something like
> >
> > if (key.equals("foo")) return "foobar"
> >
> > somewhere in your adapter. This is a bit more work but Freemarker's
> adapter
> > design is elegant and not much of a hindrance. (If you ever dealt with
> > java.lang.reflect, you know how "fast" it can be, not to mention
> potential
> > stack explosions).
>
> This is misleading. WebMacro uses the reflection API to analyze your
> class exactly once for each class, and then caches that data for the
> life of your servlet environment.
>
> This is the same approach Sun takes with JavaBeans, and is remarkably
> efficient.
>
> If WebMacro re-analyzed every object on every access it would be slow.
> But it doesn't do that, and is actually very fast.
>
>
> > 3) Documentation. I found Freemarker's docs to be well-organized,
> coherent
> > and with a working walkthrough of a guestbook example. WebMacro has the
> same
> > but it's about 50% of what it has to be, partially due to its
> complexity. I
> > had problems with WebMacro's
> > guestbook example due to the default template provider's functionality
> of
> > looking for a template in the classpath.
>
> It's quite straightforward, and hundreds are using it successfully. I
> admit there needs to be some better documentation--however the lasy
> couple of releases added a substantial amount of new documentation, so if
> your comments refer to an older version you might find things have
> improved.
>
> > and last but not least, the claim that many template packages use as
> bait:
> > "let the designer write HTML and use our simple syntax to control the
> data
> > flow". This is a myth as most HTML designers have a difficult time
> > understanding foreach loops and other programmatic constructs. Usually
> good
> > designers come from art/publishing/media side of the pond and are
> excellent
> > visual artists with poor grasp of data structure constructs...and that's
> > good. I'd rather have a strong artist who knows his craft than a
> > middle-of-the-road designer who knows Javascript. ("Instead of table,
> you
> > have a foreach loop with a single row. - <Blank stare>"). Therefore, the
> > application developer has to take on the responsibility of marking up
> the
> > template. As such, lesser syntax complexity and greater programmatic
> control
> > is always appreciated.
>
> You can't create dynamic content including tables unless you are
> prepared to iterate through lists. WebMacro's #foreach is the simplest
> iteration structure possible, much simpler than a for loop, or while
> loop, or anything else with a loop condition.
>
> JavaScript is about 1000 timesmore complex, and requires a big thick
> book to learn properly. WebMacro's template script can be fully
> explained in about three pages (lengthy version) or illustrated in
> a one-page example.
>
> <table>
> #foreach $thing in $list {
> <tr><td>$thing.Name</td><td>$thing.Description</td></tr>
> }
> </table>
>
> The above may be difficult to describe, but given an example like
> this the vast majority of page designers catch on immediately. A few
> are so afraid of computers that they refuse to see--but they are a
> distinct minority (and won't be better served by JSP/ASP/FreeMarker/etc.)
>
> Even if you have such designers, a programmer can easily convert a plain
> HTML file produced by such a designer into the above with little work.
>
> A simplified construct like WebMacro's #foreach really isn't hard to
> understand.
>
> Justin
>
> __________________________________________________________________________
> _
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
> body
> of the message "signoff SERVLET-INTEREST".
>
> Archives: http://archives.java.sun.com/archives/servlet-interest.html
> Resources: http://java.sun.com/products/servlet/external-resources.html
> LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
