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
