I think having a special "matches anything" checksum value (perhaps "-"?) might be a good idea from an integration point of view. Again, for anything that originates inside Tapestry, Tapestry will build the correct URL.
On Tue, Apr 9, 2013 at 9:18 AM, Barry Books <trs...@gmail.com> wrote: > I'm not a big fan of the release in the URL for three reasons > > 1 it causes problems in development because things change but the URL does > not > > 2 it causes all resources to become invalid with a release even if they do > not change. The more often you release the bigger the problem > > 3. It complicates CDN integration because all the assets paths change > every release > > Using a hash as part of the URL > > /assets/myapp/hash/.../name solves these but makes the URL difficult to > predict. Adding > /assets/myapp/nocache/.../name > > Makes it possible to predict the name in style sheets if needed and CSS > rules allow this to be overridden in the layout if you want the performance > increase. The ETag could also be used here so the nocache asset could > return a not modified > > On Apr 9, 2013, at 9:46 AM, Ivan Khalopik <ikhalo...@gmail.com> wrote: > > > In my opinion the best practice is to use ETag in addition to application > > version folder. So the first level of asset caching is by path, e.g. > > /assets/myapp/1.0.0/... When we deploy a new app version, this path is > > changed and browser forces new assets retrieval. If application version > is > > not changed, we have the same path for assets and they are cached by > > browser until expired. But we can also reduce the traffic even if app > > version is changed or browser cache is expired. If we have the second > level > > of cache using ETag. If asset checksum is changed we will return the > whole > > asset content, or just 304 otherwise. > > > > So, application version folder reduces request count to those that are > not > > cached for current app version, ETag reduces the rest of traffic if asset > > checksum is not changed. > > > > > > > > > > On Tue, Apr 9, 2013 at 4:39 PM, Dmitry Gusev <dmitry.gu...@gmail.com> > wrote: > > > >> Barry, > >> > >> no need to pass current date as application version, because if you > don't > >> supply any defaults then > >> tapestry will generate random version for you. > >> > >> But this may have some limitations if you're running in a clustered > >> environment. > >> > >> Also your clients will get new assets every time you restart your > server. > >> > >> See this: > >> > >> > http://mail-archives.apache.org/mod_mbox/tapestry-users/201005.mbox/%3caanlktinz4ukjng-zom8t86ry-mrw7st7e9eufhkvv...@mail.gmail.com%3e > >> > >> > >> On Tue, Apr 9, 2013 at 5:26 PM, Barry Books <trs...@gmail.com> wrote: > >> > >>> After being bitten by APPLICATION_VERSION I switched to this > >>> > >>> configuration.override(SymbolConstants.APPLICATION_VERSION, > >>> *new*Date().getTime()); > >>> > >>> > >>> This way on my development machine I get a new version every restart > and > >> on > >>> my production machine on every deploy. > >>> > >>> > >>> That said I think the hash of the object in the URL and a never expires > >>> header is the way to handle this. The only problem I can think of is > >> assets > >>> in style sheets. I would say the solution to that problem lookup the > >> asset > >>> with the hashed url and return the object with a never expires header. > If > >>> there is no hash just return the object without the header. This makes > it > >>> easy to use assets in stylesheets. If you want to solve the caching > >> problem > >>> just override (or declare) the style in the Layout component and use > the > >>> asset like this: > >>> > >>> > >>> <style> > >>> > >>> .navbar-fixed-top { > >>> > >>> xheight: 64px; > >>> > >>> background-position: 0px 40px; > >>> > >>> xbackground-image: url('${context:/images/top-background.jpg}'); > >>> > >>> xbackground-repeat: repeat-x; > >>> > >>> } > >>> > >>> </style> > >> > >> > >> > >> -- > >> Dmitry Gusev > >> > >> AnjLab Team > >> http://anjlab.com > > > > > > > > -- > > BR > > Ivan > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org > For additional commands, e-mail: dev-h...@tapestry.apache.org > > -- Howard M. Lewis Ship Creator of Apache Tapestry The source for Tapestry training, mentoring and support. Contact me to learn how I can get you up and productive in Tapestry fast! (971) 678-5210 http://howardlewisship.com
