Re: [mochikit] Does anyone use this?

Um, I still use it daily, on projects new and old. It gets the job done, and the logo makes me happy. I charge extra if a client insists on jQuery. > On May 25, 2017, at 11:04 PM, Bob Ippolito wrote: > > I don't think anyone is building anything new on MochiKit at this

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 Birgisson wrote: > Prototype was one of the main contenders towards the end, before jQuery > took over. When I started

Re: [mochikit] Does anyone use this?

Indeed: https://github.com/google/closure-library/blob/master/closure/goog/dom/dom.js#L16-L17 So I guess mochikit lives at my new employer too! ab On Fri, May 26, 2017 at 5:26 AM, Chaz Gatian wrote: > Sounds like there was quite a vibrant community of developers

Re: [mochikit] Does anyone use this?

> > Sounds like there was quite a vibrant community of developers consuming >> the framework. I loved digging through the source code. > > I actually stumbled upon this while viewing the JavaScript source in Google Photos. Surprised to see such an old web framework is still used in portions

Re: [mochikit] Does anyone use this?

> On 26 May 2017, at 07:55, Arnar Birgisson wrote: > > Must say thanks to Bob, Thomas, and Per for putting it out and maintaining. > It was an enormous value in my work back then, Ditto. > and I'm sure that code is still running at my old company. The code eventually got

Re: [mochikit] Does anyone use this?

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

Re: [mochikit] Does anyone use this?

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

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 Gatian

[mochikit] Does anyone use this?

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

Re: [mochikit] Re: Server side Javascript logging

Really? This thread is more than 4 years old. I'm sure jslogger is a fine product, but this is just border line of spam. On 26 May 2013 18:20, Dumitru Glavan dumitru...@gmail.com wrote: You might try JSlogger http://jslogger.com - we built it exactly for the same reason. We have a couple of

Re: [mochikit] Re: Server side Javascript logging

Sorry, was just helping out :) Didn't notice the date... On Sunday, May 26, 2013 7:34:44 PM UTC+2, troelskn wrote: Really? This thread is more than 4 years old. I'm sure jslogger is a fine product, but this is just border line of spam. On 26 May 2013 18:20, Dumitru Glavan

[mochikit] Re: Can not doSimpleXMLHttpRequest in local

resolve. File that I had broken pack. -- You received this message because you are subscribed to the Google Groups MochiKit group. To view this discussion on the web visit https://groups.google.com/d/msg/mochikit/-/cg-Lcy7bOBsJ. To post to this group, send email to mochikit@googlegroups.com.

[mochikit] Multiselect List

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

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

[mochikit] Re: Is MochiKit Dead?

Ok. I'll see what I can do. Most of it are obviously pure additions and should be fairly easy to add. But for example the changes to bind to support placeholder arguments and introducing value propagation in the Deferreds might require some more discussion. Happy to get some comments here. I'll

[mochikit] Re: Is MochiKit Dead?

I've had similar thoughts. jQuery is king of the DOM nowadays, no need/use to compete with overlapping low-level features there. I think the Python heritage should continue to be embraced though. When looking at underscore lib I kindof like it but that's mostly because lots of it already exists in

Re: [mochikit] Is MochiKit Dead?

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

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

Re: [mochikit] Is MochiKit Dead?

Agreed. Nowadays I'm also in maintenance-only-mode with respect to MochiKit. Meaning that I'll only address critical bugs or merge well-documented tested patches. The MochiKit.Text module and version 1.5 won't progress further unless someone else steps up to do the work. That said, I'm still

[mochikit] Is MochiKit Dead?

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

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

[mochikit] getstyle z-index is 0px for IE8

hi! konnitiha z-index:0 is 0px for IE8 bug? 1 is 1. maybe only zero. i dont no IE9 thank you. -- You received this message because you are subscribed to the Google Groups MochiKit group. To view this discussion on the web visit https://groups.google.com/d/msg/mochikit/-/XMsIf4RyvgIJ. To

[mochikit] Callaback parameters (follow..)

