Christopher Schultz wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
yoursoft,
yoursoft wrote:
Dear Developers,
The first version is my class is available.
It is a little performance "tweak", because this read from disk only,
when original template is changed, and make a cached compressed copy of it.
Just to recap... this thing normalizes spaces in a template, right?
Yes, it is normalizes white-spaces in the templates.
With compressed input, the memory use is lower, velocity variables
insertion is faster and bandwidth usage is also lower.
Can you quantify these claims? For instance, how much less memory (and
bandwidth) is really used given a relatively standard template?
I wrote that: it is a little performance "tweak".
Whitespace removal is depends how to format your templates. In most case
it is compress your html code to 50%-75%.
Memory usage is more complex thing:
Depends on format of you html code and the count of templates in memory.
How can
Velocity variable insertion be faster?
I think, when Velocity replace a $variable in a template, velocity will
be faster when a template is smaller.
It also looks like you implemented many methods (such as init,
getResourceStream, isSourceModified, and getLastModified) that might be
better implemented elsewhere. For instance, since your implementation of
ResourceLoader appears to be file-based, why not extend
FileResourceLoader and then just modify the behavior of
getResourceStream like this:
public InputStream getResourceStream(String templateName)
throws ResourceNotFoundException
{
InputStream in = super.getResourceStream(templateName);
// now perform your filtering
}
This would make a much cleaner class, IMO.
Yes this is a good idea :-)
It would also make this into
more of a filter, which makes more sense me, personally. Instead of
essentially copying the file and then reading /that/ into memory, why
not just filter the input stream on the fly?
In your solution, when you e.g. restart Tomcat, and Velocity reload a
template, every time need to compress it. In my solution if the
compressed file date is not smaller than original template date, in this
case isn't need to recompress it, only reload from compressed file. But
your solution is an other way, that may be better. My first think was
same with your think. :-)
You could also write your class such that instead of extending a single
class (such as FileResourceLoader), you could wrap /any/ type of
resource loader, and pass the source loader as an argument to a
constructor. Your no-arg constructor could simply use a
FileResourceLoader as the default.
Then, all your methods would be delegates to the "real" loader except
for getResourceStream, which would perform the filtering.
This is good idea, but is not my target. My target only a file resource
(html file) loader, that compress my input templates. :-)
- -chris
Thanks for suggestions,
Regards,
Ferenc
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
