On 1 Mar 2009, at 10:17, David Zülke wrote: > - each extra HTTP request costs time. It is a lot faster to combine > several JS files into one, because that then comes from the browser > cache, and just one HEAD is made to the web server to see if it's up > to date. I was going to add far-future expires headers sent with the JS files, and then in the src add a ?modified=[lastmodtime]. So potentially for the first request for a given js file there will be a http request, but not as long as it's in the browser's cache, it won't be requested again (unless a forced refresh is made I guess)
> - it's incredibly, incredibly hard to do in combination with > caching. It's a bit too hard to explain without causing utter > confusion, but trust me, you will regret it. It's not really an > implementational problem in Agavi, but rather a general logical > issue. In short: a slot that was cached on page A will be restored > from cache on page B, and restore all of page A's javascript and css > instructions. Fail. You can work around it, of course, but that's > annoying. I can sort of see why- ish. I guess I am indeed confused. > My tip would be to do it based on routes or something, in a global > filter. Can I ask if you could explain this tip a bit more? Although perhaps I don't see quite what you mean about being based on routes, I can maybe guess at a filter-based approach. The filter could scan the page for any elements of class, say, 'ajaxForm'. It can then add the required js files for an ajaxForm to the head section. I guess also the names of the classes and the required JS files could all be configured in global_filters.xml? Is this overkill for just including a few JS files into a page though? Would this have an effect on caching? What do you think? Thanks, Michal. _______________________________________________ users mailing list [email protected] http://lists.agavi.org/mailman/listinfo/users