Sorry I have corrected my errors. The problem now is that my field ctx.user.data is not modified... function FormController(){ this.user = { name: ALBATOR, valide: true, data : TEST } } FormController.prototype = { fetchdata: function () { this.user.data =

[mochikit] Re: Callaback parameters (follow..)

You're confusing loadJSONDoc with a JSONP/XSS call. loadJSONDoc uses standard xmlhttprequest, thus your call to twitter fails due to the same domain restrictions. Currently MochiKit doesn't have a JSONP call. Could be added though, this has been discussed before. Something like this should work

Re: [mochikit] Re: MochiKit.I18n -- proposed new module for internationalization

Once again, the jQuery-route seems to be the way to go. I'll abandon my dev branch for now. Cheers, /Per On Wed, Jan 12, 2011 at 00:59, Fredrik Blomqvist fblomqv...@gmail.com wrote: FYI. Before I noticed this thread I and Per exchanged couple of ideas @github.

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] MochiKit.I18n -- proposed new module for internationalization

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

[mochikit] typeName() function -- introspecting object types

Being tired of all the idiosyncrasies of the typeof() operator, I tried to make something better:    function typeName(value) {        if (typeof(value) !== object !(value instanceof RegExp)) {            return typeof(value);        } else if (value == null) {            return null;        }

[mochikit] Async Deferred discussion

Hi, Since MochiKit pioneered JavaScript implementation of the Deferred pattern I thought I'd make you aware of two current discussions regarding this on the Google Closure library mailing list. (Google's initial Deferred impl is actually a port from MochiKit, see

Re: [mochikit] Re: Mochikit.signal and DOM objects that don't exist yet (like jQuery.live)

On 2010-12-05, at 18:11 , ryanwil...@gmail.com wrote: On Dec 4, 5:58 am, Per Cederberg p...@percederberg.net wrote: 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

[mochikit] Re: Mochikit.signal and DOM objects that don't exist yet (like jQuery.live)

On Dec 4, 5:58 am, Per Cederberg p...@percederberg.net wrote: 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.

Re: [mochikit] Mochikit.signal and DOM objects that don't exist yet (like jQuery.live)

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

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

Re: [mochikit] Does the BSD license need to be mentioned?

Thanks for your feedback! I've updated the license text in the MochiKit repository with your patch: http://github.com/mochi/mochikit/commit/60ac9815cb6a4d63a90936777ea7dc836caf7e94 We'll use the updated license for the 1.5 release (whenever that'll be), but there are no current plans for

[mochikit] Re: Possible bug in MochiKit.Base.compare

Some more input regarding comparisons. Found this in the Python 3 changelog: http://docs.python.org/release/3.0.1/whatsnew/3.0.html#ordering-comparisons Essentially they've decided to tighten the rules, making all the examples I listed above throw a: TypeError: unorderable types: exception.

[mochikit] Re: Iter: __iterable__ support?

...OK... for some reason (many links?) Google apparently decided to queue my messages *much* longer than usual. My very first reply is still totally lost for example.. But, now I see my other attempts at re-posting showed up all at once.. Sigh... :( Apologize for the spam! // Fredrik Blomqvist

Re: [mochikit] Re: Iter: __iterable__ support?

Thanks, I was afraid there was some even more subtle issue involved. I've now re-enable it in my fork of MochiKit, see: https://github.com/blq/mochikit/commit/1352ea316184b83ccffc30d19d65faa0431ce43b Unit tests pass but I'll let it spin around in my code for a while before merging it into MochiKit

[mochikit] Re: Iter: __iterable__ support?

ok, thanks. I was afraid there was some more subtle issue I missed. I guess I'll simply throw it in again in, initially in my fork, and see if it breaks anything (different browsers...). If successful I'd say it should be re-enabled. (.. by the way, speaking of iterators, I have been doing a lot

[mochikit] Re: Iter: __iterable__ support?

Thanks, I was afraid there was some even more subtle issue involved. I've now re-enable it in my fork of MochiKit, see: https://github.com/blq/mochikit/commit/1352ea316184b83ccffc30d19d65faa0431ce43b Unit tests pass but I'll let it spin around in my code for a while before merging it into MochiKit

[mochikit] Re: Iter: __iterable__ support?

Thanks, I was afraid there was some more subtle issue involved. I've now re-enabled it in my MochiKit fork, see: https://github.com/blq/mochikit/commit/1352ea316184b83ccffc30d19d65faa0431ce43b Unit-tests pass, but I'll let it spin around in my code for a while before a merge into MochiKit master.

[mochikit] Re: Iter: __iterable__ support?

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,

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__ !==

[mochikit] can log but unable to return value from addCallback

I can log the value, but it returns as undefined. var getOffice = function(county_id) { var d = loadJSONDoc('/office_from_countytype/'+ county_id +'/'); var off_id; d.addCallback(function (result) { off_id=result[0].fields['office']; log('got office id: '+ off_id);

[mochikit] Re: can log but unable to return value from addCallback

You're confusing the return inside addCallback with the return from the outer getOffice function. --- modified example: var getOffice = function(county_id) { var d = loadJSONDoc('/office_from_countytype/'+ county_id +'/'); var off_id; d.addCallback(function (result) {

[mochikit] Re: can log but unable to return value from addCallback

thanks for the response - I'll give this a try. I'm still trying to wrap my head around the concepts of deferred and callbacks On Nov 15, 2:45 pm, Fredrik fblomqv...@gmail.com wrote: You're confusing the return inside addCallback with the return from the outer getOffice function. ---

[mochikit] Introspecting object types

Being tired of all the idiosyncrasies of the typeof() operator, I tried to make something better: function typeName(value) { if (typeof(value) !== object !(value instanceof RegExp)) { return typeof(value); } else if (value == null) { return null;

[mochikit] Re: Possible bug in MochiKit.Base.compare

similarly you also have: # compare(0, '') == 0 # compare(0, []) == 0 .. But, equivalence is one thing, defining meaningful ordering is more difficult. A quick take in Python gives this table (didn't check the standard): -- '' == [] False '' [] False '' [] True 0 '' True 0 ''

[mochikit] Possible bug in MochiKit.Base.compare

While writing some MochiKit tests, I stumbled upon the following: # compare(, []) == 0 # == [] == true Seems like the JavaScript type coercion is used inside compare(): compare: function (a, b) { if (a == b) { return 0; } ... But perhaps that was

[mochikit] Code comments in MochiKit sources

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

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 --

Re: [mochikit] MochiKit moving to github

The download customization is now working. You can reach it here (also linked from the new web site): http://mochi.github.com/mochikit/packed/MochiKit/customize.html Regarding tickets, if you are a stakeholder, please look through the list and re-submit the ones you still think applies in the

[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

[mochikit] Re: svn.mochikit.com and trac.mochikit.com down

On 2010-10-06 19:20:23 +0200, Ethan Jucovy said: 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? Apparently

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

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

[mochikit] Re: SpiderMonkey and MockDOM Issues

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

Re: [mochikit] Re: SpiderMonkey and MockDOM Issues

When svn.mochikit.com is back up you can easily create your own packaged version without any of the DOM packages. Don't know if any of the magic initialization code in MochiKit uses the navigator, window or document objects, but I guess they should detect if they are missing. Otherwise we have a

[mochikit] Re: svn.mochikit.com and trac.mochikit.com down

citethey haven't destroyed it entirely/cite hope so. btw what is the last repo revision? On Oct 7, 6:52 pm, Bob Ippolito b...@redivi.com wrote: 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

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

[mochikit] Re: svn.mochikit.com and trac.mochikit.com down

thanks Bob it is alive On Oct 7, 9:58 pm, stranger pipy...@gmail.com wrote: citethey haven't destroyed it entirely/cite hope so. btw what is the last repo revision? On Oct 7, 6:52 pm, Bob Ippolito b...@redivi.com wrote: It looks like the ops team at Mochi has decommissioned the machine

[mochikit] SpiderMonkey and MockDOM Issues

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

[mochikit] svn.mochikit.com and trac.mochikit.com down

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

Re: [mochikit] Mochikit.js does not download from Apache 2.2.3 on Centos 5.4/5.5

On Jun 9, 2010, at 8:42 PM, jonauman 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

[mochikit] Mochikit.js does not download from Apache 2.2.3 on Centos 5.4/5.5

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

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

[mochikit] Additional information for a bug

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

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

[mochikit] Bug in Iter.chain

Here is a firebug log to show the bug, present in mochikit 1.4.2, and according to a test I did, also in mochikit 1.5: list([1]) [1] list(chain([1],[2])) [1, 2] list(chain([1],[2],[3])) [1, 2, 3] * list(chain([],[],[3])) []* list(chain([1],[2],[3])) [1, 2, 3] list(chain([],[2],[3])) [2, 3] *

[mochikit] Re: Future plans/timeline for Mochikit?

I strongly encourage you to continue. MochiKit is by far the best implementation of a js-framework I have seen as of yet...most others have weird structure and don't do it python-esque-enough...:) /Alex On Mar 11, 9:19 pm, Per Cederberg cederb...@gmail.com wrote: No, there is no timeline. I

[mochikit] Future plans/timeline for Mochikit?

I only recently discovered that, as opposed to what the website itself let believe (release feed, official blog, and even Bob's blog), MochiKit was not unmaintained since November 2008, and that there was in fact quite a bit of activity on 1.4.3 and 1.5 branches, and even a sizzle/selectors

Re: [mochikit] Future plans/timeline for Mochikit?

No, there is no timeline. I planned a 1.4.3 bugfix release, but haven't noted any particular interest for it. Seems most people (like me) just use the svn trunk version right now. On the topic of version 1.5, it seems work on it has mostly paused. Some additions are included, but my own time for

Re: [mochikit] Providing patch for ticket #361

Thanks for the patches, Niek! They've now been applied to svn trunk. Cheers, /Per On Fri, Feb 19, 2010 at 09:32, Niek Kouwenberg niek.kouwenb...@gmail.com wrote: Okay, Attached you'll find 361.patch for bug #361. I also added a patch for bug #246, which was fairly simple. On Thu, Feb 18,

[mochikit] Patch for ticket #329

MochiKit.Base.serializeJSON fails for objects with a 'length' property This method used an 'is array like'-like check, instead of a strict 'is array' check. The provided patch replaces the if-statement with the isArray checks as implemented in Prototype.js and jQuery. This does not break existing

Re: [mochikit] Patch for ticket #329

I think the proper type check would be better written as o instanceof Array. Also, previously we've been very cautious with breaking backwards compatibility. The existing code supports JSON-serialization of array-like structures, something that wouldn't be supported by the new code. Perhaps we

[mochikit] Re: Patch for ticket #329

I see. In that case we can just try to serialize the JSON string for an array-like object, and on failure (incorrect length property) fallback to the object-like serialization. A simple try-catch will fix this. I've attached a different patch which is backward compatible and fixes this bug. --

Re: [mochikit] Providing patch for ticket #361

Okay, Attached you'll find 361.patch for bug #361. I also added a patch for bug #246, which was fairly simple. On Thu, Feb 18, 2010 at 5:37 PM, Bob Ippolito b...@redivi.com wrote: You can send it here to the list On Thu, Feb 18, 2010 at 3:18 AM, niek.kouwenb...@gmail.com

[mochikit] Providing patch for ticket #361

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

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.

[mochikit] Async issue in FF

Hi, I'm having some problems with the mochikit.async code in FF (only tested in 3.6), whereas it works as expected in IE6/7 and Chrome. I do something akin to: function doIt() { ... var myresult = doSimpleXMLHttpRequest( url, { foo : bar } ); myresult.addCallback( function(result) {

[mochikit] Re: Packing on the function level

Thanks Fredrik, that's exactly what I'm looking for.. No luck compiling a packed version of MochiKit (1.5) and trying to connect a signal - I get an error MochiKit.i is undefined. The closure inspector isn't working for me (FireBug 1.5.0) so I'm afraid I can't further investigate at this time

Re: [mochikit] Re: Packing on the function level

Don't want to send stop-energy around, but is it really worthwhile to pack MochiKit like that? I mean, the full MochiKit.js is only 197,5 kB uncompressed. And the customizer we already have lets you pick quite freely on the module level. Have you double-checked what type of performance increases

[mochikit] Packing on the function level

Has anyone made an attempt to pack up MochiKit omitting functions that are not used? e.g. include DateTime.toISODate but not DateTime.toPaddedAmericanDate if the latter doesn't happen to be called in a given file. I realise this would be non trivial to do automatically.. -- You received this

[mochikit] Re: Packing on the function level

This should be possible using the Google Closure compiler: http://code.google.com/closure/compiler/ (Some issues to watch out for: http://code.google.com/closure/compiler/docs/api-tutorial3.html#dangers) I hope to find time to try this myself also, please report back about your progress! Would

[mochikit] connect to keyboard events not working in FireFox?

Hi, The following works for me in IE, Chrome and Safari, but fails in FireFox 3.6 (running on Vistax64). The 'key down' event just doesn't seem to get received: = html head script type='text/javascript' src='MochiKit.js'/script script

[mochikit] Re: connect to keyboard events not working in FireFox?

I investigated further and I think you're right. However I found an easier solution: binding the event to the window instead of the body works without any tab index. However it does *not* work in IE. Sigh - browser specific hacks either way. In any case it's not MochiKit's fault: I verified

[mochikit] Congratulations

Congratulations to Bob and his team, again. Simply awesome. Regards, David -- David Janes President, Discover Anywhere Mobile davidja...@discoveranywheremobile.com joa...@discoveranywhere.ca +1 416-785-4425 -- You received this message because you are subscribed to the Google Groups "MochiKit"

[mochikit] MochiKit.Animator and sizzle branch

I was updating one of my projects which uses MochiKit and I thought to look what's new in MochiKit development. My project doesn't use visual effects, but I thought with the next version I might do some effects. I found that Karl Guertin's Animator pages weren't up. From emailing him, I learned

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.

[mochikit] JSON.parse MochiKit.Base.evalJSON

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

[mochikit] Re: MochiKit.DOM.getElementsByTagAndClassName performance

On Nov 5, 2009, at 1:32 AM, Fredrik wrote: I created a getElementsByClassName based on this code: http://robertnyman.com/2008/05/27/the-ultimate-getelementsbyclassname-anno-2008/ http://code.google.com/p/getelementsbyclassname/ Pending a full selector integration something like this

[mochikit] Google Closure includes MochiKit

Hi, Google recently announced their core javascript library - Closure. http://code.google.com/closure/library/ When browsing the code I noticed it uses parts of MochiKit: http://code.google.com/p/closure-library/source/browse/trunk/closure/goog/dom/dom.js

[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

[mochikit] MochiKit.DOM.getElementsByTagAndClassName performance

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

[mochikit] Re: MochiKit.DOM.getElementsByTagAndClassName performance

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.

[mochikit] Lets flirt or...

Hello to this group, Im newbie here. Life is boring and uninteresting, entertain me :) Lets flirt or maybe something more? Im here: http://camelliaelfr.150m.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups

[mochikit] Re: MochiTAL

I can't answer the question directly about MochiTAL, but when I saw MochiTAL more than a year ago I decided to write a more complete implementation of TAL in javascript called jstal. I have combined jstal with an XSLT implementation (tal2xslt) into a single package ATALi (Alternate TAL

[mochikit] MochiTAL

Hi, I am new to JavaScript and to Mochikit, but I've seen enough of it (Mochikit) to get very much interested about it. I am currently looking into the Ajax Tables example from the Mochikit web site, and I have to confess that I am a little bit confused about the MochiTAL processing. So, I

[mochikit] Re: Defered.setFinal

Hello all, On Tue, Feb 10, 2009 at 6:48 PM, Bob Ippolitob...@redivi.com wrote: 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

[mochikit] Ticket #352: Adding MochiKit.DateTime.toISOTime arguments to the API

In ticket #352 the realISO parameter in the MochiKit.DateTime.toISOTime() function is discussed: http://trac.mochikit.com/ticket/352 It was introduced by Bob in r377 (some 4 years ago), but never added to the documentation or the official API: http://trac.mochikit.com/changeset/377 Is it

[mochikit] Re: Defered.setFinal

Slow response here, but I finally got around to committing this to Subversion (r1533): http://trac.mochikit.com/changeset/1533 Modified the patch a bit further to account for some additional cases. Also added tests and documentation. @Bob: Can you please review this change? I have the

  1   2   3   4   5   6   7   8   9   10   >