The checsums are there for a reason, and I think this is the correct approach.
The only thing missing in my opinion is to be able to declare that I want the checksum for all assets inside directory x to be calculated from all the assets in that directory. This way the checksum would be the same for all the assets in the dir and change if any of the assets change, which would lead to correct functionality in this WYMeditor example (the relative paths would work then). Easy to upgrade too, drop in new version of WYMeditor and Tap calculates new checksum for you and browsers react correctly. Don't upgrade and let the browser caches work magic. I think that would make sense for many third party integrations, and once again, it would let Tap make a sensible default, but allow fallback if needed. (And let the developer be king! http://www.youtube.com/watch?v=8To-6VIJZRE :)) Ville -----Alkuperäinen viesti----- Lähettäjä: Barry Books [mailto:[email protected]] Lähetetty: 12. syyskuuta 2013 15:44 Vastaanottaja: Tapestry development Aihe: Re: [5.4] Problems with the asset checksums and relative paths based on them If you have file a b and c. The page includes a which then includes b and c but in your case with a's checksum. If Tapestry just returned b and c with a's checksum everything would work fine. The only problem would be if you change b or c without changing a. I agree this could be a problem but if you are using a library with releases I would say the odds of this happening are low and is easily fixed by just changing a. In other words what's the benefit of the 404? The checksum is not meant to be a security mechanism. On Thu, Sep 12, 2013 at 6:54 AM, Thiago H de Paula Figueiredo < [email protected]> wrote: > On Wed, 11 Sep 2013 19:41:40 -0300, Barry Books <[email protected]> wrote: > > Perhaps a dumb question but why does the checksum need to match for >> Tapestry to return the file? The only problem I can think of is if >> the included file changes but the main file does not then the cached >> file might be used. >> > > What do you mean by included file and main file? > > > I would think that's unlikely to happen >> > > Actually, browsers not getting updated JS, CSS and image files after > they were changed in the server is quite common without some mechanism > like that. In T5.1 projects, many times I've had to ask the testers to > clear their caches because they were testing the fix and the problem > was still appearing because of the browser cache. > > I've actually fixed my problem by creating a request filter that > checks for requests to files dynamically included by WYMeditor, find > the original files in the classpath, generate a new Asset instance for > them (which contains the right checksum) and redirects to it. Ugly, > but fixes the problem. :) > > > -- > Thiago H. de Paula Figueiredo > > ------------------------------**------------------------------**------ > --- To unsubscribe, e-mail: > dev-unsubscribe@tapestry.**apache.org<[email protected]. > org> For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
