More about WebMacro's design and efficiency:

  http://webmacro.org

Quoting Alex Smith ([EMAIL PROTECTED]):

> For the sake of showing the list readers that my comments
> were not entirely unaccurate:


 [ on loading templates ]

> I was comparing the same functionality in Freemarker and WebMacro. Caching a
> parsed template is a must for a template framework and both Freemarker and
> WebMacro do that. However, due to WebMacro's broker architecture, a provider
> has to be written whereas no extra effort is required by Freemarker.
>
> As an aside, I dont see why 1) a provider that does this (use files instead
> of classpath) is not supplied with WebMacro given the fact that this is a
> popular use case 2) an application developer has to care about the
> implementation details of the package, i.e. a provider has to be written,
> because WebMacro uses a broker internally to allocate resources.

Most users of WebMacro never write, or even look at, the providers.

The provider that ships with WebMacro does not use the classpath,
and does use files. The only thing WebMacro does with the classpath
is look up its WebMacro.properties file.

An application developer does not have to know anything about providers.
All they have to know is that getTemplate(name) will return the
template matching name. By default this loads the template from a
file called 'name'.

An advanced user can extend the WebMacro framework by registering
a different template provider--for example, loading from a database
instead of a file. Doing so does not require any change to any
servlet's code--getTemplate() will just gain an additional place
to go searching for the template.

And in any case, no developer ever has to know about the implementation
of any other package.

A non-advanced user doesn't have to do anything with providers, as
the default one does what you expect (loads from a file).

> Justin:
> ---
> 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.
> ---
>
> I was operating under the assumption that parsed template is cached, which
> is what you're emphasizing above. I stand by my opinion that an adapter is
> better than introspection for a reasonably complex document, because in the
> former case the control is placed into the developer's hands whereas in the
> latter case a framework has to conduct a search for an appropriate method
> with correct arguments. F On the other hand, an adapter has to be written
> whereas introspection is done for you automagically. This is a tradeoff and
> I prefer the adapter approach (see below).

OK. But there isn't really any performance difference. JSP/JavaBeans
does exactly the same thing WebMacro does--caching the analysis makes
the method lookup cost very little.

Note that there are two separate caches here:

   1. the cache of compiled templates (in ResourceBroker)
   2. the cache of class analysis information (in PropertyOperator)

The second means that when executing a compiled template, WebMacro
does *not* introspect to turn a property name into a method.

As for control:

Nothing stops you from implementing an adapter in WebMacro,
it's an option. Just do this:

   public class FooAdapter {
       Foo _foo;
       FooAdapter(Foo f) { _foo = f; }

       public Object get(String property) {
           // whatever you want, to resolve property
       }

       public void set(String property, Object value) {
           // whatever you want, to set property
       }
   }

Now if you do a context.put("foo", new FooAdapter( myFoo )) WebMacro
will call your get/set methods since nothing else is available.

This puts control over property resolution back in your hands, but
normally it will be unnecessary--the methods of Foo can be used
directly, if they follow the beans spec.

The above is an example of one of the ways WebMacro's class analysis
is more aggressive than the basic beans spec.

> From prior experience, I know that reflection is expensive.

Yes it is. When I started caching the class analysis, WebMacro
tripled in speed.

> I urge the readers to investigate both packages (or any others) and report
> their experience to the list, lest my opinion be taken as absolute truth.

Both packages are free, after all :-)

WebMacro can be downloaded free here:

   http://webmacro.org/Download.html

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

Reply via email to