Re: [mochikit] Does anyone use this?
MochiKit was started specifically because Prototype didn't suit my needs and didn't have sufficient docs or tests :) On Thu, May 25, 2017 at 23:56 Arnar Birgissonwrote: > Prototype was one of the main contenders towards the end, before jQuery > took over. When I started using mochi it was between it and mootools > however (winter 2005-2006). jQuery, and I think Prototype as well, came > later. I distinctly remember picking mochikit because of its documentation > and module structure. > > Must say thanks to Bob, Thomas, and Per for putting it out and > maintaining. It was an enormous value in my work back then, and I'm sure > that code is still running at my old company. > > ab > > On Thu, May 25, 2017 at 11:32 PM troels knak-nielsen < > tro...@knak-nielsen.dk> wrote: > >> Whoa. Blast from the past. >> >> Mochi was way ahead of the curve 10 years ago. I used it last around >> 2009. At that point jquery had sort of taken the position, as I remember it. >> >> For sake of a bit of code archeology, there were definitely other tool >> kits even before Mochi. I think xb (xbrowser?) was one of my go-to staples >> for a while. >> >> T >> >> On Fri, 26 May 2017 at 05.01, Chaz Gatian >> wrote: >> >>> I stumbled upon MochiKit for the first time tonight, and it completely >>> blew my mind. >>> >>> I started web development eight years ago, and have never heard of such >>> a tool. It's so interesting to read the blogs, and issues from the past. >>> From what I can tell this library seems like the first framework to try to >>> solve all the different browser quirks, something I always thought jQuery >>> was the first to accomplish. But now having learned about this framework, I >>> might be *VERY *wrong! >>> >>> If anyone still frequents this group please say something, I'm curious >>> to know if anyone is still using this in applications today. >>> >>> -Chaz >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "MochiKit" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to mochikit+unsubscr...@googlegroups.com. >>> To post to this group, send email to mochikit@googlegroups.com. >>> Visit this group at https://groups.google.com/group/mochikit. >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "MochiKit" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to mochikit+unsubscr...@googlegroups.com. >> To post to this group, send email to mochikit@googlegroups.com. >> Visit this group at https://groups.google.com/group/mochikit. >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "MochiKit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mochikit+unsubscr...@googlegroups.com. > To post to this group, send email to mochikit@googlegroups.com. > Visit this group at https://groups.google.com/group/mochikit. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "MochiKit" group. To unsubscribe from this group and stop receiving emails from it, send an email to mochikit+unsubscr...@googlegroups.com. To post to this group, send email to mochikit@googlegroups.com. Visit this group at https://groups.google.com/group/mochikit. For more options, visit https://groups.google.com/d/optout.
Re: [mochikit] Does anyone use this?
I don't think anyone is building anything new on MochiKit at this point. We sure did pioneer a lot of stuff people are doing today over a decade ago, but frankly all of the ideas are really just from other places outside the browser :) On Thu, May 25, 2017 at 20:01 Chaz Gatianwrote: > I stumbled upon MochiKit for the first time tonight, and it completely > blew my mind. > > I started web development eight years ago, and have never heard of such a > tool. It's so interesting to read the blogs, and issues from the past. From > what I can tell this library seems like the first framework to try to solve > all the different browser quirks, something I always thought jQuery was the > first to accomplish. But now having learned about this framework, I might > be *VERY *wrong! > > If anyone still frequents this group please say something, I'm curious to > know if anyone is still using this in applications today. > > -Chaz > > -- > You received this message because you are subscribed to the Google Groups > "MochiKit" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to mochikit+unsubscr...@googlegroups.com. > To post to this group, send email to mochikit@googlegroups.com. > Visit this group at https://groups.google.com/group/mochikit. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "MochiKit" group. To unsubscribe from this group and stop receiving emails from it, send an email to mochikit+unsubscr...@googlegroups.com. To post to this group, send email to mochikit@googlegroups.com. Visit this group at https://groups.google.com/group/mochikit. For more options, visit https://groups.google.com/d/optout.
Re: [mochikit] Multiselect List
On Sun, Oct 16, 2011 at 6:09 AM, Jurgens de Bruin debrui...@gmail.com wrote: Hi, I am very new to mochiKit and would appreciate some help. I have a form containing a multi-select list, I am try to use AJAX and JSON to produce async tasks. Currently I can't get all the selected elements from the multi-select list passed to the server. How can I obtained all selected elements from the list after submit has been click? http://mochi.github.com/mochikit/doc/html/MochiKit/Signal.html#fn-connect https://developer.mozilla.org/en/DOM/element.onchange http://mochi.github.com/mochikit/doc/html/MochiKit/DOM.html#fn-formcontents http://mochi.github.com/mochikit/doc/html/MochiKit/Base.html#fn-serializejson http://mochi.github.com/mochikit/doc/html/MochiKit/Async.html#fn-doxhr http://mochi.github.com/mochikit/doc/html/MochiKit/Async.html#fn-evaljsonrequest -bob -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Is MochiKit Dead?
Good idea. Done! On Mon, Aug 15, 2011 at 4:20 AM, Chris Snyder chsny...@gmail.com wrote: Not Dead: Feature Complete. Since this issue comes up every year or so, I think there should be a simple explanation on the website homepage, something like: MochiKit is considered feature complete at version 1.4, and is therefore not in active development. It simply does what we have needed it to do for quite a few years so we haven't bothered to make any major changes to it. Contributions and improvements are welcome via GitHub. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Is MochiKit Dead?
On Sat, Aug 13, 2011 at 11:35 AM, machineghost machinegh...@gmail.com wrote: So, given that: * There hasn't been a blog post on the website in ... ever (according to the front of the site; in reality there was a post back in 2008) * There hasn't been a release since 2008 * This mailing list gets a post (with no response) once every other month or so, if that * MochiKit is less popular than random frameworks I've never heard of (xajax? what's that?) by a factor of six (http://www.readwriteweb.com/ hack/2011/08/javascript-framework-popularit.php) it really seems like MochiKit is a dead project, or at best a zombie project. Is that accurate? I mean, obviously people currently using it aren't going to stop, but is new development, promotion of the framework, improvement of the website/docs/etc. dead? Zombie sounds about accurate to me, we still use it but it's done what we've needed it to do for quite a few years so we haven't bothered to make any changes to it. We don't have a lot of incentive to encourage other people to use it, especially at this point. If someone is interested in making improvements they're more than welcome to do so, it's all pretty much github based these days so accepting pull requests, adding contributors and updating the site is very easy. -bob -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] MochiKit.I18n -- proposed new module for internationalization
This is pretty cool, something I always imagined that I might do if I were doing this kind of localization. We've only done en and zh at Mochi, so haven't needed anything outside of the system format. On Mon, Jan 10, 2011 at 6:38 PM, Per Cederberg cederb...@gmail.com wrote: Since I found the MochiKit.Format.formatLocale() function too limited, I hacked up a new MochiKit.I18n module: https://github.com/cederberg/mochikit/blob/i18n/MochiKit/I18n.js It is backwards compatible and adds locales for most languages on earth (data derived from Wikipedia and Google Closure sources). At the moment it only contains numeric formatting information, but can be extended with currency and datetime formatting information if needed. My intention is to include this in the default MochiKit 1.4 tree and update the MochiKit.Text module to properly support the number formatting specified in these locales (some are not currently supported). Please let me know if you have any issues with this. Cheers, /Per PS. Pasting in the source rst docs below to give a clue as to how it is supposed to work. Name MochiKit.I18n - internationalization, localization and globalization Synopsis :: assert( locale().decimal == . ); assert( locale(sv_SE).decimal == , ); Description === This module contains numeric localization information for most languages and regions on earth. Actual text formatting lives in other modules (such as :mochiref:`MochiKit.Text`). Dependencies - :mochiref:`MochiKit.Base` Overview Locale Names MochiKit uses IETF language codes [1] to identify a locale, e.g. ``en_US``. The locale database also supports the use of previously unknown locale identifiers by creating a new locale based on the language code or the default locale. A number of built-in locale identifiers are also supported: +-+-+ | Language | Description | +=+=+ | ``system`` | The built-in system locale. It is identical to a | | | ``en_US`` locale for backward compatibility. | +-+-+ | ``user`` | The user locale, as reported by the browser. This | | | points to a specific language locale (or the | | | ``system`` locale.) | +-+-+ | ``default`` | The default locale, used when no language code is | | | provided. This points to the ``system`` locale by | | | default. | +-+-+ The default locale is modified by accessing the ``MochiKit.I18n.LOCALE`` cache of resolved locale objects: :: MochiKit.I18n.LOCALE[default] = locale(user); Locale Objects -- The locale objects returned by :mochiref:`locale()` and stored in the ``MochiKit.I18n.LOCALE`` cache all have the following properties (some inherited through the prototype chain): +-+-+ | Name | Description | +=+=+ | ``decimal`` | The decimal dot character. | +-+-+ | ``separator`` | The thousands grouping character. | +-+-+ | ``separatorGroups`` | The size of thousands groups (from | | | right to left). Repeats when exhausted. | +-+-+ | ``percent`` | The percent character. | +-+-+ | ``permille`` | The permille character. | +-+-+ | ``plus`` | The plus sign character. | +-+-+ | ``minus`` | The minus sign character. | +-+-+ | ``signAtEnd`` | The boolean sign at end of string flag. | +-+-+ | ``infinity`` | The infinity character. | +-+-+ API Reference = Functions -
Re: [mochikit] Mochikit.signal and DOM objects that don't exist yet (like jQuery.live)
That said, I think jQuery Live style functionality is useful, and I certainly wouldn't mind seeing some additional module to support it. However, all existing MochiKit functionality works only on the current state of the DOM and it is not a bug that it doesn't consider future changes to the DOM that may match the id or selector given. On Sat, Dec 4, 2010 at 5:58 PM, Per Cederberg p...@percederberg.net wrote: Thanks for your input to the project, but I don't think we can consider this a bug. Referring to objects that do not yet exist is an error in almost any programming language, so it is to be expected. The MochiKit docs do not explicitly make it clear that the id lookup is immediate, but they definitely do not discuss any lazy or delayed lookup of the signal source. The documentation is explicit regarding that the destination slot will be looked up on the first signal, though. In your case, why wouldn't you just attach the signal when creating the element? Otherwise you'd have to listen to any DOM modification and possibly attach signals to elements added. And that use case sounds pretty specific to me. BTW. If you'd like to contribute patches to the MochiKit project, it would be much easier if you forked the project on GitHub I think. The move happened quite recently, so I haven't moved all my own patches yet, but by forking on GitHub it becomes much easier for us maintainers to pick up patches and ideas. Cheers, /Per On Fri, Dec 3, 2010 at 16:37, ryanwil...@gmail.com ryanwil...@gmail.com wrote: Hi all, I was playing around with MochiKit.Signal, specifically asking the question: Can I use MochiKit.Signal.connect to set event handlers for objects that don't exist yet. Like so: // connect to our make a new button button MochiKit.Signal.connect(button_that_exists, 'onclick', function(evt ) { var new_button = MochiKit.DOM.BUTTON({'id': newly_created_button}, Hello world, I'm new); MochiKit.DOM.appendChildNodes( MochiKit.DOM.getElement(main_content_div), new_button ); }); MochiKit.Signal.connect(newly_created_button, 'onclick', function(evt) { alert(hey world); }); NOTE that newly_created_button won't exist until the user clicks the button_that_exists. When I try this I get an error in MochiKit.Signal, about src being null. Is this a bug (MochiKit.Signal should allow connecting to DOM objects that don't exist yet), or a limitation of how MochiKit.Signal was designed (MochiKit.Signal.connect supports only objects that live on the DOM when it is called)? I do see that MochiKit.Signal.signal DOES seem to support the src object being a string, so I suspect the former answer. If it is the former answer (if this error is a bug) I can try to put together a patch to try and allow this behavior, BUT I wanted to check before I went down this road. To see my full example, I've pushed it up to Bitbucket (as part of a learning repository, so there's a lot of extra stuff in there :( ): http://bitbucket.org/rwilcox/learning_javascript/src/tip/MochiKit/ signals_and_slots/ -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Re: Iter: __iterable__ support?
If I remember correctly the problem is that __iterator__ was defined on Object.prototype (to iterate over keys), so everything had it, and it made the registry worthless. Maybe if we moved that code to after the registry, or maybe checked to see if iterator.__iterator__ !== Object.prototype.__iterator__ before the registry, and then just a regular check after. It looks like they moved that behavior to Iterator though, so maybe it's ok to bring back. On Sun, Nov 21, 2010 at 7:55 AM, Fredrik fblomqv...@gmail.com wrote: FYI, here the actual links to the changes: adding __iterator__: https://github.com/mochi/mochikit/blob/b54de3b0429396cb86edd2c1ade0860831b65379/MochiKit/Iter.js .. dropping __iterator_: https://github.com/mochi/mochikit/blob/3022d8755cf932a9581f0ba19134472a368c6d64/MochiKit/Iter.js On Nov 21, 12:51 am, Fredrik fblomqv...@gmail.com wrote: Hi. In Iter.js I find this, regarding the support for the __iterator__ pattern. //--- // XXX: We can't support JavaScript 1.7 __iterator__ directly // because of Object.prototype.__iterator__ //--- In Git/SVN the only message to the (reverted) change (2006-05-18) is oops :) The Google Closure library seems to sniff for it for example, see:http://closure-library.googlecode.com/svn/docs/closure_goog_iter_iter... Is this still applicable? Supporting __iterable__ would be very useful I'd say. .. Guess this more or less a question for Bob himself but if anyone has knowledge about this issue please enlighten! Regards // Fredrik Blomqvist -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Code comments in MochiKit sources
It was for Aptana, not sure if anyone still cares? On Tuesday, October 12, 2010, Per Cederberg cederb...@gmail.com wrote: Does anyone (Bob?) know why the MochiKit source code has these types of comments for most exported functions: /** @id MochiKit.Signal.connect */ Cheers, /Per -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
[mochikit] MochiKit moving to github
I'm in the process of moving MochiKit to github to remove the maintenance burden from the Mochi ops team, and make it easier to contribute. We're in the process of switching everything to git internally anyway, so it's about time: http://github.com/mochi/mochikit I think that we'll just go ahead and use github pages for the site once the transition is complete. I have most of it set up here (the customize functionality still uses SVN): http://mochi.github.com/mochikit We haven't migrated anything in Trac yet. I'm not sure how much of it is really useful these days. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] svn.mochikit.com and trac.mochikit.com down
It looks like the ops team at Mochi has decommissioned the machine it runs on without realizing that services were still hosted there. I've filed a ticket to get these services back up, hopefully they haven't destroyed it entirely. On Thu, Oct 7, 2010 at 1:20 AM, Ethan Jucovy ethan.juc...@gmail.com wrote: Hi, I noticed yesterday that http://svn.mochikit.com and http://trac.mochikit.com are down. They seem to still be down today. http://downforeveryoneorjustme.com/svn.mochikit.com Has the mochikit repository moved somewhere else? Thanks, Ethan -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] SpiderMonkey and MockDOM Issues
No idea what you're trying to do but it sounds like whoever packaged this with Ubuntu did the wrong thing. Surely there must be an up to date mirror of mochikit on github or something that can be used until service is restored. On Thu, Oct 7, 2010 at 1:25 AM, Kaleb Hornsby theka...@gmail.com wrote: I am running Ubuntu and have just discovered MochiKit in the repositories. I attempted to start it with smjs, but I ran into an error. I apparently needed MochiKit.MockDOM. I found it [online] [1] on another site than mochikit's because their track server is down. This seemed rather old. Sure enough, though, I loaded mockdom.js and then loaded mochikit.js and it solved the error, but created another. Sample output: $ js js load('MochiKit.js') MochiKit.js:3506: TypeError: this._document has no properties js load('MockDOM.js') js load('MochiKit.js') MochiKit.js:4323: ReferenceError: navigator is not defined js Does somebody have a more recent version of mockdom that works with mochikit? [1]: http://bknr.net/trac/browser/trunk/projects/quickhoney/website/static/MochiKit/MockDOM.js?rev=2828 -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Re: SpiderMonkey and MockDOM Issues
MochiKit provides MockDOM so that some tests can be run without a full browser environment. It does not exist for server-side programming purposes, it was built before that was a really sensible thing to do. On Thu, Oct 7, 2010 at 9:21 PM, Kaleb Hornsby theka...@gmail.com wrote: Since MochiKit makes JavaScript a more robust programming language, I am trying to use both to do some server side programming. That's why MochiKit provides a MockDOM. I think that overall, it should not be coupled to the DOM at all. On Oct 7, 7:54 am, Bob Ippolito b...@redivi.com wrote: No idea what you're trying to do but it sounds like whoever packaged this with Ubuntu did the wrong thing. Surely there must be an up to date mirror of mochikit on github or something that can be used until service is restored. On Thu, Oct 7, 2010 at 1:25 AM, Kaleb Hornsby theka...@gmail.com wrote: I am running Ubuntu and have just discovered MochiKit in the repositories. I attempted to start it with smjs, but I ran into an error. I apparently needed MochiKit.MockDOM. I found it [online] [1] on another site than mochikit's because their track server is down. This seemed rather old. Sure enough, though, I loaded mockdom.js and then loaded mochikit.js and it solved the error, but created another. Sample output: $ js js load('MochiKit.js') MochiKit.js:3506: TypeError: this._document has no properties js load('MockDOM.js') js load('MochiKit.js') MochiKit.js:4323: ReferenceError: navigator is not defined js Does somebody have a more recent version of mockdom that works with mochikit? [1]:http://bknr.net/trac/browser/trunk/projects/quickhoney/website/static... -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/mochikit?hl=en. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Mochikit.js does not download from Apache 2.2.3 on Centos 5.4/5.5
That's strange, I'm not seeing any problem with Firefox or Chrome on Mac. On Wed, Jun 9, 2010 at 11:42 AM, jonauman jonau...@nescent.org wrote: The file hangs at 8% download using curl. However, if I copy the javascript to a Mac server and I can download the file. I am not able to access http://mochikit.com via Firefox or curl on my Mac with Snow Leopard. I am able to do so in Safari on my Mac. jonauman:~ jonauman$ curl -O http://www.mochikit.com/include/_js/MochiKit/MochiKit.js % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 11 110k 11 13376 0 0 551 0 0:03:25 0:00:24 0:03:01 0 As you see, it hangs at 11% It was working a few days ago, and stopped working yesterday. Any ideas? -Jon -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Additional information for a bug
Well, the implementation of MochiKit's keys function was written years before any of the browsers implemented an Object.keys function. It's unfortunate that they don't do exactly the same thing, but changing the implementation of MochiKit's keys would break existing code. On Mon, Apr 26, 2010 at 7:46 PM, Saikat Chakrabarti saik...@gmail.com wrote: I couldn't find a way to comment on a bug I just filed (https:// trac.mochikit.com/ticket/365) but here is a sample implementation that would do the correct thing: http://gist.github.com/380263 (from http://ejohn.org/blog/ecmascript-5-objects-and-properties/). -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Providing patch for ticket #361
You can send it here to the list On Thu, Feb 18, 2010 at 3:18 AM, niek.kouwenb...@gmail.com niek.kouwenb...@gmail.com wrote: Hi, I've just created a ticket for which I have a patch. Since editing and replying to tickets seems to be disabled since 2008, I have no way of attaching this patch. Since I've been using MochiKit quite some time now in several projects, I am keen on helping a little with development (which seems rather slow). Not being able to provide patches or comment to tickets seems to make this really hard and might kill MochiKit future. Where do I send my patch? -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] JSON.parse MochiKit.Base.evalJSON
On Sat, Nov 28, 2009 at 2:18 PM, Per Cederberg cederb...@gmail.com wrote: I just tried to modify MochiKit.Base.evalJSON() to use the new JSON.parse() function when available. This would give us the following advantages: 1. Speed (but, well... eval() is probably fast enough already) 2. Security Unfortunately we would also get a nasty regression issue due to the stricter syntax enforcement in JSON.parse() vs. eval(). None of the apps we've written depend on the capability to parse invalid JSON, so it wouldn't bother me. -bob -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
[mochikit] Re: MochiKit.DOM.getElementsByTagAndClassName performance
At least with recent browsers there are better ways to speed this up, e.g. by leveraging more native code (getElementsByClassName and/or XPath). None of them did this when the code was written in 2005 but I think all of them do now (except maybe IE). On Tue, Nov 3, 2009 at 11:14 PM, Per Cederberg cederb...@gmail.com wrote: Generally, I think some of these optimizations make sense. Like using === instead of == in code like this: typeof(x) === string But I think the optimizations where variables are moved outside code blocks and where array lengths are stored to variables should be used with extreme caution. These are the type of things that people used to recommend for Java code, but nowadays the virtual machines optimize these things better by themselves. And what used to be a speedup actually often leads to decreased performance. For JavaScript, the VM:s are much more immature. But they are rapidly becoming faster and more advanced. So low-level code optimizations that result in a speedup today, might not do so just a year or two down the road. I think our focus here should be on clarity of intention. If some critical-path function is extremely slow, we might want to have a look at optimizing that specific function. But in general I think we should refrain from low-level code optimizations that doesn't also improve code readabilty and reduce the frequency of bugs. Also, if speed is a problem, most serious speedups come from changes to the algorithms and data structures involved. In this case for instance, it might be faster to first find elements by class and then filter out the ones with the correct tag. Or by using an indexOf(class) on the className field before splitting it up. These kind of optimizations will probably result in higher gains with less reduction to the code readability. Just my 2 cents. Cheers, /Per On Tue, Nov 3, 2009 at 23:23, takashi mizohata bea...@gmail.com wrote: Hi All, Forgive me, if this is a recurring argument. Today I was looking at Firebug profiler and I realize that getElementsByTagAndClassName takes certain percentages of processing time. And I took a look at the code, and I did a little bit of hand optimization. It doesn't change any semantics of code, but just organizing code. It does pass the tests of course. And i got around 6% better performance. Well the down side of this tweak may be the decrease of readability. Since you need to carefully type comma between local variables. I usually check it with jslint before commit in order to find those potential mistakes. And obviously I don't much about coding convention of MochiKit and I might need to edit the style of it. Here I attached .patch file for this issue. Please try it and let me know what you think. if somebody's interested in, I can contribute some more performance tweaks in MochiKit. Thanks, -- Takashi M --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Base.js unescape reassignment and intrusion protection systems
There are various ways it could be rewritten, but without knowing exactly how stupid the IPS is it's hard to say which permutation would pass its test. Someone who can reproduce this issue should spend some time with it and produce a patch. On Thu, Jul 16, 2009 at 6:34 PM, Michaelmstras...@gmail.com wrote: I have found a problem with MochiKit Base.js and the intrusion protection system at work. The IPS truncates Base.js because it assigns the unescape() function to a variable (in parseQueryString(), line 1225 in version 1.4.2 of Base.js). The IPS response is documented here: http://www.iss.net/security_center/reference/vuln/JavaScript_Unescape_Obfuscation.htm Has anybody else seen this behaviour? Could the code be re-written to not use that reassignment? (I discovered this because MarkMail does not work, and it uses a compressed version of MochiKit 1.4.) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Mapi function
Did you read the sentence that I wrote? izip(count(), someArray) does the indexes. On Wed, May 20, 2009 at 7:32 AM, Rupert Bates rupert.ba...@gmail.com wrote: Thanks for the reply, so that answers the alternate rows case, but there are plenty of other cases where you would want to know the index of the item. The items() solution feels like a bit of a workaround and presumably has performance implications. Would a mapi function not be more efficient and elegant? Sorry if I'm missing something. Rupert On May 19, 4:13 pm, Bob Ippolito b...@redivi.com wrote: Typically this is done with count or cycle and izip. izip(cycle([odd, even]), someArray) On Tue, May 19, 2009 at 2:19 AM, Rupert Bates rupert.ba...@gmail.com wrote: Hi there, how about adding a mapi function to Mochikit.Iter which passes the index of the item being processed to the specified function? It would be really handy, for instance for specifying altenate rows on a table. Rupert --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Mapi function
Typically this is done with count or cycle and izip. izip(cycle([odd, even]), someArray) On Tue, May 19, 2009 at 2:19 AM, Rupert Bates rupert.ba...@gmail.com wrote: Hi there, how about adding a mapi function to Mochikit.Iter which passes the index of the item being processed to the specified function? It would be really handy, for instance for specifying altenate rows on a table. Rupert --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: doSimpleXMLHttpRequest, IE and non ascii characters
You probably need to use encodeURIComponent. 2009/4/16 Boštjan Jerko ml...@japina.eu: Hi! I am using MochiKit 1.4 and have a simple usage of doSimpleXMLHttpRequest: var handleServerFeedback = function(result) { log(d_querystring); } var handleServerError = function() { log(error); } returnedServerValue = new doSimpleXMLHttpRequest(/ showContent/?f_name=+d_querystring); log(d_querystring); returnedServerValue .addCallbacks(handleServerFeedback,handleServerError); When I use the script on any browser it works perfectly, but when I set d_querystring with some non standard text characters or non ascii characters it doesn't work on Internet Explorer - it works in Firefox. I did a RSS reader and when I have a feed caled: Avian’s Blog it doesn't work. Mind that there is a #96; character in the name. The problem also appears when I use some Slovene characters (e.g. ccaron - č). Any ideas why is this happening? B. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: why use MochiKit.Base.update to create the mochikit object hierarchy?
The reason I chose not to hide methods in a scope is so that you could monkeypatch them if you needed to. In retrospect I probably should've just done it in a scope because it would make the code smaller. Using an object literal was the compromise I chose between assigning each property by themselves and using a closure. On Sun, Mar 29, 2009 at 11:56 AM, Per Cederberg cederb...@gmail.com wrote: I think Bob is the best person to answer this, but in the current version of the code MochiKit.DOM, MochiKit.Style and friends are all created by the MochiKit.Base._module function. This function automatically inserts a few practical helpers, such as the module name, __repr__() and toString(). So by using a call to update(), these generated helper properties are kept intact. An alternative would of course be to assign each property by itself: MochiKit.DOM.currentWindow = ... MochiKit.DOM.currentDocument = ... But I think people would consider this too verbose. I don't mind myself though, because I think it would increase the code clarity somewhat. Anyway. The correct way of doing a library nowadays I think is this: (function(scope) { ... declare stuff ... ... export selected resources into 'scope.MochiKit.DOM' ... })(this); That would hide internal methods securely inside an inner scope. But sometimes the internal methods are quite handy of course... Cheers, /Per On Sun, Mar 29, 2009 at 3:26 PM, Freek Zindel zin...@gmail.com wrote: When looking at the source code for MochiKit I found that the object hierarchy is created with calls to update. e.g.: MochiKit.Base.update(MochiKit.Dom,{...}); I am eager to learn about the rationale for doing this so that I may enhance my understanding of javascript. What is the advantage of using this technique over an assignment such as: MochiKit.Dom = {...} I am aware of the benefit of having the option to call update several times, each time adding some extra functionality to an object. But if only one call to update is made for a specific part of the MochiKit tree wouldn't the work that update does just be extra overhead? Or are there other benefits? Best regards, Freek Zindel --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Defered.setFinal
Finalizing a Deferred should ensure that no further callback/errbacks are registered and it should attach a default error handler (success should be no-op). The most common problem I've seen with Deferreds is that an error occurs but nobody attached an error handler that far down the stack. In Python they work around this by having a finalizer so that you see the error when the object gets GC'ed, but that's not really possible in JS since you don't have finalizers or weak references. On Tue, Feb 10, 2009 at 8:04 AM, Per Cederberg cederb...@gmail.com wrote: I think this is a good idea. I needed something similar too, so I ended up writing an ugly hack that worked most of the time... d.addBoth(function (res) {d.addBoth(finalFunc); return res; }); It adds new callback once the first deferred result drops in, hopefully after all the other callbacks have been added... But a more formally correct solution would probably be a good idea. Cheers, /Per On Tue, Feb 10, 2009 at 2:30 PM, Amit Mendapara mendapara.a...@gmail.com wrote: Hi Per, I have just started again improving the MochiKit Extensions. While creating tests for the Ajax module, I found one problem (not bug, but specific to the feature I'm trying to implement). I registered a callback which should be fired at the end of all registered callbacks. I achieved by modifying Async.js with a new method `setFinal` (not addFinal as there should be only one finalizer) which gets fired when `chain.length == 0`. It's simple. I would we happy if you add one such function in MochiKit.Async.Defered... Regards -- Amit --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Curry and uncurry
The difference between currying and partial application is that you can call a curried function f with 1 argument that needs N arguments and the return value is a function f_1 that needs N-1 arguments and when called again with 1 argument will return a function f_2 that takes N-2 arguments, etc. until some point where N-K=0 and it returns a value instead of another function. It's effectively a transform that wraps a function f(a, b, c) with something like this: function (a) { return function (b) { return function (c) { return f(a, b, c); } } } Partial application explicitly takes a function with N arguments and returns a function that takes N-K arguments but the resulting function behaves the same as any other function in JS without that magic. I'm not a real big fan of currying in languages where it's not built-in. It's easy to make a mistake by calling a function with too few arguments and you get a harder to track down bug. It also doesn't work well with languages that have default arguments or the equivalent (e.g. using the arguments object) because you don't know exactly when to stop currying. On Wed, Dec 17, 2008 at 11:31 PM, Per Cederberg cederb...@gmail.com wrote: The names curry and uncurry were a bit confusing to me, so it took me a while to understand these two functions... http://en.wikipedia.org/wiki/Currying To me (and probably other non-Haskell users) the names imply the same thing as bind or partial. It's a confusing world... :-( In JavaScript, I think plain apply + MochiKit.Base.bind does the same thing: var test = [ [10, 1], [20, 2], [30, 3] ]; var addArray = bind(apply, operator.add, null); assertEqual(map(addArray, test), [11, 22, 33]); It's no beauty, so perhaps this particular variant of bind merits an alias? Uncurrying is just the same as the built-in apply function, so that seems unnecessary. Cheers, /Per On Wed, Dec 17, 2008 at 5:22 PM, Arnar Birgisson arna...@gmail.com wrote: One thing I think could be useful is to port Haskell's curry and uncurry. This is basically a convenience method for (un)wrapping an .apply on a function object: function curry(f) { return function () { // first convert arguments to a regular array var args = Array.prototype.slice.call(arguments); return f(args); } } function uncurry(f) { return function (args) { return f.apply(this, args); } } Example use: test = [ [10, 1], [20, 2], [30, 3] ]; assertEqual(map(uncurry(operator.plus), test), [11, 22, 33]); // assume join is a function that takes a list and returns a string // with the elements joined with some delimiter f = curry(partial(join, _, , )) assert(f(Bond, James Bond) == Bond, James Bond) Does anyone else think this could be useful? What module would it fit? Base already has a lot of functional stuff (compose, partial, map friends) - I'm wondering if it fits there or if all the functional stuff should be in a seperate module MochiKit.Functional - as Python seems to be heading. cheers, Arnar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: connectEach shortcut
On Fri, Dec 12, 2008 at 11:20 AM, Arnar Birgisson arna...@gmail.com wrote: Hi On 12.12.2008, at 16:45, Eoghan eoghanomur...@gmail.com wrote: connectEach($$('#my-ul li'), 'onclick', function(e){ // do sumn' }); rather than slightly more unwieldy: forEach($$('#my-ul li'), function(el){ connect(el, 'onclick', function(e){ // do sumn' }); }); Is it a good candidate to include in the signal api? I can definitely see the use case, but IMO this is one of the cases where I'd not want to add since forEach is not that much typing. In my mind this the whole point of having a functional, composable API such as the iter module. Just my 2000 ISK Personally I think it's useful, but I would rather have the connect take a selector as a string instead of a list. Makes it much easier to track down when the lookup happens in-connect. connectAll(#my-ul li, onclick, ...); (not sold on the name) We could even have the existing API do this if passed a list, but perhaps that's a bit too magical. connect([#my-ul li], onclick, ...); The other problem is that the return signature has to change for disconnect, or we have to allow for a different kind of disconnect. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Problems with appendChildNodes?
Are you adding SPAN({}) to a string or something? appendChildNodes(idOfADiv, SPAN({})) should insert an empty SPAN, but appendChildNodes(idOfADiv, SPAN({}) + ) might have the behavior that you're describing. You want to use commas, not addition to add multiple nodes, e.g. appendChildNodes(idOfADiv, SPAN({}), text, DIV({})) Using $() is not necessary because any function that expects a DOM node will automatically do the getElement for you. On Tue, Nov 25, 2008 at 2:24 PM, Bjoern [EMAIL PROTECTED] wrote: Hello, I am new to MochiKit and couldn't get appendChildNodes to work properly. As an example, I tried appendChildNodes($(idOfADiv), SPAN({})); but on the website this shows up as [object HTMLSpanElement] (same with images, created with IMG), so it doesn't look as if a span dom object is being inserted. What am I doing wrong? Björn --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: MochiKit 1.4.1 released
I don't think anything relevant to the screencast has changed, although there are a lot of new things that one could talk about in a new screencast. I suppose it was probably a bad idea to associate the screencast with a version number. On Sun, Nov 2, 2008 at 12:43 PM, Cowmix [EMAIL PROTECTED] wrote: With the new release(s) of Mochikit in the past few weeks... do you think it might be appropriate to update the 1.1 based screen cast? Thanks! On Nov 2, 6:09 am, Per Cederberg [EMAIL PROTECTED] wrote: MochiKit 1.4.1 has now been released and is available on the web site: http://mochikit.com/download.html This version contains the correction of a few issues found since the original 1.4 release: --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: MochiKit 1.4 released
Awesome! Thanks for all the hard work everyone, I owe many of you beers :) On Tue, Oct 21, 2008 at 9:35 AM, Jason Bunting [EMAIL PROTECTED] wrote: Congrats and thanks to everyone involved for all of the hard work that goes into maintaining this stable toolkit! Jason Bunting -Original Message- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Per Cederberg Sent: Tuesday, October 21, 2008 4:32 AM To: MochiKit Subject: [mochikit] MochiKit 1.4 released MochiKit 1.4 has now been released and is available on the web site: http://mochikit.com/download.html The full change history from version 1.3.1 is rather lengthy, but you can find it on our web site: http://mochikit.com/doc/html/MochiKit/index.html#version-history As far as I know, there should be no backwards-incompatible API changes between 1.3.1 and 1.4. If you happen to find one, please let us know through this mailing list so that we can update the docs and/or fix the issues. Finally, many thanks to everyone who contributed code, documentation, bug reports, ideas and everything else during this long development cycle. Looking forward to hear from you all during the 1.5 development. Cheers, /Per No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.8.2/1737 - Release Date: 10/21/2008 9:10 AM --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
Well, the login database is outside of trac since we're using basic auth to login and they are the same credentials that give svn commit access. Disabling anonymous commenting is something that I did because I couldn't be bothered to implement a better spam filter or maintain it. I'm not really sold on launchpad, I think bzr would be too much of a barrier to entry for many people. I would certainly consider moving to google code though, because that would be easy enough. All of our other open source projects are there these days. People that want to use distributed vcs to keep a local branch can do so easily enough with a central svn repo. On Mon, Oct 13, 2008 at 6:47 AM, Amit Mendapara [EMAIL PROTECTED] wrote: The version of trac is okay. See http://trac.edgewall.org/wiki/TracPermissions, you can easily prevent those spams. You can see how TurboGears trac is configured... You can also think about moving MochiKit to Launchpad.net. It's really a good platform to host OpenSource projects with distributed vcs, bug tracking, blueprints and more. Launchpad team has already created a project for MochiKit (so that no one then MochiKit team can claim the ownership, you can contact Launchpad team to get ownership rights). - Amit Mendapara On Oct 13, 6:24 pm, Per Cederberg [EMAIL PROTECTED] wrote: On Mon, Oct 13, 2008 at 3:13 PM, Amit Mendapara [EMAIL PROTECTED] wrote: Once, I filed a bug report on the trac (related to Sortables), but I was unable to change/comment it later. That's why I never submitted again. Yes, this is very unfortunate. I used to have the same problem, so I hear you loud and clear. The problem is the amount of spam that we'd otherwise receive in bug reports. Don't know if there is some newer version of Trac that fixes this that we could install on the server. Or if there is some other solution that would work. Until that happens, emailing to this list or directly to the bug owner should work. Sorry about that. Cheers, /Per --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Migrate to Google Code?
I've been considering this for a while but didn't want to put forth the effort at the time, but I think that with the release of 1.4 it would be a good time to migrate from the Mochi Media hosted Trac and SVN over to something else. My personal preference is Google Code because we already use that for our other open source projects and it wouldn't require transitioning from a mainstream VC solution to something more obscure (e.g. launchpad, github). Per, do you have any thoughts on this? -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
I had intended to build exactly that years ago, but never got around to it... mostly because it's hard to do client side and I didn't want that feature to be dependent on some server-side script. My thinking was that we'd keep packed versions of every module (so that we could continue to use the Java based packer, instead of implementing a JavaScript version)[1] and some client-side could could XHR them all down and concatenate them in the correct order, but the problem is allowing the user to actually download that text. Using the pasteboard would work I guess, but that's not a nice solution. I suppose we could set something up where the client just does a POST to some URL (maybe an app engine service or something) and the server simply echos it back with a Content-Disposition header that forces download. [1] But maybe it would be reasonable to write an entirely JS based packer with Narcissus http://mxr.mozilla.org/mozilla/source/js/narcissus/ -- are there any other projects like this that I'm not aware of? -bob On Mon, Oct 13, 2008 at 4:47 AM, Per Cederberg [EMAIL PROTECTED] wrote: Seeing that this wasn't just an omission, I won't change it for the 1.4 version. For version 1.5 I think we should consider having a nice little download web page where you can customize your packed version of MochiKit. I created a little dummy UI to show what I mean: http://www.percederberg.net/mochikit/pack.html If we plunge forward and start adding more extension modules (as suggested here before), I think such a UI would be important to keep all users happy. Cheers, /Per On Wed, Oct 8, 2008 at 3:44 PM, Arnar Birgisson [EMAIL PROTECTED] wrote: Hi Per, On Wed, Oct 8, 2008 at 15:38, Per Cederberg [EMAIL PROTECTED] wrote: The packed version of MochiKit still doesn't include the modules DragAndDrop and Sortable. I found a previous discussion of that in this thread: http://groups.google.com/group/mochikit/browse_thread/thread/9d3a82cd7b165e73/70b954863b717c99 None of the two modules have been much modified lately, so perhaps they are now stable? Otherwise, I think we should make the docs clearer regarding their status and how to use them. Including them is fine with me, but for my own purposes I don't use that.. since for me MochiKit serves purely as a utility library rather than one of UI elements. I suspect there are others in a similar situation. What we really should do, and it should not be too hard, is make several packed versions. Basically for every module we'd provide a dependency-closed packed version - i.e. one that includes that module and all of its dependencies. Modifying the packed script to perform this should be doable. If people don't like the idea of so many packed versions, perhaps we could decide on two or three feature-sets and provide packed versions of these. I know MochiKit is not that big, and download time is not really the issue - but bandwidth can be an issue for the host. cheers, Arnar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
AFAIK Flash can't save to disk in that manner either. You can build Flash content with free tools though (Adobe Flex 2 SDK, MTASC, haXe, etc.). -bob On Mon, Oct 13, 2008 at 11:51 AM, Per Cederberg [EMAIL PROTECTED] wrote: Scary stuff. JS in JS... :-) I also gave the download issue some thought. Seems it would be possible to spoof a download in IE and Firefox (with privilege escalation warning). But not on Safari. And anyway, it would be an ugly and messy hack. So my next thought would be to create something in Flash that could save a file locally. We can even supply it with the actual text file content from JS just like Bob explained. Is that doable? I don't have a license for that stuff and have never worked in Flash myself, so perhaps I'm just dead wrong here. Third option would be to just open a window with the packed text and ask the user to do Ctrl-S. Perhaps by setting the window title or something. Cheers, /Per On Mon, Oct 13, 2008 at 6:29 PM, Bob Ippolito [EMAIL PROTECTED] wrote: I had intended to build exactly that years ago, but never got around to it... mostly because it's hard to do client side and I didn't want that feature to be dependent on some server-side script. My thinking was that we'd keep packed versions of every module (so that we could continue to use the Java based packer, instead of implementing a JavaScript version)[1] and some client-side could could XHR them all down and concatenate them in the correct order, but the problem is allowing the user to actually download that text. Using the pasteboard would work I guess, but that's not a nice solution. I suppose we could set something up where the client just does a POST to some URL (maybe an app engine service or something) and the server simply echos it back with a Content-Disposition header that forces download. [1] But maybe it would be reasonable to write an entirely JS based packer with Narcissus http://mxr.mozilla.org/mozilla/source/js/narcissus/ -- are there any other projects like this that I'm not aware of? -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Migrate to Google Code?
Keeping the commit hooks for updating the site is possible, I'll probably set up a svn mirror at or near the current svn repository and our internal tools will be able to update that. Might have to hook up some kind of mail hook thing to have it happen instantly though, I don't think google code has a HTTP post-commit web hook. Anyway, I can take care of it. These are the sorts of reasons that I didn't bother before, but I'm willing to do it now :) I do like keeping the packed version and docs in svn, but we could have a process that automatically does it and performs a second commit when necessary (but setting that up might be a little too much work to bother). -bob On Mon, Oct 13, 2008 at 12:02 PM, Per Cederberg [EMAIL PROTECTED] wrote: Google code seems fine by me. Especially if we get better access for normal users. The only issue I come to think of is that the mochikit.com web site automatically updates from svn trunk. Don't know if it would be easy to keep that link. Something which is pretty good to have from time to time. Especially when we are linking to examples and demos that are actually inside the project repo (not just on the web site). On the other hand, we often forget to make_docs.py or pack.py before committing to svn. So perhaps it would be good to have these steps performed automatically by some automated web publisher. So that we wouldn't need the packed version in svn... Just my random thoughts. Cheers, /Per On Mon, Oct 13, 2008 at 6:17 PM, Bob Ippolito [EMAIL PROTECTED] wrote: I've been considering this for a while but didn't want to put forth the effort at the time, but I think that with the release of 1.4 it would be a good time to migrate from the Mochi Media hosted Trac and SVN over to something else. My personal preference is Google Code because we already use that for our other open source projects and it wouldn't require transitioning from a mainstream VC solution to something more obscure (e.g. launchpad, github). Per, do you have any thoughts on this? -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Why doesn't removeElement use the DOM Coercion rules?
If you'd like to fix it then I don't see why the patch would be rejected. On Fri, Oct 10, 2008 at 7:57 PM, Jason Bunting [EMAIL PROTECTED] wrote: That's it huh? No more discussion on this? I guess I am smoking crack... Jason -Original Message- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of Jason Bunting Sent: Thursday, October 09, 2008 10:50 AM To: 'Per Cederberg'; 'MochiKit' Subject: [mochikit] Re: Why doesn't removeElement use the DOM Coercion rules? Per Cederberg wrote: Well... I think your case here is pretty uncommon. This is because the __dom__() function is really supposed to create a *new* DOM node. Otherwise people might run into issues when adding an object twice into the DOM tree. Excuse my ignorance, and permit me to ask a few questions so I can explore this further... Line item 6 in the DOM Coercion Rules, as posted in the documentation, states: 6. Objects that have a .dom(node) or .__dom__(node) method are called with the parent node and their result is coerced using these rules. So, perhaps there is some confusion because of the documentation, but I don't see how my example code violates anything. I am confused by your statement that Otherwise people might run into issues when adding an object twice into the DOM tree - using my example, if someone were to try to add myWidgetInstance to the DOM twice, the behavior would be exactly as I would expect it - it is the same instances, and thus it would only appear once (because the call to __dom__ would return the same instance). If the developer doesn't understand that this would happen, then they have other problems. Unless they instantiate another instance, there should only be one. But sure, there is an inconsistency here. My suggestion would be to just work around it instead: removeElement(myWidgetInstance.widgetDomRepresentation); IMO, that's terrible. It breaks encapsulation because now something that should be private is made explicitly public. I don't want a workaround, I want consistency in MochiKit's API. Actually, other widget libraries tend to use the magic dom property for storing the root DOM node in the widget. Personally, I'd recommend using a mixin approach to widgets, just as I've done in the suggested MochiKit.Widget library: http://github.com/cederberg/mochikit- patches/tree/master/MochiKit/Widget.js I appreciate your comments, and while an API for widget building may provide some useful help, it isn't what I am looking for at the moment. The way I have built widgets up to now (successfully, and for quite a while) is pretty much the way my example implies. It works beautifully and is simple enough to be understood without an entire widget framework (notwithstanding the fact that some help from using one might eventually be better than my approach). I would simply like some consistency in the API - the following functions all use the DOM Coercion Rules: appendChildNodes insertSiblingNodesBefore insertSiblingNodesAfter createDOM replaceChildNodes ... If those do, so should any of the others that expect DOM elements: removeElement swapDOM ... If this is merely work that needs to be done, I would be willing to do it. I simply want to see if and why others don't see the inconsistencies that I do. Thanks again, Jason Bunting On Thu, Oct 9, 2008 at 1:01 AM, Jason Bunting [EMAIL PROTECTED] wrote: I don't know if I am up in the night on this or if it is an oversight, but why doesn't removeElement use the DOM Coercion rules in the same way that something like appendChildNodes does? Here's some sample code that illustrates my problem: function MyWidget() { var widgetDomRepresentation = DIV({style:border:solid 1px}, Hi!); var that = this; connect(widgetDomRepresentation, onclick, function() { signal(that, removeme); }); this.__dom__ = function() { return widgetDomRepresentation; }; } var myWidgetInstance = new MyWidget(); connect(myWidgetInstance, removeme, function() { removeElement(myWidgetInstance); // this blows up }); appendChildNodes(currentDocument().body, myWidgetInstance); It seems to make little sense that one can append myWidgetInstance to the DOM using MochiKit.DOM functions, but can't remove it just as easily. Am I missing something here? Jason Bunting No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.7.6/1716 - Release Date: 10/9/2008 9:44 AM No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.173 / Virus Database: 270.7.6/1716 - Release Date: 10/9/2008 9:44 AM
[mochikit] Re: MochiKit.Async.doXHR
It looks like your problem is that your usage of partial probably doesn't do what you intend it to. request.addCallBacks( partial(this.typeLoaded, i), partial(this.typeFailed, i) ); With that expression, you lose the binding to this (since JavaScript has no bound methods). You probably want to use bind or method instead of partial in such a way that you can keep the this binding. -bob On Wed, Oct 1, 2008 at 10:41 PM, Akari no ryu [EMAIL PROTECTED] wrote: I've been battling with this for a few hours now, been reading the docs and read this groups mails on defferred.callback None of that seems to help. My code does the following: this.interfaceTypes = { 'lines':false, 'regions':false, 'points':false }; for(var i in this.interfaceTypes) { var url = i+'.php'; var queryString = MochiKit.Base.queryString({'do':'fetchTypes'}); log('created url of '+url+' and queryString of '+queryString); try { var request = MochiKit.Async.doXHR(url); request.addCallBacks( partial(this.typeLoaded, i), partial(this.typeFailed, i) ); } catch(e) { for(var j in request) { log('request.'+j+\n+request.j) } } } For all values of request's properties, it's showing up as undefined. Also, if I don't litter my constructor with log calls, the log calls don't happen in there and a log call after it won't happen either. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Formatting strings, numbers and stuff
On Fri, Sep 12, 2008 at 9:01 AM, csnyder [EMAIL PROTECTED] wrote: On Wed, Sep 10, 2008 at 3:53 PM, Per Cederberg [EMAIL PROTECTED] wrote: Suggested formatting types: s - Output from toString(), this is the default r - Output from MochiKit.Base.repr() b - Binary. Outputs the number in base 2. c - Character. d - Decimal Integer. Outputs the number in base 10. o - Octal format. Outputs the number in base 8. x - Hex format. Outputs the number in base 16, using lower-case letters. X - Hex format. Outputs the number in base 16, using upper-case letters. f - Fixed point number. % - Percent conversion for a fixed point number (and adds a '%' char at the end). ... perhaps some format for exponents (but it would be hard to implement) ... and some nice time formatting stuff What about currency (amount) formatting? Or is that just $+format({0:0.2d}, 1.6) ? It wasn't immediately clear to me from the examples how you get a precision 2 decimal number, which is likely to be one of the most requested formats. d is for integers, f is for fixed point. 1 mochifmt:f(${0:.2f}, [1.234]). $1.23 -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Formatting strings, numbers and stuff
On Wed, Sep 10, 2008 at 5:55 AM, Per Cederberg [EMAIL PROTECTED] wrote: I guess this is a question for Bob, but others might have some clues here also. Thus sending it to the list. I've recently done some Python coding and found the % string formating there very convenient. Now, as MochiKit is so inspired by Python, I find it a bit odd that there is no generic string formatting similar to the Python version. Is this just due to lack of time or is it a deliberate omission? The MochiKit.Format.numberFormatter function is of course very powerful, but it doesn't provide everything that the Python equivalent does: 1. No type selection mechanism. Cannot format strings, random objects or hexadecimal, octal, binary or floating point exponential numbers. 2. No generic string formatting. Cannot output Value: %d or similar. 3. Inconvenient API for throw-away formatting. You have to create a formatting function and then call it (very Java-ish). Has anybody created a generic formatting function in JavaScript? Other libraries? Or am I the only one seeing the need? I've wanted to have it once or twice, but the number formatting has worked out well for what I wanted to do. Conversely, Python's formatting functions don't allow you to put thousands separators in numbers, which is something we do very often. The number formatter uses the same spec as Java does so the way it acts should be of little surprise. The API isn't terribly inconvenient other than the length of the name I guess, since functions are first class. numberFormatter(###,###%)(2134) isn't that much longer than say formatNumber(###,###%, 2134) or something like that. If we do implement a string formatting library my personal preference would be the advanced string formatting from PEP 3101 that is going into Python 2.6/3.0: http://www.python.org/dev/peps/pep-3101/ We've also got a similar Erlang implementation here: http://code.google.com/p/mochiweb/source/browse/trunk/src/mochifmt.erl -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Formatting strings, numbers and stuff
I think we should keep deep object names, JSON data structures are often nested a little bit and it's nice to be able to work with them as-is without creating a new object just to flatten it out. As far as nested replacements go, I think we can ditch that safely. I've never really wanted to use that. Otherwise the proposal looks good! :) On Wed, Sep 10, 2008 at 12:53 PM, Per Cederberg [EMAIL PROTECTED] wrote: Thank you everyone for the interesting comments. I had a look at PEP 3101 (Python 3), the (new) Java 1.5 Formatter API and a popular sprintf implementation for JavaScript. And in the end, it seems hard to strike a good balance between readable syntax, power features and localization. Actually, I think they all fail at one or the other. In PEP 3101 I couldn't find any mention of the thousand separator (at first, but now I just realized that :n should be used). The Java Formatter API took the already ugly sprintf-syntax to new heights of unreadability. And the standard sprintf variants are problematic for localized format strings where the order of the parameters might change. So, I'm thinking about using a simplified version of PEP 3101 with a few add-ons to enable most of what is possible with the current numberFormatter function. I'm thinking that the API should look something like: // Create a formatter function for specified pattern locale MochiKit.Format.formatter(pattern/*, locale=default */) == function object // Short-cut that immediately applies the formatter on the specified args MochiKit.Format.format(pattern/*, ... */) == formatted string Perhaps a few examples would best explain the formatting patterns: // Simple positional replacements format(A {1} string with {0} arguments., numeric, format) == A format string with numeric arguments. // Or we use object properties format({name} == {value}, { value: 2, name: a }) == a == 2 // As usual, escaping is performed by double chars format({{}}) == {} // Differing from Python, the default is a toString() format({0}, 1/3) == 0. // Naturally, null is supported as null format({0}, null) == null // We can force a decimal format format({0:d}, 1.5) == 1 // And a fixed number of characters format({0:4d}, -4) == -4 // We can force the field to be left-aligned format({0:4d}, 4) == 4 // Or add zero padding format({0:04d}, 4) == 0004 // Using the repr() output format({0:r}, foo) == \foo\ // I suggest we skip nested replacements due to complexity format({0:{1}}, 4, 3) == error, but in Python it would be 4 // I'd also reject deep object names as it is just not useful enough format({sub.name}, { sub: { name: Alice } }) == error, but in Python it would be Alice So the format for the replacement string is: { key : fmt } The format string has the following (Python) format: [flags][width][.precision][type] Flags: '' - Forces the field to be right-aligned (default). '' - Forces the field to be left-aligned. '+' - Sign should be used for both positive and negative numbers. '-' - Sign should be used only for negative numbers (default). ' ' - Leading space should be used on positive numbers. '0' - Numbers will be zero-padded to the specified width. ',' - The result will include locale-specific grouping (thousand separators). Width specifies the minimum field width. The precision indicates how many digits should be displayed after the decimal point in a floating point conversion. For non-numeric types the field indicates the maximum field size. Suggested formatting types: s - Output from toString(), this is the default r - Output from MochiKit.Base.repr() b - Binary. Outputs the number in base 2. c - Character. d - Decimal Integer. Outputs the number in base 10. o - Octal format. Outputs the number in base 8. x - Hex format. Outputs the number in base 16, using lower-case letters. X - Hex format. Outputs the number in base 16, using upper-case letters. f - Fixed point number. % - Percent conversion for a fixed point number (and adds a '%' char at the end). ... perhaps some format for exponents (but it would be hard to implement) ... and some nice time formatting stuff I think the above would support most of the common use cases for formatting, while leaving it fairly simple to implement in plain JavaScript. If more advanced formatting is required, one can always write specialized functions that re-use these components accordingly. Opinions? Think I'll start on this next week otherwise. Cheers, /Per --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Selector speedup by using John Resig's Sizzle
On Thu, Aug 28, 2008 at 3:04 AM, Arnar Birgisson [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 05:35, Amit Mendapara [EMAIL PROTECTED] wrote: Another problem to which I am not sure is licensing issue, Sizzle is MIT licensed while MochiKit has dual MIT/AFL license. I myself thinking of releasing my code under any FSF approved licenses like MIT or GLP. Do you see any difficulties of including these sources to MochiKit particularly under AFL? To be honest, I don't know. Bob, or anyone, do you know if there are problems with this? If there are, John Resig was keen on the idea so he might make some arrangements for us. I don't think there should be a problem with that, since AFL doesn't give any permissions that don't already exist in MIT, but IANAL. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Random Ideas for Mochikit.DOM
On Tue, Aug 26, 2008 at 6:34 PM, machineghost [EMAIL PROTECTED] wrote: First off, I do 3 Mochikit. I wasn't trying to bash it, I just wanted to share my opinion of it with someone who seemed to be in a similar position. part of the reason changes are looked at with suspicion is because a lot of suggestions are not in keeping with the intent of MochiKit. Suspicion is one way to describe it; I'd lean more towards outright hostility (although said hostility is generally civil and polite, which is more than I can say for a lot of lists). And as for the intent of MochiKit, I thought it was to make JavaScript suck less. It does that to some degree right now, but do you really think it's impossible for JS to suck even less? I don't (JS sucks a lot, and I say that even though it's one of my favorite languages). Yes, it's certainly possible, but it does what we want it to do... if it didn't, you'd see a lot more commits from us. Is the lack of development necessarily indicative of a problem? Absolutely, the health of any open source project is measured by it's activity. As a JS implementer I need to know that the (JS framework) horse I bet on is going to respond to my future needs in a timely fashion. I have great confidence of that with JQuery because it has an extremely active development community; try comparing the activity on their list: http://groups.google.com/group/jquery-en?lnk=srg to the activity here and you can see why I don't have similar confidence in Mochikit. Alternatively you can compare the membership of the groups, the # of Google results for searches on MochiKit vs. JQuery, the # of commits to either library in the last year, ... whatever metric you use, Mochikit always comes in last compared to not just JQuery, but every other major JS library (prototype, YUI, dojo, etc.) as well. If you want something popular with a vocal community and lots of new developments, you're in the wrong place and that's been the situation for a long time. I don't think anyone here would try and convince you otherwise. what things is it missing? Well there are two just in this thread alone: chainability and additional element methods. Another great example from JQuery is the onDOMReadyState pseudo-event. But again, it's not just the feature by feature comparison between frameworks that matters; five years ago I could not have predicted the need for an XmlHttpRequest abstraction, but that's obviously a very essential feature for a JS library today. Chainability probably is not going to happen, but onDOMReadyState certainly should at some point. If you really like chainability, you should probably be using jQuery. That's what it's good at, but I personally don't care much for that style. jQuery is a perfectly good library for what it intends to do, if it does w hat you want it to how you want it to be done, why not just use it? MochiKit is here because it solves a lot of problems that we had a couple years ago before jQuery existed. Were it around in 2005 I might've just used it instead of writing my own, but dojo and prototype were not really worth using at the time. I have no real vested interest for you to use MochiKit. I'm not involved with any kind of consulting, I don't intend to write any books, not particularly interested in speaking at any more conferences about JS, etc. It helps me and my company out when people contribute code, file bugs, etc. because this is the library we use. In other words, I don't really care if you use MochiKit or not. If my company had adopted some framework based solely on it's feature- set back then, and that framework had never added an XmlHttpRequest abstraction, I'd be up a proverbial creek without a paddle. I'd have to convert all of our code to use a new library or else use two libraries (and have a giant download footprint); either way I'd be kicking myself for not choosing an actively developed framework. I don't see the library itself as missing anything. There are still hundreds of opportunities to make JS suck less, but Mochikit is missing all of them while libraries like JQuery either respond to them directly (by adding new stuff to the library) or indirectly (via something like JQuery's plug-in mechanism). All JavaScript frameworks have plug-in mechanisms... you can add whatever code you want to the runtime system. From what I recall, jQuery's plug-in mechanism is just there to make it easy to inject things into jQuery's namespace such that it's chainable, which is not something MochiKit needs. MochiKit is more of a collection of libraries than a framework in that sense, because you don't need a plug-in mechanism, you just add more code. Is this because they wouldn't add a few aliases for you? Hardly. I personally have proposed not just that but several other enhancements, and of course I'm not the only one who has made suggestions, yet almost no improvements have come out of any of that
[mochikit] MochiMedia looking for Web Developers
If you're reading this list, we know you use MochiKit, so how about coming and working with the team that developed it in the first place? We're looking for a Senior Web Application Developer experienced using Python, Pylons, MochiKit, SQLAlchemy, etc. Here's a short job description. Reply back to [EMAIL PROTECTED] if you're interested! Senior Web Application Developer for Mochi Media We're looking for a Sr Web Developer to build out applications in Python to support our network of Flash game developers. The ideal candidate has 5+ years of experience building applications for large web brands, loves to iterate designs, gets agile development, and is unafraid of diving into any area the problem leads him/her to. You should have opinions on programming languages, frameworks and styles, yet be versatile enough to use any of them. CSS/DHTML/AJAX pour out of your mind and into code as fast as you can type it. If I've described you, let me now describe us. Mochi Media is a fast growing startup based in San Francisco. We build a platform for Flash game developers with in game advertising as a key focus for the developers. We just closed our series B round, and we're looking to ramp the company quickly. We're a small team with a very high bar for the types of people we'll bring in led by me (CTO and co-founder) and Eric Boyd our VP Eng. Mochi Media key stats 20% impression growth every month for almost a year. 60MM unique users every month. Strong and rapidly growing revenues. Small team where you can come in and have an immediate impact -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Problems using partial toggleElementClass as an event handler...
On Sun, Jul 6, 2008 at 9:46 PM, Jason Bunting [EMAIL PROTECTED] wrote: I have this code in a control I have built: var ldel = this.LaborDataEntryList; connect(this.ExpandCollapseButton, onclick, function() { toggleElementClass(Invisible, ldel); }); What I originally tried to do was this: connect(this.ExpandCollapseButton, onclick, partial(toggleElementClass, Invisible, this.LaborDataEntryList)); Problem is, when the event fires the result of the partial also gets the additional event argument sent to it and it blows up within addElementClass (which is called by toggleElementClass); is there anything that can be reasonably done to prevent this from happening or do I need to accept that I will have to write this code with the lambda? You'll have to use the anonymous function, but if you find yourself doing it a lot you can always write your own higher order function that returns an appropriate anonymous function. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Flash/Flex port of Deferred?
I've done it before, for AS2 a long time ago (it was the predecessor of the JS implementation). Porting should just be cut + paste, MochiKit's Deferred doesn't do anything outside of the ECMAScript profile that Flash supports. On Mon, Jun 23, 2008 at 7:12 AM, Leo Soto M. [EMAIL PROTECTED] wrote: Hi all, Does anybody know if there is an ActionScript port of MochiKit.Deferred? I'd love the API and I'd like to use it on Flex (basically for RemoteObject interaction). I'm willing to port the code, but hopefully someone did it before. OTOH, If nobody has done it yet, maybe there is a good reason which I may have missed... Thanks, -- Leo Soto M. http://blog.leosoto.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Django doXHR Headers and Guidance
mimeType: 'application/javascript' doesn't do what you think it does, it's the overrideMimeType on the XHR. For JSON it doesn't matter since it only uses responseText, I think it's only useful for setting it to XML. I think your problem is that XMLHttpRequest has a responseText attribute, not response_text. However you should probably just use MochiKit's evalJSONRequest instead of doing the eval yourself. -bob On Mon, May 12, 2008 at 9:07 AM, Szaijan [EMAIL PROTECTED] wrote: Hi Folks, I have a Django application with a scratch-built AJAX Javascript layer that works well on Safari and Firefox, but not on IE. I am attempting to rewrite it using MochiKit, but am having some issues with the doXHR function, in that I seem to be getting back an empty XHR from my Django Python script. I have a few questions: 1) Can anyone see what I'm doing wrong in the MochKit code? As I said, I get back an empty XHR. Am I accessing the return XHR incorrectly (should be the result argument in my callback, right?) When I use typeof(result) I get the expected XHR type. result.toJSONString() yields {}. 2) In the first code sample, I am able to access ajaxRequest.response_text, which should be the same as resulot.response_text in the MochiKit example, but the result appears to be empty. Do I need to do something different to access the fields of the doXHR result argument? 3) Am I getting back an empty result because doXHR sets some default headers for the request that are incompatible with the Django return type? What would be a good set of headers to use? The generic code that works looks like: selectEntity : function (entity) { try { var url = '/visionary/game/select/?xhr'; var eId = 'harp_game_id'; var getData = eId + '=' + escape(entity.pk); var ajaxRequest = this.createRequest(); // Creates a generic, platform appropriate XHR ajaxRequest.open(POST, url, true); ajaxRequest.onreadystatechange = MochiKit.Base.bind(function () { try { if(ajaxRequest.readyState == 4) { if(ajaxRequest.status == 200) { var response = eval( ( + ajaxRequest.responseText + )); if (response.success) { var consoleMessage = response.initial_console_message; MochiKit.Base.map(MochiKit.Base.bind(function (index) { consoleMessage += br+ index + : + response[index]; var rowId = [this.app, this.cn, response[index], 'row'].join('_'); this.setRowHighlight(MochiKit.DOM.getElement(rowId), index == 'newId' ? true : false); }, this), ['newId', 'oldId']); this.updateConsole(consoleMessage); } else { this.errorsToConsole(response); } return true; } } } catch(e) { MochiKit.Logging.logError('selectEntity Callback fn ' + e); } return false; }, this); ajaxRequest.setRequestHeader(Content-Type, application/ x-www-form-urlencoded); ajaxRequest.send(getData); return true; } catch(e) { MochiKit.Logging.logError('selectEntity(' + entity + ') ' + e); } return false; } The MochiKit heavy code I can't get a response from looks like: selectEntity : function (entity) { try { var url = '/visionary/game/select/?xhr'; var q = 'harp_game_id=' + entity.pk; var r = {method: 'POST', mimeType: 'application/javascript', headers: [['Content-Type', 'application/x-www- form-urlencoded'], ['Accept', 'application/ json']], sendContent: q}; var d = MochiKit.Async.doXHR(url, r); d.addCallback(MochiKit.Base.bind(function (result) { try { MochiKit.Logging.log('Callback Request: ' + result); var response = eval( ( + result.response_text + )); if(typeof(response) != 'undefined') {
[mochikit] Re: 1.4 release
On Fri, Apr 18, 2008 at 8:01 AM, Christoph Zwerschke [EMAIL PROTECTED] wrote: Bob Ippolito schrieb: Documentation patches are key, and having more examples for the features in Visual would at least prove that they work under *some* circumstance :) I just noticed that MochiKit already has an example page for the visual effects, in the examples/effects folder. I think it would be good to have this on the demos page http://www.mochikit.com/demos.html Thanks for the suggestion, just committed that :) -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Updated docs for MochiKit.Visual
This looks good to me, thanks! On Mon, Mar 24, 2008 at 9:45 AM, Per Cederberg [EMAIL PROTECTED] wrote: I've finished updating the docs for MochiKit.Visual now. The clarified version is available on the usual place: http://mochikit.com/doc/html/MochiKit/Visual.html Please let me know if you find any issues or typos in this version. /Per --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Reasons to not use a simple ondomload signal?
Yeah, the major problem of doing a synthetic ondomload event like that is that you need to instrument all of your pages with that script tag at the bottom. It's nicer to do it via DOM calls because you don't need to change the markup. -bob On Thu, May 8, 2008 at 12:16 PM, Per Cederberg [EMAIL PROTECTED] wrote: Antti Koivisto, one of the Safari browser developers, wrote an interesting blog entry about page loading recently. It explains some of the difficulties involved from a browser perspective: http://webkit.org/blog/166/optimizing-page-loading-in-web-browser/ And a small extract of the most relevant section: --- Problems start when a document contains references to external scripts. Any script can call document.write(). Parsing can't proceed before the script is fully loaded and executed and any document.write() output has been inserted into the document text. Since parsing is not proceeding while the script is being loaded no further requests for other resources are made either. This quickly leads to a situation where the script is the only resource loading and connection parallelism does not get exploited at all. A series of script tags essentially loads serially, hugely amplifying the effect of latency. --- So, in my understanding, putting a script tag at the very end of the HTML text on the page should be nearly identical to actually waiting for the onDOMLoad event. All the document text should have been parsed already and be available in the DOM tree. One of the many issues with onload is also the latency involved in loading images and CSS files, which actually adds up to quite some time (as most browsers only request 2 objects simultanously per web site). /Per On Thu, May 8, 2008 at 7:10 PM, machineghost [EMAIL PROTECTED] wrote: As I understand things (and I am by no means a JS event sequence expert), the ordering is as follows: 1. Browser reads page line by line; every time it reads enough lines to complete a JS statement, it executes that statement; meanwhile, non- JS content is loaded in to the DOM as it is read 2. Once the browser has finished reading the page it will have a complete DOM ... in memory. 3. The browser will then render that DOM tree to your screen. 4. Once it has finished rendering the DOM tree, it invokes any onload events. Technically that's wrong, because the first three things are really happening simultaneously (ie. the browser starts rendering the top of the page even before it has a complete DOM loaded), but it's simpler to think of it that way (because they will almost always finish in that order). The problem with your code, as I understand it, is that your code goes off in #1, which means there is no guarantee that a complete DOM will exist. If you instead wait for onLoad though, you have to wait for the page to render. So what people who are interested in the onDOMLoad event are after is getting an event that triggers after 2 but before 3. That way, you don't have to wait for the page to render, and as long as your code doesn't require any rendered information (like what are the dimensions of $('someElement')) it should work fine. But all of the above was written with my very flawed understanding of the JS event model; please take it with a giant helping of salt. Jeremy On May 8, 9:37 am, csnyder [EMAIL PROTECTED] wrote: Hi MochiKitters, I've been using the following trick successfully for a few months now. It _seems_ to work fine cross-browser and cross platform. script type=text/javascript signal(window,'ondomload'); /script /body /html But based on the recent thread about implementing ondomload, I assume that there must be cases when a simple signal at the end of the dom isn't enough. Can anyone give me a quick earful about why the above isn't the best way to do it? -- Chris Snyderhttp://chxo.com/ --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Anyone Else Interested in a New Synthesized onReady Event (ala JQuery)?
This would definitely be convenient, it's always been on my list and I've hacked together crappy (polling) implementations once or twice, but I never needed it bad enough to tackle all of the cross-browser issues myself :) On Tue, May 6, 2008 at 10:51 PM, Per Cederberg [EMAIL PROTECTED] wrote: I liked the ondomready name and structure. Looking at MSDN, they provide the following solution instead of writing new script tags into the document (not tested, just pasted): document.onreadystatechange=fnStartInit; function fnStartInit() { if (document.readyState==complete) { // Finish initialization. } } Otherwise I like the proposed solutions and vote for inclusion to MochiKit.Signal. Never know when it might be handy. Cheers, /Per On Wed, May 7, 2008 at 6:21 AM, Felipe Alcacibar B [EMAIL PROTECTED] wrote: oops, some mistake in the webkit part, sorry [code] if (/WebKit/i.test(navigator.userAgent)) { var __domready__timer__ = setInterval(function() { if (/loaded|complete/.test(document.readyState)) signal(window, 'ondomready'); clearInterval(__domready__timer__); }, 10); [/code] On 7 mayo, 00:12, Felipe Alcacibar B [EMAIL PROTECTED] wrote: MochiKit is wonderful, as you wrote ir, but is the base, you can made too much things, but you may need read or investigate some more time like jQuery. I prefer call it domready, because it is when dom nodes are loaded, i use this code to implement domready, and i not have any problem. [code] var __domready__ = false; if (document.addEventListener) document.addEventListener(DOMContentLoaded, function() { if(! __domready__) { __domready__ = true; window.signal(window, 'ondomready') }; }, false); /[EMAIL PROTECTED] @*/ /[EMAIL PROTECTED] (@_win32) document.write(script id=__ie_onload defer src=javascript:void(0)\/script); document.getElementById(__ie_onload).onreadystatechange = function() { if (this.readyState == complete) { signal(window, 'ondomready'); } }; /[EMAIL PROTECTED] @*/ if (/WebKit/i.test(navigator.userAgent)) { var __domready__timer__ = setInterval(function() { if (/loaded|complete/.test(document.readyState)) signal(window, 'ondomready'); clearInterval(ctimer); }, 10);} [/code] and when i need to call them i use [code] connect(window, 'ondomready', function () { alert('now i know kung fu');}); [/code] Felipe Alcacibar Buccioni Developer of systems and solutions On 6 mayo, 17:47, machineghost [EMAIL PROTECTED] wrote: Hey All, In trying to explain why he liked jQuery, a co-worker of mine clued me in to a fairly cool method in that library: ready(someFunc);. For those who aren't familiar with jQuery, you can think of this method as something like: partial(connect, document, DOMContentLoaded) In other word, it connects the provided function to the DOMContentLoaded document event. Now, the specific jQuery syntax I could care less about (with partial I can already make any connect variant I want), but what is really cool about the function is that it makes it really easy to use the DOMContentLoaded event. And why is that cool? 1) The DOMContentLoaded event fires sooner (and if you have a heavy page, MUCH sooner) than the onLoad event (although you can't do stuff that depends on the rendered DOM, like getElementDimensions, until onLoad goes off). As a result, you can get significant performance improvements just by changing (most of) your onLoad code to be onDOMContentLoaded code. 2) Internet Explorer doesn't support DOMContentLoaded :-( Luckily however, this guy:http://javascript.nwbox.com/IEContentLoaded/ figured out a hack to emulate the event in IE. When you call ready(someFunc), behind the scenes JQuery handles figuring out whether to use the hack or the real event. Now, I don't have any desire to switch to jQuery; it has the same basic stuff as Mochikit, but none of the wonderful advanced stuff like partial, keys, etc. I would however like to have access to this fake event. Am I alone in this, or would others on this list like to see a synthesized Mochikit DOMContentLoaded event (similar to the existing synthesized onmouseenter and onmouseleave events)? If there is interest in this event I'll be happy to help write a proper Mochikit patch, but if not I'll just steal (quick and dirty style) the jQuery event for my own purposes. --~--~-~--~~~---~--~~ You received this message
[mochikit] Re: Problem with packed version in trunk
On Sun, Mar 23, 2008 at 12:10 PM, Christoph Zwerschke [EMAIL PROTECTED] wrote: I just stumbled upon an error when using MochiKit with HTML, and it took me some time to realize that it already has been fixed, but not in the packed vresion I was using - the packed version of MochiKit in the trunk does not contain the bugfix in r1335. You should either use a pre-commit hook to make sure that the packaged version is always in sync, or not keep the packed version the repository at all. Neither of those options are very practical, but thanks for letting us know that it got out of sync. It usually isn't. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Can MochiKit support Comet/http push/long polling ???
I've implemented long-polling with MochiKit before. The JavaScript doesn't really change all that much, you just use doXHR like you normally would, the response just doesn't come back for a while and as soon as you get one then you make another one, and you have to have some sort of empty response that you ignore. It doesn't make a whole lot of sense to implement more than one or two of the comet mechanisms.. Long polling works pretty well across the board, for example. On Mon, Mar 3, 2008 at 9:43 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm a big fan of MochiKit and it has served me well. I recently learned I can replace AJAX polling with something much better called Comet aka long polling aka http push. I know there is a TurboGears+Dojo presentation at Pycon on this but I was wondering if we must all replace MochiKit for Dojo to do this paradigm. Furthermore, doesn't Comet/http push/long polling require some modifications to your *server* to do it right?? (e.g. event driven instead of multithreaded ??) I don't see how Dojo or any Javascript library can do it all by itself. Sincerely, Chris --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Trac tickets and code submissions
I watch trac with my newsreader, but for the widest exposure mentioning them on the list helps. On Sun, Feb 24, 2008 at 12:48 AM, Per Cederberg [EMAIL PROTECTED] wrote: Hi, Just a simple question (for Bob I guess): Does someone monitor ticket submissions to trac.mochikit.com? Is it the best way to submit patches and new stuff for MochiKit, or should I also cross-post to this list? Cheers, /Per --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: I'm having a problem with BindMethods
I think you're confused. self is not defined. You want to be using this. On Feb 4, 2008 11:59 PM, Akari no ryu [EMAIL PROTECTED] wrote: self is a property of the pseudo classes in Javascript, similar to this. I possibly should have added that if I comment out the bindMethods part, everything works as expected. On Feb 5, 7:55 am, Bob Ippolito [EMAIL PROTECTED] wrote: Card = function(value, suit, orientation, set) { MochiKit.Base.bindMethods(self); ^^ self isn't defined here. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: I'm having a problem with BindMethods
Card = function(value, suit, orientation, set) { MochiKit.Base.bindMethods(self); ^^ self isn't defined here. On Feb 4, 2008 10:54 PM, Akari no ryu [EMAIL PROTECTED] wrote: I have three files. var deck = new Deck(); loadPage = function() { var postRequest = new MochiKit.Async.doSimpleXMLHttpRequest('deck.php', {'method':'post'}); postRequest.addCallback( function(request) { deck.load(request.responseXML); } ); } function debug(obj) { str = {; for(i in obj) { str+=\t+i+:+obj[i]++\n; } str+= }; logDebug(str); } MochiKit.Signal.connect(window, 'onload', loadPage); which builds a Deck object from the class Deck = function() { this.set = null; this.cards = []; this.md = MochiKit.DOM; } Deck.prototype.load = function(doc) { var xml = doc.documentElement; this.set = xml.getAttribute('set'); var cardNodes = xml.getElementsByTagName('card'); for(i=0; icardNodes.length; i++) { card = new Card( cardNodes[i].getAttribute('value'), cardNodes[i].getAttribute('suit'), cardNodes[i].getAttribute('orientation'), this.set ); this.cards.push(card); } this.addCards(); } Deck.prototype.addCards = function() { log(here) } The load method of Deck should instantiate Card objects Card = function(value, suit, orientation, set) { MochiKit.Base.bindMethods(self); this.md = MochiKit.DOM; log(this); this.value = value; this.suit = suit; this.orientation = orientation; this.set = set; } Card.prototype.getXMLString = function() { return 'card value='+this.value+' suit='+this.suit+' orientation='+this.orientation+'/'; } Card.prototype.rotate=function() { this.orientation=(!this.orientation); } Card.prototype.clone=function() { return new Card(this.value, this.suit, this.orientation, this.set); } Card.prototype.getSuit = function() { return this.suit; } But the log is reporting this, for the class, as Object Window, not Object Object. I've been racking my brains over this one for a while now. Any ideas? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: deferred callbacks that throw errors
On Jan 23, 2008 9:07 PM, SimonS [EMAIL PROTECTED] wrote: Hi, I'm curious about the effect of the following code: var d = new Deferred(); d.addCallback(function() { alert('f'); throw new GenericError('foo'); }); d.addErrback(function() { alert('e'); }); d.addCallback(function() { alert('s'); }); d.callback('success'); The result I observe is that all three alerts fire, in the order 'f', 'e', 's'. This happens even though the first callback (f) throws an exception. My question is why is the last alert fired? The docs say that a callback that throws an exception will put the deferred into an error state. Since the deferred transitions to an error state, why does it continue calling the 'success' chain? Is there a simple way to abort the callback chain from one of the callbacks? It continues calling the success chain because the errback doesn't return an error or raise an exception. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Shouldn't doXHR default to POST instead of GET to be proper?
On Jan 21, 2008 12:56 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Jan 21, 1:16 am, troels knak-nielsen [EMAIL PROTECTED] wrote: That depends on how you use it. The assumption is, that you are pulling data with doXHR. If you want to push data, you should specify the method. Most other HTTP-agents also default to using GET, and only use POST, when explicitly told to. (Take the browser, for example) I thought loadJSON was for pulling from server and doXHR was for pushing to server. I didn't know doXHR could be used for both. I suppose you'll say that doXHR is needed when people do NOT want to pull data from server in JSON format? doXHR is the primitive operation used by all XMLHttpRequest-based operations, including loadJSON. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: How prepend a prefix like /myapp/ to all URLs in MochiKit/Javascript?
Write your own function? I guess all XHR requests go through doXHR at some point, so you could swap it out with something else. Something like this might work: MochiKit.Async._old_doXHR = MochiKit.Async.doXHR; doXHR = MochiKit.Async.doXHR = function (url) { return MochiKit.Async._old_doXHR.apply(MochiKit.Async, extend(['/myapp/' + url], arguments, 1)); }; -bob On Jan 14, 2008 11:42 PM, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'm happily using MochiKit in TurboGears. TurboGears has a nice setting to add prefixes to all URLs (server.webpath). For example, for server.webpath = /myapp: /a - /myapp/a /b - /myapp/b etc. This does *not* seem to affect Javascript code. Anyway to do something similar in my MochiKit/Javascript code? Chris --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: 'this' in Draggable callback
On Jan 13, 2008 11:35 AM, James [EMAIL PROTECTED] wrote: Hi all, I'm something of a newcomer to MochiKit to forgive me if this is a silly question. When using Signal's 'connect' function to add signal callbacks I'm using the form: var obj = new MyObj; connect(window, onload, obj, 'init'); So that 'this' still refers to obj in the init function. However, I'm also using custom callbacks for a Draggable I'm creating, e.g.: var dr = new Draggable($('drag'), { 'onchange': this.dragMoved } In the MyObj.dragMoved function I need access to the obj object, but 'this' refers to the signal source. I tried: 'onchange': partial(this.dragMoved, this) adding a 'self' parameter onto MyObj.dragMoved, but self seemed to be a copy of 'this' as it was when I connected the callback, rather than the live version - a closure in other words. Is there a way for me to get at the live obj instance in this situation? Yeah, use bind instead of partial. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Firefox Issues?
getElement(loginForm) finds an element with an id of loginForm. IE confuses name and id, other browsers don't. You don't have any elements with id=loginForm in your markup. Try using getElement(lfForm). -bob On Jan 2, 2008 3:45 PM, infringer [EMAIL PROTECTED] wrote: Hi, I developed my site using Internet Explorer v7. Now I come to find out it doesn't work with firefox. in my Javascript I have: self.form = getElement(loginForm); self.form.login.focus(); and I keep getting self.form has no properties error message in the Firefox Error Console. Granted, this issue isn't that big a deal as it just isn't focusing. But I have other places where I get the exact same error message self.form has no properties Here is the HTML for the form: form name='loginForm' action='process.html' method='POST' id=lfForm div class=fieldLabelLogin:/div div class=fieldEntry select name='login' option A Bunch of Options /option /select/div div class=fieldLabelPassword:/div div class=fieldEntryinput type='password' name='pw' size=15 maxlength=100 value = //div div id=lfButtoninput type='submit' name='lfSubmit' value=Login class='null'/div input type=hidden name=validbrowser value=false /form Can anyone provide advice/help? Thanks, -David --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Async request problem on Safari
Have you tried using doXHR with the mimeType: 'text/xml' option? Take a look at the ajax_tables or interpreter examples for usage. On Dec 29, 2007 9:50 AM, Steve Zatz [EMAIL PROTECTED] wrote: No matter what I put in that XML declaration, Safari only returns something for responseText (tested on both Leopard and Windows). I tried the DOMParser suggestion but I can't get it to work either -- there must be something wrong with the xml string but I can't figure it out (yet). Thanks again for taking a look at this and for your suggestions. Steve --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: callLater and this
On 12/20/07, Ian Lewis [EMAIL PROTECTED] wrote: Is it intentional that the callLater() function causes the 'this' reference to get scrapped? Has nothing to do with MochiKit, JavaScript doesn't have bound methods like Python does. The binding of this is done by the method call syntax. It would be impossible to preserve it unless the function was wrapped. See MochiKit.Base.{bind,method,bindMethods} for the typical workarounds, also: http://bob.pythonmac.org/archives/2005/07/06/this-sucks-in-javascript/ -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: callLater and this
On 12/20/07, Ian Lewis [EMAIL PROTECTED] wrote: Thanks bob, I guess it's been about 8 years. Good to talk to you again. High school feels a lot longer ago than that :) Tricky. I suppose you would run into this pretty much any time you pass around foo.bar when bar bound (or not) to the object foo as you wouldn't be able to do the call with this syntax. If your blog post is right then it looks like the only way to do call with this explicitly calling the function via the object in code. Welcome to JavaScript. That's pretty much what bind does, but Function.prototype.call and Function.prototype.apply let you jigger this for a given call. foo.bar(a, b) is the same as foo.bar.apply(foo, [a, b]) or foo.bar.call(foo, a, b). Anyway, changing the test code to test.init = function() { createLoggingPane(true); callLater(3.0, bind(test.myfunc, test)); } works. It's cute how bind returns a function that calls your function but goes out and finds the this for you first. Pretty useful hack. Well you give it 'this' as the second argument, it doesn't do all that much magic. bind(test.myfunc, test) is equivalent to function () { return test.myfunc.apply(test, arguments); } -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Problem in IE not in Firefox - loadJSONDoc
On 12/19/07, JS [EMAIL PROTECTED] wrote: I have the Javascript code which is located here: http://pastebin.com/m6d9fe26c It works 100% of the time when I use Firefox for my browser, but doesn't give expected results all the time with IE. The problem occurs after line 12. Here is an overview of what I'm doing. I have an INPUT field where I'm capturing the ENTER key press and calling an 'updateMethod'. When the 'updateMethod' completes, I want to call a 'revertMethod' which will change the INPUT field back to the HTML that it was before. (It got changed to an INPUT field when the user double-clicked on it). The update is working 100% of the time, regardless of the browser. After the update, it seems that at times, with IE that the 'revertMethod' is not called. But, I don't know how to debug this with IE. As I said, it works in Firefox where I use Firebug and the logger for debugging. I'm very new to Javascript programming and the whole callback thing, and am wondering if there is a problem with the way that I have a second loadJSONDoc embedded inside a callback from a previous loadJSONDoc. Or, maybe I'm going about the entire thing all wrong. Any advice on how to debug in IE (MochiKit 1.3) or similar experiences with loadJSONDoc would be appreciated. http://groups.google.com/group/mochikit/browse_thread/thread/3cd6439ac43b1909/4d1aa3d71d464abd?#4d1aa3d71d464abd -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: New INPUT short-hand functions?
It still wouldn't work because you need the arguments object, not arguments[0], for the call to apply. My personal preference would be to use merge because it wouldn't mutate the input object you give it, but there are potential efficiency concerns with all that extra overhead. The original solution was probably fine. MochiKit isn't a replacement for JavaScript, you shouldn't try and wedge it in everywhere just because it might be possible :) -bob On 12/17/07, Kevin Damm [EMAIL PROTECTED] wrote: Oops, that should probably be arguments[0] On Dec 17, 2007 2:00 PM, Kevin Damm [EMAIL PROTECTED] wrote: Maybe use MochiKit.Base.merge or MochiKit.Base.update: function CHECKBOX() { return INPUT.apply(this, update(arguments, {'type': checkbox})); } - Kevin On Dec 17, 2007 1:30 PM, machineghost [EMAIL PROTECTED] wrote: I recently found myself doing this a lot: var a = INPUT({type:textbox}); var b = INPUT({type:checkbox}); var c = INPUT({type:hidden}); etc. So I wanted to make short-hand functions like CHECKBOX and HIDDEN which would work exactly like INPUT, only with a pre-specified type. At first I thought I could do this: CHECKBOX = createDOMFunc(input, {type:checkbox}); but that eliminated all other attributes (since the {type:checkbox} replaced my attributes argument). I played around a bit, and eventually found that I could make it work with: function CHECKBOX(){ arguments[0][type] = checkbox; return INPUT.apply(this, arguments); } But that doesn't seem very MochiKit-ish to me, so I was wondering if there was a cleaner way to do the above using bind or partial or something. Also, I was curious as to how people feel about these short-hand functions, and whether or not they'd be useful enough to include in MochiKit.DOM. Any thoughts/feedback would be appreciated. Jeremy So my question is, is th --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Usage of Selector (or bug?)
It looks like the example is probably incorrect, it's marked as a constructor so you may need to use the new operator. var selector = new Selector(#someelementid); On 12/14/07, Glin [EMAIL PROTECTED] wrote: Hi I tried to use selector example from Mochikit documentation: var selector = MochiKit.Selector.Selector('#someelementid'); But I got this error: this.parseExpression is not a function It is on line 37 in Selector.js. Should I initialize something before I use this module? Or is it a bug? PS: This module looks incredible, if I was able to use it, it could save me a lot of pain and the resulting code would be much nicer. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: What is the purpose of __class__?
It's only used for introspection. Some of the repr's use it, the ones that don't probably should. It's not otherwise very interesting. -bob On 11/28/07, Jason Bunting [EMAIL PROTECTED] wrote: I see this convention being used but don't understand why it exists: __class__ Is it simply a Pythonic type of convention that isn't being used currently? What is the point of it and how can it be beneficially used? Thanks, Jason Bunting --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Looser binding with bind() and more generic signalling
On 11/18/07, Per Cederberg [EMAIL PROTECTED] wrote: #1. Is there a way to do late binding with MochiKit.Base.bind? I.e. allowing function names to be resolved when the returned function is called, rather than when bind() is called. See example below: obj = { a: function() { return a; }, } var test = MochiKit.Base.bind(a, obj); test() == a obj.a = function() { return b; } test() == b (currently MochiKit returns a here) It is easy enough to modify the MochiKit.Base.bind(), but it would of course break semantic backwards compability a bit. I gave it a shot and it definitely breaks backwards compatibility in a way that the tests fail. I won't be doing this, but you can do this with forwardCall. obj = {a: function () { return a; }} [object Object] test = bind(forwardCall(a), obj) function () {...} test() a obj.a = function () { return b; } function () {...} test() b #3. With a few quick hacks to set class and function names on object functions I've been able to implement JavaScript stack traces. And combined with logging, this has proven extremely powerful for debugging issues in the application. Is there something for stacktraces already in MochiKit? Would it be welcomed as a patch? I've done things like this before, but not in MochiKit. I started caring a lot less about debugging tools since Firebug came out :) A patch would be good. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: 1.4, again
A release manager would be responsible for deciding when to do releases, as well as to make sure everything is up to snuff... which would probably mean that they'd spend a lot of their time reviewing code and docs, probably fixing some of it personally (especially docs). I think we're pretty solid on most things, but all of the new stuff still needs work (Selector, and the Scriptaculous stuff). I'm tempted to do a release without those things, but it seems that most people are using one or the other by now so that's not really an option. I've had a couple people express interest so far, but I'm in Seoul right now for a conference and I'm having a hard enough time keeping up with work stuff so I will probably get to that in a week or two after I get back to SF. -bob On 11/7/07, JonR800 [EMAIL PROTECTED] wrote: That begs the question, what's required of a release manager for MK? On Oct 29, 4:23 pm, Bob Ippolito [EMAIL PROTECTED] wrote: There's no need to fork the project, I would gladly hand over SVN access to someone who wants to step up as a release manager. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: 1.4, again
There's no need to fork the project, I would gladly hand over SVN access to someone who wants to step up as a release manager. -bob On 10/29/07, gsteff [EMAIL PROTECTED] wrote: I don't use Mochikit, but like the library, and check in on the newsgroup now and then. If a lot of people want to see new features added to Mochikit, or at least an acknowledgement that the new features already added are stable (via a new release), the normal solution I think is for someone to fork the project. Greg On Oct 17, 11:58 am, Arnar Birgisson [EMAIL PROTECTED] wrote: On 10/17/07, Jonathan Ellis [EMAIL PROTECTED] wrote: On Oct 16, 3:20 pm, Arnar Birgisson [EMAIL PROTECTED] wrote: Most people are in one of two situations: 1. Already using MK. If it's working and you're happy with it, why do you need a release? If it is not, a release won't help much. That's the thing, the cutting edge is a moving target and those of us who started using MK 1+ years ago have seen our requirements get steeper but MK not keep pace. So a lot of us are in the position of it's working, we have code invested in it, but we're NOT really happy with it anymore. Sadly, that's always a danger when investing in software, free or not. I've on many occasions been in the situations where there was even a support contract in place. The good thing about open source is that in that case you are able to extend it with the things you need (or pay someone to do it). Before you start frothing at the mouth, I'm not claiming Bob or you or anyone else owes me anything. My apologies, I regret that the tone in my previous post implied that I thought so. I just felt we were going in circles discussing the same thing over and over. Although a little communication is kind of an implicit obligation when you take something like this public, it's not hard to tell what it means in this case. Absolutely, and I believe that obligation has been met by the MK maintainers (btw I don't consider myself one of them). cheers, Arnar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: twoDigitFloat bug
That's how floats work, 568.80 is represented internally as (roughly) 567.7999. numberFormatter rounds though, you can use numberFormatter(#.##)(568.80) which should give you what you want. On 10/8/07, Pedro Belo [EMAIL PROTECTED] wrote: Hey guys, I'm running into something that looks like a floating point problem, but I'm not sure about what can be done about it. The thing is: twoDigitFloat(568.80) returns 568.79. Just tested against the trunk, too. I've created a ticket in case anyone comes with a solution: http://trac.mochikit.com/ticket/275 Thanks, Pedro --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: How to get Signal.connect code rendered via .innerHTML replacement to work?
On 10/4/07, John Lorance [EMAIL PROTECTED] wrote: The Problem: I have a button on a page that results in getting HTML back from the server which contains something like the following (result['content'] (below) contains the following): innerHTML doesn't execute script. You could try something like this: var elem = getElement(target_id); elem.innerHTML = result['content']; var script_tags = getElementsByTagAndClassName(script, null, elem); for (var i = 0; i script_tags.length; i++) { eval(scrapeText(script_tags[i])); } I'm not sure if that works in all of the browsers, make sure to give it a try in the ones you care about. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Activity
On 10/3/07, scipio [EMAIL PROTECTED] wrote: On Aug 18, 11:59 am, Beau Hartshorne [EMAIL PROTECTED] wrote: On 18-Aug-07, at 8:44 AM, Lee Connell wrote: Mochikit hasn't seen any activity in the revision history at least since 06, is mochikit fading? We're pretty busy with our own projects, and haven't had much time to tag a release. /trunk is very stable, and is updated with features and bugfixes regularly: http://trac.mochikit.com/browser/mochikit/trunk Desparately short sighted: if you leave a web site untouched for a year, most people will assume its dead and move on. In discussions about JS client frameworks I've already seen several comments suggesting that MK development is dead. How hard can it be to tag the repository and update a couple lines of text on a web page? It's enough of a hassle. Honestly, I don't care if anyone uses MochiKit or anything else, they should pick whatever works for them. MochiKit is not a marketing exercise, I don't do consulting and I'm not terribly interested in speaking about JavaScript at conferences right now. We use it, it works great for us. I'd like to do a release, but I care a lot more about what my company is actually working on right now. MochiKit hasn't changed much lately because we got it to the point where it does what we want it to do and we haven't needed a whole lot else from it. The big mistake that I made was accepting a bunch of functionality that we had no intention of using internally, which is what's holding up the release because it doesn't pass quality control as far as code audit and docs go. I'm not really comfortable tagging what's in there as a release in its current state. If someone is truly interested in being the release manager for MochiKit they can step up and I'd be more than happy to give them full reign. I'll even give them a job (interview, anyway) if they want to move to San Francisco and do front-end work for us also :) -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: $ in jQuery, Prototype and Mochikit
MochiKit doesn't actually use $, it's just an alias for getElement that we export for the user's convenience. You can load whatever library you want after MochiKit and let it take over use of $, nothing will break. -bob On 9/2/07, jack.tang [EMAIL PROTECTED] wrote: Hi, all I blogged one case in my blog (http://jack.lifegoo.com/?p=163) which described the complaint of $ in jQuery, Prototype and Mochikit, could you please take it consider and reduce the conflicts? Thanks. /Jack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Comparing dates
On 8/28/07, grum [EMAIL PROTECTED] wrote: Hi everyone, I'm having problems comparing the following: isoTimestamp(2007-08-13T04:00:00+00:00) which gives me: Mon Aug 13 2007 00:00:00 GMT-0400 (EDT) and: Date() which (right now) gives me: Tue Aug 28 2007 16:14:12 GMT-0400 (EDT) ie. isoTimestamp(2007-08-13T04:00:00+00:00) Date() is returning false. I think it's something to do with the lack of quotes around the result of isoTimestamp - though quite what that means i'm not sure. Please someone help me out, i really need to be able to compare these dates. JavaScript's built-in comparison operators are no good for comparing objects, only strings and numbers. This is why MochiKit.Base.compare exists. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Deferred.addCallbackMethod
On 8/22/07, Giulio Cesare Solaroli [EMAIL PROTECTED] wrote: Hello, using the excellent MochiKit.Async module, I find myself writing the following code over and over: dererred.addCallback(MochiKit.Base.method(anObject, 'aMethod'), aParam, ...); It look like it would be nice to add a 'addCallbackMethod' to the Deferred class in order to be able to write the above statement like this: deferred.addCallbackMethod(anObject, 'aMethod', aParam, ); Well if you're importing MochiKit then you can just say method(anObject, 'aMethod') instead of MochiKit.Base.method, and then it's almost just as short as addCallbackMethod. I don't really see a reason to add more API. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: callLater and IE
On 8/21/07, Jonathan Marshall [EMAIL PROTECTED] wrote: Hi, I'm not sure if this is a bug in Mochikit, or my error. The following do not work in IE 6: script callLater(1, window.print); callLater(2, alert, 'drink beer'); /script yet these do: script function f() { window.print(); } function g() { alert('drink beer'); } callLater(1, f); callLater(2, g); /script Works beautifully in Firefox though.Tried with Mochikit 1.3.1 and a recent dump from SVN. Some of these built-in methods and functions aren't actual JavaScript functions and aren't compatible with Function.prototype.apply, so using MochiKit directly on them may not work. I think there's a workaround for it in MochiKIt that makes it work in Firefox and maybe Safari but I guess that workaround doesn't work properly in IE6. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Why No DL/DT/DD Functions?
They are not deliberately left out. If a patch were made to the documentation and code it'd be applied. -bob On 8/3/07, machineghost [EMAIL PROTECTED] wrote: Perhaps it'd be more helpful if I rephrased this question: If someone (ie. me) were to write createDOM shorthand functions for DL, DT, and DD, would whoever maintains Mochikit add them? Or are those functions for these elements deliberately left out of the library for some reason? Jeremy On Jul 31, 12:14 am, machineghost [EMAIL PROTECTED] wrote: The other day I noticed that there is no createDOM shorthand function for any of the definition list tags (DL, DT, and DD). Anyone know why? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Async status success return codes question
Implement a workaround. Just write an errback that turns 2xx into a successful response, that way your code will still work if the behavior eventually changes. On 7/31/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: So is this yet another thread on success codes that ends without consensus or a final word on success code meaning in MochiKit? Obviously I would prefer it if MochiKit treated all 2** as successes but if the decision is that this wont change then I'll just implement the work around and take it of my TODO list. So Bob can you provide the final word? Regards, Simon Cusack --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: MochiKit Development
On 7/18/07, Jason Bunting [EMAIL PROTECTED] wrote: I *am* curious as to the effort to get us to an official '1.4' release - seemed like there was a bit of momentum a few weeks/months back to get all bugs fixed and get it shipped, but then it seemed to die. I think that most or all of the bug fixes are done, IIRC it's a matter of auditing everything and making sure the docs are good. I've been really busy, and since MochiKit works as-is for us (svn trunk obviously doesn't bother me) I haven't needed to devote much time to it. I understand that this bothers some people, but I didn't develop MochiKit to do consulting and my company doesn't really do anything that would benefit from MochiKit being more popular. I also don't need a job and I haven't seen any AJAX conferences in interesting locations lately ;) Other than that, I think MK is near-perfect and find it interesting how people seem to feel that if a product/technology/etc. isn't constantly being developed, it is somehow not that great or not worth using; if MochiKit fulfills the measure of its creation (i.e. if its current state meets the goals set out for its original design/purpose), then why does it need to be continually developed? Some things just mature and are then good enough unless major bugs pop up. That's more or less how I feel about it. I do plan on getting to a 1.4 release, but I've got all of these other internal releases to worry about before that happens :) -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: create form in document
On 7/16/07, MerlinTheCat [EMAIL PROTECTED] wrote: Hi, I'm well versed in JS - but I've been struggling to understand MochiKit for a couple of days... help from anyone who can clear my brainblock would be appreciated. Thanks. I'm trying to add a form on the page dynamically. The H1 and [object Object] form? gets displayed on the page... but I can't see the form or access any of it's fields or submit it??? Here's my code: MochiKit.DOM.withWindow(self.window, MochiKit.Base.bind( function() { var doc = MochiKit.DOM.currentDocument(); MochiKit.DOM.appendChildNodes(doc.body, H1(null,This gets added OK)); var formObj = MochiKit.DOM.FORM({id:myForm, action:test01.asp, method:post}, {inputs: [{type:text, id:field1, name:field1, value:newval}, {type:submit, name:mySubmit, value:mySubmit}]}); MochiKit.DOM.appendChildNodes(doc.body, formObj); alert(doc.body.formObj.field1); // this indicates undefined? alert(doc.formObj.field1); // this indicates undefined? }, this)); That's because the code you wrote doesn't make any sense. {inputs: [ ... ]} isn't going to do anything. You need to do the same thing you're doing with FORM, except with INPUT. FORM(attrs, INPUT(attrs), INPUT(attrs), ...) -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Can't get 'this' to point to the right object
On 7/9/07, TiNo [EMAIL PROTECTED] wrote: Hi, I am having another problem with 'this' again. I have to classes (better said, that's how I would like them to behave), EditGrid and EditCell: --- var EditGrid = function (base_url,target_id) { bindMethods(this); this.base_url = base_url; this.target_id = target_id; [...] this._createGrid(); connect(window.document,'onkeydown',this._handleKey); } EditGrid.prototype = { [methods] } var EditCell = function (el,type,special_edit) { bindMethods(this); this.cell = el; this.type = type; this.special_edit = special_edit; info = el.id.split('_'); this.column = info.pop(); this.id = info.pop(); } EditCell.prototype = { [methods...] } --- When both get 'instantiated' from a javascript block on the html-page there is no problem. 'this' refers in both cases to them selfs as an object. But when I try to 'instantiate' one of them from the same javascript file (be it from the bottom line of the script, or calling EditCell from EditGrid), this refers to 'window'. What can I do about this? There's a bug with the interaction between bind and connect. You either need to upgrade to MochiKit from SVN, or you need to write the connect as: connect(window.document,'onkeydown',this, '_handleKey'); -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: 'this' and addCallbacks
On 7/9/07, kael [EMAIL PROTECTED] wrote: This doesn't work. When the callback, dataReciever, is called it doesn't know what 'this' is any more. I want dataReciever to update the object and then call this.showRecord. SBP.prototype.dataReceiver = function(data) { // data is an array of (id,text) things alert(this.divID + ' dr') // here, this.divD is undefined this.data=data; this.idx = 0; this.showRecord(idx); }; SBP.prototype.refreshRecords = function (){ epReq=loadJSONDoc(this.refreshJSON); epReq.addCallbacks(this.dataReceiver,alertFailed); alert(this.divID) // this.divD here is correct }; Does anybody care to point out the problems in the design? Two major problems in the design. 1. Your code expects something asynchronous to happen as soon as the next line of code executes. Asynchronous code by definition doesn't work like that. Even if the code wasn't otherwise broken, alert(this.divID) will never work where you put it. You can only access it after the callback has happened, which means you either make a second callback or you add it to the end of the code in your existing callback. 2. JavaScript doesn't have bound methods. You can't use this.dataReceiver as a callback. You can use method(this, dataReceiver) though, which will do the right thing. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: 'this' and addCallbacks
On 7/9/07, Bob Ippolito [EMAIL PROTECTED] wrote: On 7/9/07, kael [EMAIL PROTECTED] wrote: This doesn't work. When the callback, dataReciever, is called it doesn't know what 'this' is any more. I want dataReciever to update the object and then call this.showRecord. SBP.prototype.dataReceiver = function(data) { // data is an array of (id,text) things alert(this.divID + ' dr') // here, this.divD is undefined this.data=data; this.idx = 0; this.showRecord(idx); }; SBP.prototype.refreshRecords = function (){ epReq=loadJSONDoc(this.refreshJSON); epReq.addCallbacks(this.dataReceiver,alertFailed); alert(this.divID) // this.divD here is correct }; Does anybody care to point out the problems in the design? Two major problems in the design. 1. Your code expects something asynchronous to happen as soon as the next line of code executes. Asynchronous code by definition doesn't work like that. Even if the code wasn't otherwise broken, alert(this.divID) will never work where you put it. You can only access it after the callback has happened, which means you either make a second callback or you add it to the end of the code in your existing callback. Sorry, I misread the code. It looked like you were setting the divID in the callback. Ignore this part. 2. JavaScript doesn't have bound methods. You can't use this.dataReceiver as a callback. You can use method(this, dataReceiver) though, which will do the right thing. This still applies though. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Async status success return codes question
On 7/5/07, Karen J. Cravens [EMAIL PROTECTED] wrote: On Jul 5, 8:19 pm, Bob Ippolito [EMAIL PROTECTED] wrote: with (the ones that you actually run into in the wild). It's easy to Given the increasing popularity of REST, seems pretty likely you'll start running into a wider range of response codes in the wild. It's kind of disturbing to learn it's that noncompliant; we haven't settled on a library yet, but Mochikit was the front-runner for me. Now I'm back to I dunno, let's put all the names in a hat and pick one, since Wirebird makes use of pretty much the full range of HTTP responses. As demonstrated it's effectively three lines of code to do whatever you want to do with HTTP status codes, and you only have to write it once. If that really makes such a difference, then I doubt MochiKit is the right choice for you. There are many cases where you actually have to write code, but MochiKit's behavior is well documented so at least you know what it's going to be doing. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Async status success return codes question
On 7/6/07, Karen [EMAIL PROTECTED] wrote: On 7/6/07, Bob Ippolito [EMAIL PROTECTED] wrote: As demonstrated it's effectively three lines of code to do whatever you want to do with HTTP status codes, and you only have to write it once. If that really makes such a difference, then I doubt MochiKit is the right choice for you. There are many cases where you actually have to write code, but MochiKit's behavior is well documented so at least you know what it's going to be doing. Yes, I saw the example, but it's more of a philosophy issue... it's a matter of the right tool for the task. I need a stickler-for-the-rules RFC-compliant library; Mochikit seems to have a more pragmatic approach. This works 99% of the time, but I'm that obscure 1%. It works 100% of the time. If you're doing something obscure with status codes (anything obscure, even successful codes that aren't 2xx), you need to use an extra three lines of code in this case. That doesn't mean it's broken. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Async status success return codes question
On 7/6/07, Karen [EMAIL PROTECTED] wrote: On 7/6/07, Bob Ippolito [EMAIL PROTECTED] wrote: It works 100% of the time. If you're doing something obscure with status codes (anything obscure, even successful codes that aren't 2xx), you need to use an extra three lines of code in this case. That doesn't mean it's broken. It means it's not RFC-compliant out of the box. I'm not saying that's a bad thing overall (the other 99% of the time, you don't want overhead for bits that almost no one uses), I'm just saying it's a bad fit for me. Three lines of code for this fix and that does start to add up; at a certain point it becomes more efficient to start with a more low-level library rather than try to impose a new design philosphy on a more advanced one. Given that you can write your own functions, and those functions can call other functions, you only have to do it once. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Async status success return codes question
On 7/5/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I have been working with Async to build an inhouse web app, we have ended up using the return codes to implement some interesting behaviour in our clients. MochiKit is just one of the clients that uses the web service and some of our other processes (robots essentially) look for return codes to act upon. One of these codes is 202 - Accepted. We use this in response to requests that fire off long running processes in the server. The server responds with a 202 saying that it is now running the process and includes a location header to indicate where the client should go to get updates on the current status of the process. By default MochiKit doesn't treat a 202 as a success. MochiKit is written mostly with practical considerations in mind, and it only knows how to handle the specific success codes that it deals with (the ones that you actually run into in the wild). It's easy to make it do what you want though... something like this: function http_2xx_ok(err) { if (err instanceof XMLHttpRequestError err.number = 200 err.number 300) { return err.req; } throw err; } var d = doXHR(...).addErrback(http_2xx_ok).addCallback(...); -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: 'this' gets overridden on every function call
On 6/20/07, TiNo [EMAIL PROTECTED] wrote: With the following code (shortend): -- var EditGrid = function (base_url, target_id) { bindMethods(this); this.base_url = base_url; this.target_id = target_id; this.editing = false; this.direction = 6; //forward, see your numpad this.editcell = null; this.render(); } EditGrid.prototype = { render : function(params) { params = params || {}; params = eval(params); params['tg_random'] = new Date().getTime(); params['tg_format'] = json; var d = loadJSONDoc(this.base_url + '/get_data', params); d.addCallback(this.createGrid); return d; }, createGrid : function(response) { var grid = Widget.editgrid.render(this.target_id, response); swapDOM(this.target_id, grid); connect(window,'onkeydown',this.handleKey); }, editCell : function(e) { [...] }, handleKey : function(e) { [...] if(e.key()['string'] == 'KEY_ESCAPE') { this.abort() e.stop() } [...] }, abort : function(e){ var editcell = this.editcell; if(!this.editing) return; swapDOM(editcell.firstChild,document.createTextNode(this.original)); this.editing = false; this.original = null; this.editcell = null; if(e)e.stop(); } [etc...] } - I have the following problem: the 'this' variable is overwritten by the EditGrid function every time one of its methods is called. Example: editCell is called on onclick on a tablecell, it thereby sets this.editcell to the target cell, and this.editing to true. But when the handleKey method is called by a onkeydown, this.editing is set to false, and this.editcell to null, like the values they had initially. What am I doing wrong? There was a bug in connect that interfered with bind(). You can either upgrade to the latest svn trunk, or change this: connect(window,'onkeydown',this.handleKey); to this: connect(window,'onkeydown',this, 'handleKey'); -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: MochiKit DOM manipulation performance?
On 6/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Hi I've been reading a bit about some optimised DOM manipulation libraries developed for the yui-ext, jQuery and Dojo toolkits: http://www.jackslocum.com/blog/2007/01/11/domquery-css-selector-basic-xpath-implementation-with-benchmarks/ http://jquery.com/blog/2007/01/11/selector-speeds/ http://dojotoolkit.org/node/336 This discussion occurred in January/February of this year, and the upshot was that these toolkits were drastically improving their DOM manipulation performances. MochiKit gets mentioned in the benchmark done on domQuery (the yui-ext engine), and performs horribly (10 to 100 times slower than domQuery, if the test is to be believed). My question is, are these benchmarks accurate, and if so, what has been done since to improve MochiKit's DOM performance? This is a very particular kind of DOM query (CSS selector emulation) that is currently experimental in MochiKit SVN trunk. It has not yet been optimized, but it's also not currently used internally by MochiKit. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Different search result for different browser
On 6/17/07, tired [EMAIL PROTECTED] wrote: When I try to search on JSON file with same search key in different browser with sortable table, the result is different. IE6 shows only those results (row) where search character(s) arrive at the very beginning (like first letter(s) of sentence) of the data. Why not getting the result like FireFox (looks appropriate). You're probably going to need to show some code. Your description doesn't really have enough information to determine why you're seeing that. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: How prevent mochikit from html entity decode of sortable data?
On 6/15/07, tired [EMAIL PROTECTED] wrote: I have used the 'mochikit sortable' table to sort data (loading a json file through ajax). In that table one of columns has linked data which htlml entity decoded by mochikit, so it show raw html instead link. For example, I supplied the data like a href=drink-details.php?drink_id=153Red Wine Glass: Use for red or white wine (if you don't have a white wine glass), or water./a But mochikit show it like, lt;a href=drink-details.php?drink_id=153gt;Red Wine Glass: Use for red or white wine (if you don't have a white wine glass), or water.lt;/agt; That is it decode the '' and '' to 'lt' and 'gt'. Anybody help me how to prevent this type decoding? It's not decoding anything, the DOM works with nodes not markup. Text turns into text nodes. In order to turn literal HTML into a DOM node you'll have to use something like this: function htmlDiv(htmlText) { var s = DIV(); s.innerHTML = htmlText; return s; } -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: createDom option example please
On 6/15/07, hotani [EMAIL PROTECTED] wrote: Ok. Like I say, this is not very clear to me right now, and I'm trying to create an option list for a drop-down. Let me put up my shot-in-the-dark example, then maybe someone can correct me: // add a single value/text option to drop-down: OPTION(null, {'value': '123', 'text': 'some text'}); Trying to create this: option value=123some text/option and a bunch more if everything goes well The first argument is attributes, additional arguments are contents. OPTION({'value': '123'}, some text); -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: MochiKit.Async, synchronousness, and testing
On 6/11/07, GK [EMAIL PROTECTED] wrote: I've been Googling around looking for tools to help with testing of asynchronous code using mochikit's Deferred's. The only thing I found so far was this post from over a year ago, to which there was no response. http://groups.google.com/group/mochikit/msg/53af9c5dece6e576 What I'm looking for is something akin to the 'twisted.trial.unittest' package that extends a synchronous unit test framework to handle deferred results. Ideally, I'd like to be able to mix synchronous and deferred tests in a single suite. I think I can see a way to achieve this, effectively absorbing all the tests into a reactor monad (wrapping any synchronous values in mochikit.async.succeed) and supplying a testrunner that collects the results and analyzes them when all deferreds have fired. But before I spend too much effort trying to figure the details of doing this, I'd be interested to hear if anyone has already done anything similar for mochikit. How about looking at how MochiKit.Async's tests work? -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Arabic Spam
On 6/10/07, Arnar Birgisson [EMAIL PROTECTED] wrote: On 6/9/07, Bob Ippolito [EMAIL PROTECTED] wrote: I've just changed the moderation settings to moderate all messages from new users. I'm not sure how much that's going to help though. I'll volunteer as a moderator if you like. I'm in timezone GMT+0 Excellent. You should have permission to moderate now. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: getNodeAttribute Doesn't Work In An OnFocus Handler
On 5/22/07, MikeC [EMAIL PROTECTED] wrote: It seems that I am being forced to not use getNodeAttribute in one instance. I created a small example (see below) of where it seems to fail. My little example contains two text boxes. You enter some text in the first one and the onfocus handler for the second text box will show you (via an alert function) the content of the first box. The problem is that it doesn't work using MochiKit's getNodeAttribute. But it does work using the less desirable construct... text1Val = document.TheForm.text1.value; Thanks for any explanation of why this is the case. I'm not entirely sure why it doesn't work.. but it's probably because you're going through the ancient form API rather than the DOM API. I don't see any real reason to prefer getNodeAttribute for value in this case. Do you like it because it's slower and less direct? ;) -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: IE6 problem with OPTION
On 5/17/07, Paul [EMAIL PROTECTED] wrote: So I'm trying to create a page that will populate a collection of SELECT's using some AJAX requests. The AJAX part goes fine and I get data back from the server, it's just when I'm trying to create new options that I'm running into problems with IE6 For example: dataTarget = getElement('id_mySel') //This is just a generic SELECT dataTarget.options[dataTarget.options.length] = OPTION({'value' : 1}, 'Some text'); On Firefox that code works perfectly fine, but with IE6 it fails with Object doesn't support property or method replacing OPTION with new Option('Some text', 1) works perfectly fine. Bug (in IE)? This happens with Mochikit checked out from SVN @ rev 1292 IE 6.0.2900.2180.xpsp_sp2_gdr.070227-2254 WinXP Pro SP2 Have you tried using DOM functions instead? Something like this: appendChildNodes(id_mySel, OPTION({value: 1}, some text)); -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Does Mochikit accept patches for Format.LOCALE ?
On 5/16/07, Roger Demetrescu [EMAIL PROTECTED] wrote: If it is possible, could you guys add this brazilian-portuguese locale to MochiKit.Format.LOCALE ? ... pt_BR: {separator: ., decimal: ,, percent: %}, ... Ok, it's in r1292. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: evalScripts:true equivalent in Mochikit?
On 5/15/07, Spiderr [EMAIL PROTECTED] wrote: Thanks Kevin, This works great! This seems a very fundamental thing to want to do... am I missing something? Why isn't this in Async.js or similar? It's not really that common. Most people using MochiKit are loading data, not code, and if they are loading code then it's usually not mixed with other stuff. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Bug in queryString?
On 5/3/07, Arnar Birgisson [EMAIL PROTECTED] wrote: Hi all, The current svn version of queryString gives me something unexpected on this queryString({nonni:null, x:3}) It gives me a silent error and no result. The docs say attributes with null values or undefined will be skipped, so I was expecting x=3 here. Further investigation shows that the line that fails is Base.js:1115: typeof(v.length) == number I assume this is failing because null has no .length property. Am I doing something wrong here? I find it unlikely that no-one has bumped into this before since this affects everything that uses queryString, including loadJSONDoc. If this is clearly a bug, I'd only be happy to commit a fix. Sounds like a bug. Please commit a test that fails, then commit a fix :) -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Fix for CVE-2007-2381
On 5/1/07, Konstantin Ryabitsev [EMAIL PROTECTED] wrote: Hello: Will there be a fix for http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-2381 in the 1.3.1 branch? Nope. It's not a real security issue, not with MochiKit anyway. The recommended fix would mean supporting some junk that's not JSON anymore. I've already caved and put said support on the trunk just so people would shut up about the issue, but I'm certainly not going to make a maintenance release to fix this non-issue. Ensuring that your server only sends JSON when properly authenticated, or otherwise sending only non-exploitable JSON (e.g. JSON with an object envelope) is the only solution to this problem. Only a very small subset of JSON, specifically [array, envelope, json] is susceptible to this data leakage attack. Don't send that stuff on the server-side, and there is no problem. Most people don't send array envelope JSON anyhow. Either way, totally irrelevant to the client-side. It's like saying that we should fix browsers so that they can't be used to mount a SQL injection attack on a poorly written service. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---