On Wed, 23 Mar 2011 22:43:55 +0100, raulmt <rau...@gmail.com> wrote:
I wanted to know if there is a reason why Tapestry couldn't just answer
the
requests for assets independently of the requested version. I believe
that
it is better to answer with a newer version than to just not answering at
all… In AssetDispatcher, this could be done by just processing the
request
when its path starts with RequestConstants.ASSET_PATH_PREFIX and then to
generate the virtualPath by stripping from this constant to the next "/"
(assuming there is a version in the middle, which will be true for all
the
URLs generated by Tapestry).
Could this cause problems in some way?
This sounds like a very good idea. I can think of a few scenarios where it
would be helpful:
- cached or saved html documents from your application, with old asset URLs
- external pages referencing assets on your site
- google image search - the search engine might have indexed an old asset
URL that no longer works
A version upgrade resulting in 404 for all old asset URLs just feels
wrong. Cool URIs don't change :)
http://www.w3.org/Provider/Style/URI
There is however one potential problem I can think of:
An application running v1.2 gets a request for a newer version
/assets/1.3/ctx/script.js and delivers its own copy of that script.
That script will then get cached by clients and proxies (maybe even your
own Squid server) so when you later upgrade your app to v1.3, clients will
use the cached copy and your app won't even get a chance to deliver the
upgraded script.
Perhaps the AssetDispatcher could check the requested version number and
if it doesn't match the app version, send a 302 redirect to the "correct"
URL?
/assets/1.3/ctx/script.js --> /assets/1.2/ctx/script.js
Or perhaps it should only deliver the asset if the requested version os
older than or equal to the app version?
Determining "older" and "newer" would however assume people name their
application versions in a certain way.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
