Hi. In the Nevow source distribution there are some JavaScript code but I don't understand what files are actually used. As an example there is defer.js script, but there is also a deferred support in MochiKit. Thanks Manlio Perillo
On Sat, 29 Jul 2006 18:00:55 +0200, Manlio Perillo <manlio_perillo@libero.it> wrote:
Hi.
In the Nevow source distribution there are some JavaScript code but I don't understand what files are actually used.
As an example there is defer.js script, but there is also a deferred support in MochiKit.
I'm not the most entitled person to speak about those choices but MochiKit is currently only used for the Stan-like syntax inside Nevow. The reasons are various and mostly have to do with disagreement in some implementation choices. Basically MochiKit is currently just an implementation detail that nobody should rely on being kept there or updated (currently it's version 1.1). I'm unsure how much I agree with this choice because if from one hand it means that nevow fixes some problems with MochiKit APIs it also means that Nevow will have to maintain its own version of javascript library which is a problem by itself because, for example, the next MochiKit version will also provide a rich package for visual effects, also MochiKit works with all the main browsers while Nevow currently doesn't work with Opera and Safari (because of Safari) and I'm unsure about IE (although I think it works there). anyway I'll let the others complete the answer because they know it better than me.
Hi Valentino, On Sat, 29 Jul 2006 11:24:02 -0500, Valentino Volonghi aka Dialtone <dialtone@divmod.com> wrote: [snip]
I'm unsure how much I agree with this choice because if from one hand it means that nevow fixes some problems with MochiKit APIs it also means that Nevow will have to maintain its own version of javascript library which is a problem by itself because, for example, the next MochiKit version will also provide a rich package for visual effects, also MochiKit works with all the main browsers while Nevow currently doesn't work with Opera and Safari (because of Safari) and I'm unsure about IE (although I think it works there).
Some details regarding browser support: Opera 9 is supported by the current release of Nevow.Athena; also, there is a patch awaiting review that will make Opera as fast, or faster, than any other supported browser for the most common DOM operations that Nevow.Athena performs. IE is fully supported too, although it doesn't get tested as thoroughly as Firefox. Safari is not supported, although it can be as soon as Apple pushes a release that includes a sufficiently updated version of WebKit. I have already done some preliminary hacking on my local runtime.js to enable Safari support, and with the right WebKit, it will work. Whenever the correct WebKit version gets folded into a Safari release, I'll see about providing a decent patch for Nevow.Athena. Hope this helps, L. Daniel Burr
* Valentino Volonghi aka Dialtone <dialtone@divmod.com> [2006-07-29 18:24:02 +0200]:
On Sat, 29 Jul 2006 18:00:55 +0200, Manlio Perillo <manlio_perillo@libero.it> wrote:
Hi.
In the Nevow source distribution there are some JavaScript code but I don't understand what files are actually used.
As an example there is defer.js script, but there is also a deferred support in MochiKit.
I'm not the most entitled person to speak about those choices but MochiKit is currently only used for the Stan-like syntax inside Nevow.
It is? I believe usage of MochiKit.DOM for this purpose is "deprecated" within Divmod itself, but there may be some isolated uses. The main dependency blocking MochiKit's removal is the client-side JSON serialization functionality.
The reasons are various and mostly have to do with disagreement in some implementation choices. Basically MochiKit is currently just an implementation detail that nobody should rely on being kept there or updated (currently it's version 1.1).
Specifically, an Athena transport implementation detail.
I'm unsure how much I agree with this choice because if from one hand it means that nevow fixes some problems with MochiKit APIs it also means that Nevow will have to maintain its own version of javascript library which is
These APIs do not overlap all that much; in many cases, Athena can provide a far richer API for certain things than MochiKit could, simply because of the Widget hierarchy. (eg. the nodeByAttribute Widget method)
a problem by itself because, for example, the next MochiKit version will also provide a rich package for visual effects, also MochiKit works with all the main browsers while Nevow currently doesn't work with Opera and Safari (because of Safari) and I'm unsure about IE (although I think it works there).
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.
anyway I'll let the others complete the answer because they know it better than me.
Basically, it's a mostly orthogonal issue. -- mithrandi, i Ainil en-Balandor, a faer Ambar
On Sat, 29 Jul 2006 22:15:08 +0200, Tristan Seligmann <mithrandi-twisted-web@mithrandi.za.net> wrote:
It is? I believe usage of MochiKit.DOM for this purpose is "deprecated" within Divmod itself, but there may be some isolated uses. The main dependency blocking MochiKit's removal is the client-side JSON serialization functionality.
I didn't know JSON was involved too, but MochiKit.DOM is used throughly in Divmod's Quotient.
a problem by itself because, for example, the next MochiKit version will also provide a rich package for visual effects, also MochiKit works with all the main browsers while Nevow currently doesn't work with Opera and Safari (because of Safari) and I'm unsure about IE (although I think it works there).
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. 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).
* Valentino Volonghi aka Dialtone <dialtone@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...
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. -- mithrandi, i Ainil en-Balandor, a faer Ambar
Tristan Seligmann wrote:
* Valentino Volonghi aka Dialtone <dialtone@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?
* Phil Mayers <p.mayers@imperial.ac.uk> [2006-07-31 15:57:46 +0100]:
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.
You could make XHR calls via this reverse-proxy using the Athena primitives for XHR, though.
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.
I don't see any reason why Athena has to replace MochiKit. For the most part, the two libraries are completely orthogonal. If you want to use MochiKit's JSON-RPC functionality, nothing is stopping you.
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.
MochiKit does not implement any kind of peristent HTTP transport, so this seems a moot point.
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.
I'm not personally concerned with this use case, so I'm not likely to spend any time on implementing this. I would imagine that patches to refactor Athena's Widget code to be less dependent on the Athena client-server transport would be accepted, though, so others are free to do the work to implement this.
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 point is that nothing is stopping you from doing this, so far as I can see.
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?
There are no "fixes". The copy of MochiKit distributed in Nevow is completely unmodified so far as I am aware (even if it isn't the latest version). There is Athena-specific functionality, not implemented at all by MochiKit, that requires either certain browser functionality, or browser-runtime-specific code. For example, the Divmod.Class system results in widespread idiomatic usage of named function expressions. Safari's JavaScript parser chokes on this as invalid syntax, hence the lack of Safari support. As was pointed out elsewhere, this problem has been fixed in WebKit upstream, so will presumably make its way into Safari at some point; when this happens, doing the rest of the work to support Safari should not be very difficult. This is basically all completely orthogonal functionality, however; Athena is not reimplementing large portions of MochiKit verbatim, it is implementing different functionality in different ways, with a few exceptions such as XHR and Deferred. Once the MochiKit dependency in Athena is completely gone, there will be no need to distribute MK alongside Athena, and thus developers will be free to include whatever version of MochiKit they wish for their own use, without having to jump through hoops. -- mithrandi, i Ainil en-Balandor, a faer Ambar
participants (5)
-
L. Daniel Burr -
Manlio Perillo -
Phil Mayers -
Tristan Seligmann -
Valentino Volonghi aka Dialtone