[
https://issues.apache.org/jira/browse/TAP5-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12660817#action_12660817
]
jordihs edited comment on TAP5-73 at 1/5/09 9:03 AM:
--------------------------------------------------------------------
I'd love to see Jawr used by Tapestry, so I thought you might want more info
before you rolled your own solution.
First and foremost, Jawr is built with framework integration in mind. This
means that you don't need to force users to learn how to use any new tool, but
rather you can just use it behind the scenes.
There is some specific documentation on the subject at
https://jawr.dev.java.net/integration/augmenter.html. You can get a general
idea there, but integration possibilities go beyond what is explained there.
For instance, the tag library delegates in tag-agnostic renderers. I made a
facelets tag library out of these and each tag is almost a one-liner. I'm
willing to help out with this if you want.
Now, Martin's concerns are all valid and should be accounted for. Jawr has out
of the box solutions for these issues:
Q: may cause scripts that could have been cached client-side to get reloaded
numerous times
A: etag and expires headers are added to responses. Also, Jawr returns 304 (not
modified) header and empty response body when if-modified-since or
if-none-match header is present in a request.
Q: may cause unneeded Javascript to get sent (and parsed) numerous times
A: Jawr keeps a list of all script/css tags added to a page so repeats can't
happen. Other than that, being careful to not repeat content in a script/css
bundle avoids this.
Q: 'static' files cannot be served from a different server, which allows
caching and could have a different bandwidth allowance (this is already a
problem and would get even worse).
A: Jawr has production and developer modes. It is possible to set a domain name
to prefix all urls in production mode. you can do all your development using
your local files, then deploy to production and point them to a CDN
automatically.
Q: Packed/Compressed Javascripts are almost impossible to debug properly.
A: Again, there is a development mode. All members of a pack are included
separately and uncompressed, so it's very easy to debug. Change a flag, and you
get the packed version.
Q:Much more important than how far in the future the cache date is, what will
the uri of the resource be?
A: Each URI in Jawr has a 'version hash' part that depends on the actual bundle
contents. It only changes when content does, so dont' worry, users get each
script once and only once. And when a new version comes out, the URL changes so
none of them run on outdated scripts.
By the way, both JSmin and the YUI compressor are supported. And there's a cool
i18n feature that generates javascript literals from resource bundle properties
files.
You can get more ideas at the features list page at
https://jawr.dev.java.net/features.html.
I'll help as I said, if you need me to. And if you'd still rather go on and
roll your solution, best luck.
Regards to all,
Jordi.
was (Author: jordihs):
I'd love to see Jawr used by Tapestry, so I thought you might want more
info before you rolled your own solution.
First and foremost, Jawr is built with framework integration in mind. This
means that you don't need to force users to learn how to use any new tool, but
rather you can just use it behind the scenes.
There is some specific documentation on the subject at
https://jawr.dev.java.net/integration/augmenter.html. You can get a general
idea there, but integration possibilities go beyond what is explained there.
For instance, the tag library delegates in tag-agnostic renderers. I made a JSF
tag library out of these and each tag is almost a one-liner. I'm willing to
help out with this if you want.
Now, Martin's concerns are all valid and should be accounted for. Jawr has out
of the box solutions for these issues:
Q: may cause scripts that could have been cached client-side to get reloaded
numerous times
A: etag and expires headers are added to responses. Also, Jawr returns 304 (not
modified) header and empty response body when if-modified-since or
if-none-match header is present in a request.
Q: may cause unneeded Javascript to get sent (and parsed) numerous times
A: Jawr keeps a list of all script/css tags added to a page so repeats can't
happen. Other than that, being careful to not repeat content in a script/css
bundle avoids this.
Q: 'static' files cannot be served from a different server, which allows
caching and could have a different bandwidth allowance (this is already a
problem and would get even worse).
A: Jawr has production and developer modes. It is possible to set a domain name
to prefix all urls in production mode. you can do all your development using
your local files, then deploy to production and point them to a CDN
automatically.
Q: Packed/Compressed Javascripts are almost impossible to debug properly.
A: Again, there is a development mode. All members of a pack are included
separately and uncompressed, so it's very easy to debug. Change a flag, and you
get the packed version.
Q:Much more important than how far in the future the cache date is, what will
the uri of the resource be?
A: Each URI in Jawr has a 'version hash' part that depends on the actual bundle
contents. It only changes when content does, so dont' worry, users get each
script once and only once. And when a new version comes out, the URL changes so
none of them run on outdated scripts.
By the way, both JSmin and the YUI compressor are supported. And there's a cool
i18n feature that generates javascript literals from resource bundle properties
files.
You can get more ideas at the features list page at
https://jawr.dev.java.net/features.html.
I'll help as I said, if you need me to. And if you'd still rather go on and
roll your solution, best luck.
Regards to all,
Jordi.
> JavaScript libraries should be automatically packed/minimalized
> ---------------------------------------------------------------
>
> Key: TAP5-73
> URL: https://issues.apache.org/jira/browse/TAP5-73
> Project: Tapestry 5
> Issue Type: New Feature
> Affects Versions: 5.0.15
> Reporter: Howard M. Lewis Ship
>
> Tapestry should catch downloads of JavaScript libraries, and should "pack"
> the JavaScript ... remove comments and unecessary whitespace. I believe Dojo
> has a library to do this, it may even shorten variable names (!).
> A smart implementation of this would manage to cache the compressed JS, and
> notice when the uncompressed version changed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
