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
Philip Luppens wrote:
>
> I'd like to pick in on this one :-)
>
> Basically, there are two sides: we have the 'internal' Freemarker
> rendering for UI components, and we have the Freemarker result, which
> both share the same caching/template loading/.. . Now, as Tom said,
> the defaults are not so good (for the internal UI rendering). Not only
> does Freemarker have a default delay of just 5 seconds, but it also
> doesn't use its strong reference cache. [2]
>
> We can choose to split up the configuration for internal (UI
> components) and external (results) rendering, where we have a infinite
> caching for the internal use, and freemarker.properties - adaptable
> settings for external use, with better default settings when not in
> development mode.
>
> In my opinion, users should not have to worry about the internal
> rendering when just using the framework, unless they set devMode on
> (in which case constant reloading is allowed, and even required), so
> we should set the default settings accordingly.
>
> Thoughts ?
>
> Phil
>
> [1] https://issues.apache.org/struts/browse/WW-1654
> [2]
> http://fmpp.sourceforge.net/freemarker/pgui_config_templateloading.html
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
iDTV System Engineer
"Always code as if the guy who ends up maintaining your code will be a
violent psychopath who knows where you live." - John F. Woods
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
