Well, I went ahead and implemented this tonight:
http://issues.apache.org/struts/browse/WW-1661
http://jira.opensymphony.com/browse/WW-1417
It turns out that FreemarkerTemplateEngine.java is only used by the UI
tags. The freemarker result hooks into freemarker via the
FreemarkerManager. I thought about implementing the redirect cache for
the UI tags, but the missing template cache was so simple that trying to
implement the redirect cache would have complicated the code. (I don't
think there's much of a performance difference one way or the other) I
will be testing this code more fully on Monday.
Even though we only wanted to implement this caching on the UI tags side
of things, it may be beneficial to implement a similar cache for the
freemarker results. Especially if the freemarker templates are being
loaded from the classpath--freemarker will reread and parse the
templates for every request! (assuming it works the same as the UI tags)
Tom
Philip Luppens wrote:
On 1/19/07, Tom Schneider <[EMAIL PROTECTED]> wrote:
Obviously you picked up on my probing questions on the chat. :) Yes--we
use JSP's with FTL templates for the tags. It only recently occurred to
me that the caching would need to be different for the FTL tag templates
vs. FTL results. I like this proposal--it would keep the user from
having to worry about any of this. Thats a good thing. (And arguable
this type of caching should have been in place already, IMO)
The other thing I wanted to mention is that I think a missing template
cache would also be a good idea. (Phil and I discussed this) The idea
is that right now there is a penalty for looking for a template, only to
find that it doesn't exist and falling back to the parent theme
template. Instead, if we find that a template is missing, we'd put that
template name into a cache of all the missing template. Next time we
look for that template, we'd check the missing template cache and find
it in there and avoid the cost of looking for a template that doesn't
exist.
Discuss ? You said it, I nodded and punched myself in the head for not
thinking about it :-) However, allow me to ramble on a bit more - feel
free to stop me at any time:
About the cache-none cache: is there an obvious reason (I'm sure there
is) why we cannot use some sort of 'redirect cache' - where an invalid
template request would result in the correct template getting returned
(eg. /template/custom-theme-which-overrides-parent/textfield.ftl would
return the template for /template/parent-theme/textfield.ftl or even
/template/base-theme/textfield.ftl) - multiple keys for the same cache
value. It would reduce 3 cache requests to 1, but it might result in
more work, or unnecessarely complicate things.
These 2 things would completely eliminate the 3+ days I spent
'optimizing' our WW app--so I think it would be very worthwhile
investment. (I'll gladly pitch in once we've wrapped up our performance
testing)
Tom
Cheers,
Phil
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
