I've been thinking about an issue with the current web client design, and I'd like to know what you all think about it: the lazy loading of static files in the current design.
Right now (after iframe removal, among other things), it mostly results in re-loading and re-executing JS files we already have, leading to longer load times on new XHR page loads (especially for Firefox, it would seem) and it makes some JS debuggers crap out as they can't make sense of where the JS code they're executing come from (Firebug's debugger is often lost there). And it might be the source of bugs as well. I think that we may be able to define those static files at the add-on level: either fetch them by listing the static/css and static/javascript directories of each loaded module (though it has the issue that the loading order would probably be incorrect) or have a list somewhere, in each module's __openerp__.py or __init__.py for instance, which we could easily query. That way, the core framework would be able to know all the files to load and in which order and could: * In development mode, add links to them in the web page and serve that * In production mode, concatenate all files of a given type, cache it (e.g. in /tmp) and serve *that*, maybe even minimizing the JS or whatever (this could also, maybe, be done statically or on server start). We could also probably handle caching better. Issues which would rise from such a move: * What to do when we suddenly load a new module, which has new static files to the set? * How do we handle JS page/content setup (currently kind-of kludged around via mixes of inline javascript, window.onload and document.ondomready)? * Other bugs by sections of JS simply not designed to work that way (will probably require re-thinking some stuff). The solution I see would be that methods which currently return HTML data (pages) would return a JSON object instead when fetched via JSON. This way, that JSON object could hold: * the content itself, currently served alone * a function name to call on JS insertion, this would be used for events setup in the content area, leading to a usage pattern somewhat similar to jsonp. In that case, the events setup would be functions or methods in the static files already fetched * a list of static files to add to the current set, resulting from the loading of a new module (there would probably be some work to do here: where would the server keep the current client's state? Should the client send its current set of files every time?) * potentially even an 'onbeforeunload'-type file which could be used to cleanup if needed (ideally should not be necessary, events should all be DOM-bound, or maybe bind "global" events on #appContent and replace it every time we change its content, that way events set on that instead of document would be nicely cleaned up) As you can infer, this would be a pretty major refactoring, if only because the current @expose system would have to be partially altered in order to support variable output types (though it might be doable gradually, and it would enable improvements for e.g. attachments handling), but it would also pave way for a better future and force us to be a bit cleaner in how we manage events, and I have no doubt it would also increase the performances of the application by drastically lowering the number of network requests after the initial loading (it would also remove a bit of code from the framework, though it would add some elsewhere as well). For those reasons, I'm not sure whether we should try doing it now before 6.0, or wait until after 6.0 is released and do this for 6.1 (hoping there won't be too many web modules by then). What are your thoughts on this? First of all do you think it's a good idea or not, do you see flaws in the reasoning or problems I have not foreseen myself? Second if you think it's a good enough idea, under which timeframe do you think this should be implemented? For 6.0, or for the release coming after that? Xavier _______________________________________________ Mailing list: https://launchpad.net/~openerp-dev-web Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-dev-web More help : https://help.launchpad.net/ListHelp
