In short1. if you are in developpement mode you want to set the system to test in admin ->settings so that css/js are not cached on the browser side. 2. if you have an issue with the cache of css/js/configuration you can go to admin->cache and reset the cache. Normally this should not happen but there are always times when you need to reset it. 3. if you add resource/javascript/my_app.js or php/javascript.inc.php to your application your javascript will be loaded automatically with the right headers and browser caching. I would suggest you use this when you are done debugging to avoid unnecessary workload. 4. css is now minified and one file is generated by including the import directives. One for common plus one per application. That means that strange things you shouldn't anyway do wont' work - like conditional directive in comments. 5. javascript follow the same approach. One file for common plus one per application. But is not minified. 6. local settings, generic settings and registrations are locally cached. This should be transparent but still need to be tested - especially installation - as I wasn't too sure where it was set. 7. global is split into init and conf. This is required as css/js caching do not need the conf overload and because conf remains rather slow.
the good1. it's much faster, global about 4 times faster. Before that several pages had global taking 75% of the time.
2. network workload is much, much less 3. pages have much better scores at google audit and yahoo slow the bad1. debugging javascript is a bit annoying in the browser with one big file. If it is too annoying I would suggest you manually add the js file - the way it is now - and use the architecture when done. 2. when caching there are situation when the caches can become out of synch, so you need to be aware this may happen. For example if you change your css and do not reset the cache it won't be updated. 3. I added called to cache synch in setting, userSetting and regisration. This is not optimal but is simple and should ensure that caches are kept in synch. This can be easily improved later on if we find a better solution. 4. not too sure if point 3 will suffice. I would appreciate if somebody could confirm when setting, usersetting and registration may change.
the ugly1. the css/js urls have now a time parameter and an expires date of 2038. So that those are fed from the browser cache. To update the files when they change the system changes the timestamp. Which is more or less equal to date of last installation. This is done manually in admin->cache
2. the less external files in pages the better. For this reason it is better to have big js/css files rather than plenty of smaller one.
3. php files which feed static content need to manage the http caching headers themselves. I.e. check for if modified-since and answer 304 when required.
4. the way it works now - same as before - is that css is fed from a php url. The result is cached on the server as well as in the browser. Another possible approach would be to generate the file on demand, store it on the file system, and return an url to the static content. That would have the benefit of being a bit faster - no php overhead - but we would loose the ability to control http headers. Which means that somebody would need to configure expire headers on the web server to complete the configuration. So I left the things the way they are.
5. Note that images have the same issues. In theory somebody need to turn on expire headers on the server side and, if you do that, you browser will likely not refresh unless you change the url. So we may work on that in the future.
Dear fellow developersAs you all may know we have been discussing the topic of caching in chamilo a few weeks ago on the mailing list. As far as i know there was not a real decision about how it would be implemented and who would implement it. Though there was no real decision i have noticed that some of you already did some kind of implementation of caching (both as an optional app and in the core). I do not like the idea that it already has been implemented in the core since there was no real decision about the caching . I'd rather have some kind of proof of concept that it's really easy and good to use with the use of an optional application.I do realize that we are all on a very tight schedule and that we need to make sure we get finished in time but we should try to avoid implementing some quick solutions without proper analysis because of the deadlines. This will cause our platform to become as chaotic as the software we once came from...I propose that we try to discuss these matters and try to reach an agreement before implementing them (with proper analysis and planning of who will do what and when). If an agreement can not be found about these kind of topics then I propose that our software coordinator, Hans, takes the final decision.
-- ____________________________________ Meilleures salutations Laurent Opprecht chat: laurent.oppre...@gmail.com blog: http://ciel.unige.ch/
<<attachment: laurent_opprecht.vcf>>
_______________________________________________ Dev mailing list Dev@lists.chamilo.org http://lists.chamilo.org/listinfo/dev
