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