Re: Frustrated by template location issues

Endre Stølsvik <[email protected]> Wed, 21 Dec 2005 09:56:31 +0100 (CET)
Newsgroups gmane.comp.java.webmacro.user
Message-ID <[email protected]>
On Wed, 16 Nov 2005, Lane Sharman wrote:

| Marc,
| 
| This is a good analysis.
| 
| What do other people think of refactoring the Broker?

Absolutely positive.

I think there is way to much "magic" in WebMacro. I'd rather that it was a 
_really_ clean little "merge macro library" than all this 
automagic/confusing resolving of whatnot.

.. and get rid of those damn threads. I dislike libraries that fork 
threads without me knowing it. It makes _all kinds of dirty mess_ with 
Class(Re)Loaders and such things. I would like to _instantiate_ the 
cache-mechanism myself, choosing one of several, or, ofcourse, make a 
proper one / project specific myself! And then I'd _set_ it on the 
WebMacro instance, or something like this.
  Of course, this could just be a part of the mechanism Marc already 
suggest: if I could instantiate the TemplateProvider myself, I'd shove the 
caching _in there_, thank you. No caching inside of "WebMacro proper" - it 
does one thing: merge templates with the context, fast and _final_.
  The default template providers coming with the system could then maybe 
be pluggable in the sense that their default caching behaviour was done 
using some API/SPI thingy - default they wouldn't cache, but you could set 
the cache on the TemplateProvider on constructor or by setter before you 
sat the TemplateProvider again on the WebMacro instance.

The Broker just complicates things hugely.

Regards,
Endre.


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click