On 3/20/07, yoursoft <[EMAIL PROTECTED]> wrote:
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.
the parsing of the compressed template will probably be a bit faster,
but once the template is parsed into an AST and cached, then merging
with the context should be the same speed, as the AST should have the
same structure, only with some smaller text nodes.
> 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. :-)
there are a lot of people who load html templates using the
WebappLoader in the VelocityTools project. if your compressor could
be used with that, i'm betting it would be of use to quite a few more
people.
perhaps you could abstract your compression code out so that it could
be used both as Christopher suggests and as you prefer. that would
make it more interesting to me, as i do not often use the
FileResourceLoader, nor allow my Velocity webapps to write files to
disk.
either way, i think you ought to add this to the Wiki
(http://wiki.apache.org/velocity/ContributedCode) and point it out to
the user mailing list once you feel it is ready for that.
> - -chris
>
Thanks for suggestions,
Regards,
Ferenc
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
