[Twisted-web] [Nevow] JavaScript code
Phil Mayers
p.mayers at imperial.ac.uk
Mon Jul 31 09:57:46 CDT 2006
Tristan Seligmann wrote:
> * Valentino Volonghi aka Dialtone <dialtone at divmod.com> [2006-07-29 22:48:09 +0200]:
>
>>> If you want to use MochiKit in your own code, there's not too much
>>> stopping you; currently, it is problematic to try and use a different
>>> version of MochiKit to the one distributed with Nevow, but once this
>>> dependency is completely phased out, that problem will no longer exist.
>> Of course. I might use dojo toolkit as well. But having two different
>> deferreds implementations in the same code is quite difficult to deal with.
>
> Is there anything besides XMLHTTPRequest that you would use MochiKit's
> deferreds for? If you're using Athena, you don't have any need for
> MochiKit's XHR support, so this seems to be a non-issue...
I can think of several reasons one might want MochiKit.
Due to the security model protecting XMLHTTP requests, you can only make
requests back to the same origin server. Therefore, if you want to call
an external (non-Twisted, non-Nevow, non-Athena) application from your
Athena page, you might choose to glue that application into your server
URL space using server-side reverse proxying.
If Athena is to replace MochiKit, it would need to provide at least as
good primitives for e.g. JSON-RPC. If it does not, you'd still need a
library to do so.
In *addition*, my understanding was that many (most?) browsers limited
the number of outstanding HTTP requests you may have to a given server
to 2. Therefore, running >2 "event loops" for XMLHTTP requests to e.g.
different application spaces is impossible. If you happen to have 3
application spaces deployed into your URL hierarchy, well, tough.
It is an unfortunate choice for some of us.
Finally, I think it's worth pointing out that one might want to use the
Nevow+Athena code for widgetry and so forth, but if one already had an
application API as e.g. JSON-RPC calls, exposing those calls *again* to
an "implementation is internal detail" Athena channel is at best time
consuming boilerplate, and at worst bug-riddled and insecure.
Athena-JS is more like a domain-specific language IHMO. It's not
unreasonable to want to code the non-athena specific bits to a more
general JS platform/framework/library.
My 2pence
>
>> And also using mochikit would only solve the visual effects problem,
>> whereas the browser compatibility problem won't be solved (not that I
>> especially care about the bugged safari).
>
> Increasing the usage of MochiKit in Athena would not solve the browser
> compatibility problem either: the lack of support for various browsers
> stems from functionality that is not implemented in MochiKit at all.
It seems a peculiar choice to not just fold those fixes back into
MochiKit. The upstream developer(s) have good reputations for being
sensible people, do they not?
More information about the Twisted-web
mailing list