openerp-dev-web team mailing list archive

[Amit Mendapara <mendapara.amit@xxxxxxxxx>]

I was always cautious about these changes since it was decided to go with
Ajax loading of view contents. Because the web client is not implemented
keeping this scenario in mind and that's why I have suggested to go with
IFRAME based solution.

I have already fixed few issues created by repeated loading of JavaScript
files. Few in calendar/gantt view and few in datetime calendar picker. I
admit, those were really hard to debug.

Anyway, the idea of using json response is good and can be done with
`expose` decorator by checking content-type header of the request. If it is
`application/json` or `text/javascript` we will generate json output else we
will generate html output by rendering entire template. With first case,
instead of rendering entire template we well render the top level widget (in
most cases it is `form` widget) as html and `JSLink, CSSLink` as `static` in
this format:

{
    'jslinks': [list of javascript links'],
    'jssource': [list of inline javascript snippets'],
    'csslinks': [list of css links],
    'html': 'the output of widget template'
}

In browser window, we should keep track of which javascript/css links have
already been loaded and those links should be skipped. The `jssource` should
always be executed.

There are two type of inline javascript code, one is created with JSSource
and another is embeded directly in templates. The later will be part of
html.

I think this might take about 4-6 weeks to implement a fully functional
solution. Though, this is my rough calculation but if it's going to
implemented I think, it should be implemented before 6.0 not 6.1. As, I am
sure there will be lots of issues with this repeated loading of javascript
(including some hidden bugs, browser memory issues etc).

Regards
--
Amit Mendapara

On Mon, Jul 26, 2010 at 1:36 AM, Xavier Morel <xmo@xxxxxxxxxxx> wrote:

> 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<https://launchpad.net/%7Eopenerp-dev-web>
> Post to     : openerp-dev-web@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-dev-web<https://launchpad.net/%7Eopenerp-dev-web>
> More help   : https://help.launchpad.net/ListHelp
>