[mochikit] Re: Defered.setFinal
Hi Per,
I have just tested the changes with the Ajax extension module and it
works as expected. Thanks for considering adding this feature. This
would help me creating jQuery compatible Ajax module for Mochikit
extensions project.
Currently, I'm quite busy with some another work but supposed to come
back on MochiKit Extensions soon...
Regards
--
Amit Mendapara
On Jul 20, 2:26 pm, Per Cederberg cederb...@gmail.com wrote:
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 feeling that I've
still missed one or two corner cases... Also, the mochikit.com and
trac.mochikit.com site seems slow from here... High server load
recently?
@Amit: Please check that my additional controls doesn't break you use case.
Cheers,
/Per
On Wed, Feb 11, 2009 at 14:52, Amit Mendaparamendapara.a...@gmail.com wrote:
Even better...
if (this.chain.length == 0 this._finalizer) {
this._finalized = this._finalizer(res);
}
This will allow us to finalize the deferred based on some
conditions...
- Amit
On Feb 11, 12:52 am, Per Cederberg cederb...@gmail.com wrote:
You mean like this?
setFinalizer: function(cb) {
this._finalizer = cb;
}
...
if (this.chain.length == 0 this._finalizer) {
this.finalized = true;
if (res instanceof Error) {
this._finalizer(res);
}
}
Would that be acceptable to Amit as well? In that case we would add a
default error handler (called a finalizer), which would also be what
I'm planning to use this for.
Other opinions?
/Per
On Tue, Feb 10, 2009 at 5:48 PM, Bob Ippolito b...@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
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: Defered.setFinal
Even better...
if (this.chain.length == 0 this._finalizer) {
this._finalized = this._finalizer(res);
}
This will allow us to finalize the deferred based on some
conditions...
- Amit
On Feb 11, 12:52 am, Per Cederberg cederb...@gmail.com wrote:
You mean like this?
setFinalizer: function(cb) {
this._finalizer = cb;
}
...
if (this.chain.length == 0 this._finalizer) {
this.finalized = true;
if (res instanceof Error) {
this._finalizer(res);
}
}
Would that be acceptable to Amit as well? In that case we would add a
default error handler (called a finalizer), which would also be what
I'm planning to use this for.
Other opinions?
/Per
On Tue, Feb 10, 2009 at 5:48 PM, Bob Ippolito b...@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
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] Defered.setFinal
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
-~--~~~~--~~--~--~---
Index: MochiKit/Async.js
===
--- MochiKit/Async.js (revision 1525)
+++ MochiKit/Async.js (working copy)
@@ -136,6 +136,11 @@
return this;
},
+setFinal: function(cb) {
+this._final = cb;
+return this;
+},
+
_fire: function () {
/***
@@ -176,6 +181,11 @@
res = err;
}
}
+
+if (chain.length == 0 this._final) {
+res = this._final(res);
+}
+
this.fired = fired;
this.results[fired] = res;
if (cb this.paused) {
[mochikit] Re: Defered.setFinal
Per,
Your hack won't work with my case as it would mark the deferred as
`chained` so consecutive addCallback/addErrback won't work. Considering
Bob's suggestion, I modified my patch to ensure no further
callback/errbacks can be registered.
Regards
--
Amit
Bob Ippolito 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
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
-~--~~~~--~~--~--~---
Index: MochiKit/Async.js
===
--- MochiKit/Async.js (revision 1525)
+++ MochiKit/Async.js (working copy)
@@ -20,6 +20,7 @@
this.canceller = canceller;
this.silentlyCancelled = false;
this.chained = false;
+this.finalized = false;
};
MochiKit.Async.Deferred.prototype = {
@@ -129,6 +130,9 @@
if (this.chained) {
throw new Error(Chained Deferreds can not be re-used);
}
+if (this.finalized) {
+throw new Error(Finalized Deferreds can not be re-used);
+}
this.chain.push([cb, eb]);
if (this.fired = 0) {
this._fire();
@@ -136,6 +140,11 @@
return this;
},
+setFinal: function(cb) {
+this._final = cb;
+return this;
+},
+
_fire: function () {
/***
@@ -184,6 +193,10 @@
res.addBoth(cb);
res.chained = true;
}
+if (this.chain.length == 0 this._final) {
+this.finalized = true;
+this._final();
+}
}
};
[mochikit] Re: Curry and uncurry
I think, for functional programming, we should keep things simple.
It's better to keep code simple and readable. Can you explain few more
use cases of the proposed functions?
Regards
--
Amit
On Dec 17, 9: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: Introducing the MochiKit.Text module
It's very good addition :) especially the new formating functions. I'll improve my MochiKit.String module so that one can create String instance with the new formating patterns. Again, I'm too, agree with Arner. Try to follow Python conventions as much as possible. startsWith = startswith endsWith = endswith and so on... See `MochiKit.String.splitlines`, you can remove `splitJoin` as you one can easily do the same with `splitlines` (if it's all about triming newline chars). Regards -- Amit On Dec 17, 5:23 pm, Per Cederberg cederb...@gmail.com wrote: Hi everyone, I've just finished committing one of my planned additions to MochiKit 1.5 -- a new MochiKit.Text module: http://www.mochikit.com/doc/html/MochiKit/Text.html It basically provides some of the text formatting stuff discussed here on the list previously. With some random string utility functions added on top. I chose the name Text instead of String or Format for various reasons, but in the end I guess it is just a matter of taste. Also, it avoids collisions with the MochiKit.String name already in use by Amit. My plans for MochiKit.Text are as follows: 1. Collect more ideas and feedback (hence this email). 2. Migrate camelize, strip, lstrip, rstrip, truncToFixed, roundToFixed and locale handling over to MochiKit.Text. Perhaps the remaining parts of MochiKit.Format should be deprecated? 3. Implement some additional stuff like toTitleCase, isDigit, isAlphaNumeric, etc. Please let me know what you think. 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 mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Weird bug in MochiKit.Style.getElementPosition
What does this line really intended for?
relativeTo = arguments.callee(relativeTo);
I have removed this line and that error was gone...
- Amit
On Dec 12, 8:08 pm, Per Cederberg cederb...@gmail.com wrote:
Hi,
I ran across a weird bug in MochiKit.Style.getElementPosition causing
FF to throw evil C++ exceptions into the console:
http://trac.mochikit.com/ticket/332
Debugging the MochiKit code I ended up looking at the following piece
of black magic:
getElementPosition: function (elem, /* optional */relativeTo) {
var self = MochiKit.Style;
var dom = MochiKit.DOM;
elem = dom.getElement(elem);
if (!elem ||
(!(elem.x elem.y)
(!elem.parentNode === null ||
self.getStyle(elem, 'display') == 'none'))) {
return undefined;
}
Question: What does the if-statement really do? And what was the real
intention?
It seems the getStyle() function is called even though I send in a {
x: 0, y: 0 } object. I guess that is not the real intention.
Especially I like the !elem.parentNode === null check. What does
that even mean??? Weird that the previous test cases haven't caught
anything here...
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: connectEach shortcut
Look at the MochiKit.Query module of the MochiKit Extensions (http://
launchpad.net/mochikit-ext).
It provides jQuery style signal functions...
MochiKit.Query('#my-ul li').click(function(evt){
// handle events here
});
or
MochiKit.Query('#my-ul li').click(some_callback);
then you can signal to matched elements by simply calling...
MochiKit.Query('#my-ul li').click();
Regards
--
Amit
On Dec 12, 9:45 pm, Eoghan eoghanomur...@gmail.com wrote:
I often use the following utility function:
function connectEach(iterable, signal, dest, func){
forEach(iterable, function(el){
connect(el, signal, dest, func);
});
}
It might be used as follows:
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?
Eoghan
--~--~-~--~~~---~--~~
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: Suggested API:s for MochiKit 1.5
Little bit late to this discussion, but I am happy to see discussion about `Mochichit Extensions` here. I too don't like mixing up two different JS libraries while my preferred library (MK) is capable enough to do what the others can. I like the jQuery very much for it's powerful DOM manipulation and traversing functions but it's not good enough for other generic usages. That's why, I have started making something similar to jQuery for MochiKit. If you compare both, you would found that MochiKit.Query tries to implement most of the DOM traversing iterating functions using MochiKit whenever possible and contains little code from jQuery where it can't (that's why, I have released ME under the GPL/MIT licences. Though, personally I always prefer FSF approved licenses). Regards -- Amit Mendapara On Oct 27, 2:49 pm, Per Cederberg [EMAIL PROTECTED] wrote: Hi everyone, Development of MochiKit 1.5 is about to start. But before we open the flood-gates, it might be useful to have a look at a summary of all proposed API:s. Below you'll find a comprehensive list of all API additions that I've found (so far). # Note 1. I've included everything, regardless of whether the author/originator actually suggested them for inclusion into MochiKit or not. # Note 2. In some cases the source code exists and has been tested. Not so in others. # Note 3. Some of these API suggestions might be duplicates of something already in MochiKit. Or are perhaps better implemented as improvements to existing functions. Some of them might just be common usage patterns that either deserve proper documentation or perhaps an alias function. So, in summary, please don't get too agitated about individual entries on the list below. Nothing is set in stone and I'm only looking to collect statistics, ideas, clarified names, generalizations, random thoughts and such. See this as my attempt to collect your thoughts and votes about what you want from MochiKit in the future. I'm holding off a bit on my own analysis. Will post my comments on individual suggestions later on. Cheers, /Per Source Notations: [trac] Enhancement suggestions in MochiKit Trac, usually without a proposed implementation. http://trac.mochikit.com/report/3 [me] Patches from the MochiKit Extensions project on LaunchPad https://launchpad.net/mochikit-ext [mp] Patches from the mochikit-patches project on GitHub. http://github.com/cederberg/mochikit-patches/tree/master [other] Random thoughts found elsewhere (don't know where) MochiKit.Base o rbind -- [trac] binds a function, but adds new args before bound ones o rpartial -- [trac] binds a function, but adds new args before bound ones o extendURL -- [trac] merges name and values into a URL query string o isFalse -- [mp] check for false, with wide interpretation o defaultValue -- [mp] returns first non-undefined value o dict -- [mp] merges keys and values to dictionary object o select -- [mp] copies listed keys (and values) from an object o mask -- [mp] removes listed keys (and values) from an object o functionName -- [mp] returns the name of a function o registerFunctionNames -- [mp] registers function names - should probably be merged into nameFunctions o stackTrace -- [mp] returns current execution stack trace o injectStackTrace -- [mp] injects stack trace for a function o version -- [other] returns an object for browser detection such MochiKit.Async o postSimpleXMLHttpRequest -- [trac] uses POST for a simple request o postJSONDoc -- [trac] same as above and also eval:s response data o sendJSONPrequest -- [trac] similar to the above, but different API o loadScript -- [trac] loads a JavaScript file MochiKit.DateTime o MILLIS_PER_SECOND -- [mp] constant millisecond value o MILLIS_PER_MINUTE -- [mp] constant millisecond value o MILLIS_PER_HOUR -- [mp] constant millisecond value o MILLIS_PER_DAY -- [mp] constant millisecond value o MILLIS_PER_WEEK -- [mp] constant millisecond value o TimePeriod -- [mp] creates a new time period object (with days, hours, minutes, seconds millis) o toApproxPeriod -- [mp] converts millis to an approximate time period MochiKit.DOM: o NBSP -- [trac] creates a non-breaking space node o unescapeHTML -- [trac] creates a DOM tree from an HTML string o selectRange -- [trac] selects text in a text box or field o NS.XHTML -- [mp] namespace constant o NS.XLINK -- [mp] namespace constant o NS.SVG -- [mp] namespace constant o NS.XUL -- [mp] namespace constant o NS.HTML -- [mp] namespace constant o isDOM -- [mp] checks if an object looks like a DOM node o isHTML -- [mp] checks if an object looks like an HTML or XHTML DOM node o reprDOM -- [mp] creates debug representation of a DOM node o attributeArray -- [mp] make existing impl. public o childNode -- [mp] returns an immediate child node o createDOMExt -- [mp] creates a DOM node
[mochikit] Re: Suggested API:s for MochiKit 1.5
o unescapeHTML -- [trac] creates a DOM tree from an HTML string We need a clearer name, perhaps toDOM (being the inverse of toHTML)? I think, a helper function `makeDOM` in `MochiKit.Query` module would serve as a base for such implementation. I have taken ideas from jQuery... MochiKit.Ajax -- new module in [me], names not exported (so no collisions) o bind -- [me] connects a signal for HTTP responses o unbind -- [me] disconnects a signal for HTTP responses o request -- [me] sends an HTTP request o get -- [me] sends an HTTP GET request o post -- [me] sends an HTTP POST request We should simplify Async a bit further when using POST requests. And it would be nice to be able to wrap Deferred objects into plain signals. But perhaps we don't need a new module for that? I think no, if we can rename those signal names (ajaxStart etc) accordingly... MochiKit.Query -- new module in [me] -- I won't document this module here, but it seems (mostly?) API compatible with jQuery. It uses MochiKit to implement (part of) that API. I find this idea intriguing. I know some people don't like to mix two libraries on their web sites. So the idea of having some API-compability layer for jQuery and others seem attractive. On the other hand, we'd get into a nightmare of compability issues. And would quite possibly have to reproduce code from other libraries. To little gain in download size, I guess. I don't think that we'd have any compatibility issues. If you compare them both, you might found that MochiKit.Query tries to imitate jQuery using MochiKit functions as much as possible and there are room to remove those jQuery code from the current implementation. Regards -- Amit Mendapara --~--~-~--~~~---~--~~ 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
Hello Per, Several files in the downloadable zip package have permission issues (on Linux). Please make sure that it's packaged properly with correct access permissions. - Amit Mendapara On Oct 21, 3:32 pm, Per Cederberg [EMAIL PROTECTED] wrote: 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 --~--~-~--~~~---~--~~ 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
Congrats and many thanks to all who made it possible. I'm sure we could reveal even better next time. Thanks Per... - Amit Mendapara On Oct 21, 3:32 pm, Per Cederberg [EMAIL PROTECTED] wrote: 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 --~--~-~--~~~---~--~~ 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
Whatever you prefer Bob. But users who want to contribute by means of codding, reporting/fixing bugs, suggesting new ideas or anything should never been restricted anyway because of those few spammers... - Amit Mendapara On Oct 13, 8:19 pm, Bob Ippolito [EMAIL PROTECTED] wrote: 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. Seehttp://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] Re: Selector speedup by using John Resig's Sizzle
I have seen many problems with MochiKit.Selector while testing MochiKit.Query module. As `Per Cederberg` is preparing for 1.4 release, I think MochiKit.Selector should not be included in 1.4, but let we get something really useful with Sizzle which is going to be integrated in MochiKit (hopefully MochiKit 1.5)... - Amit Mendapara --~--~-~--~~~---~--~~ 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 Oct 13, 5:52 pm, Per Cederberg [EMAIL PROTECTED] wrote: I'd appreciate bug reports for the MochiKit.Selector module in Trac or here on the list. I've got 1-2 previously here in this thread that I intend to have a look at soon. 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. Anyway, I will prepare one on MochiKit.Selector this night and will post here in this thread instead... - Amit Mendapara --~--~-~--~~~---~--~~ 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
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] Re: Selector speedup by using John Resig's Sizzle
On Oct 7, 1:49 pm, Arnar Birgisson [EMAIL PROTECTED] wrote: To be clear, I'm basically asking the mailing list: Would you be OK with it if the following selectors would stop working? a[fakeattribute] - i.e. checking for presence of attribute p[lang|=en] - membership test of hyphen-seperated string collections :nth-of-type(...) pseudo-class :enabled, :disabled and :checked pseudo-classes :root pseudo-class My votes... Drop these (not in jQuery, so may be not supported by Sizzle): 1) p[lang|=en] 2) :nth-of-type(...) Rename this: 1) :root to :first Should be there: 1) a[fakeattribute] 2) :enabled 3) :disabled 4) :checked 5) ... more form selectors (see jQuery doc) Regards -- Amit Mendapara --~--~-~--~~~---~--~~ 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 Extensions
Hello Everyone, I have just published the initial source of MochiKit Extensions at Launchpad.net (https://launchpad.net/mochikit-ext). At the moment it only contains the MochiKit.Query module. To obtain the source, you require Bazaar vcs tools from (http://bazaar-vcs.org). bzr branch lp:mochikit-ext Regards -- Amit Mendapara --~--~-~--~~~---~--~~ 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: Ajax Dom Replacement
As your Ajax result is a TD, innerHTML wont work if you don't create
whole TABLE with TBODY. You should do this:
var old = $('thisisatd');
var tr = TR(null);
var tbl = TABLE(null, TBODY(null, tr));
tr.innerHTML = 'td id=thisisatd colspan=3A new text/td';
swapDOM(old, tr.firstChild);
For your information, I'm implementing a jQuery style helper module
(see previous post) that will easy such tasks, for example:
MochiKit.Query('#thisisatd').replaceWith('td id=thisisatd
colspan=3A new text/td');
The MochiKit.Query will take care of creating valid DOM from the given
row html text and also executes JavaScript within the text if any.
Though almost finished, the module is still not made public. I'm
reviewing some of the code and will release the code within a week or
so...
Regards
..
Amit Mendapara
On Sep 8, 4:43 pm, gregor [EMAIL PROTECTED] wrote:
I would like to change a DOM Object with a turbogears ajax call.
At the moment the ajax call returns a string with the html of the node
that should be replaced. How can I swap the existing DOM Object with
the new one I got from the ajax callback?
InnerHTML replaces the inner part of the element, but I want to
replace the whole thing. OuterHtml seems to what I need but it does
not work in Firefox. swapDOM takes two DOM-Objects, but I've only got
a string for the replacement. How can I convert a string to a DOM
object?
Pseudo example:
html
table
trtd id=thisisatd colspan=2A text/td/tr
/table
/html
From the Ajax call I get the string back td id=thisisatd
colspan=3A new text/td/tr.
How can I replace the td with this new string?
My current function to do this looks like this:
var doReplace = function (req) {
for (var e in req.changes) {
var element = document.getElementById(e)
if (element) {
element.outerHTML = req.changes[e]; // - Does not work in
Firefox
}
else {
alert(element not found: + e);
}
}
}
--~--~-~--~~~---~--~~
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: Ajax Dom Replacement
Yes, exactly. In that case:
var old = $('thisisatd');
var tr = TR(null);
var tbl = TABLE(null, TBODY(null, tr));
tr.innerHTML = 'td id=thisisatd colspan=3A new text/tdtd
id=thisisanothertd colspan=3A new text/td';
forEach(tr.childNodes, function(td){
old.parentNode.insertBefore(td, old);
});
removeElement(old);
Regards
..
Amit Mendapara
On Sep 8, 5:52 pm, Arnar Birgisson [EMAIL PROTECTED] wrote:
Hey there,
On Mon, Sep 8, 2008 at 13:43, gregor [EMAIL PROTECTED] wrote:
I would like to change a DOM Object with a turbogears ajax call.
At the moment the ajax call returns a string with the html of the node
that should be replaced. How can I swap the existing DOM Object with
the new one I got from the ajax callback?
InnerHTML replaces the inner part of the element, but I want to
replace the whole thing. OuterHtml seems to what I need but it does
not work in Firefox. swapDOM takes two DOM-Objects, but I've only got
a string for the replacement. How can I convert a string to a DOM
object?
First of all, not that in general a string can represent a HTML
fragment containing more than one element. Consider:
tdnumber1/tdtdnumber2/td
My point is that you cannot take any string and convert it to just one
DOM element. However, say your strings always contain one complete
element, or that you just want to pick out the first one, you can
create a temporary element (not injected in the document) to use
innerHTML on, and the use swapDOM to inject the first child. I.e.
(note, this is untested code written directly in the email):
var str = tdsomething from an ajax call/td;
var container = DIV();
container.innerHTML = str;
swapDOM(id-of-element-to-remove, container.firstChild);
Actually, if you did want *all* elements from the fragment, you could
to this I guess:
var str = tdsomething from an ajax call/td;
var container = DIV();
container.innerHTML = str;
insertSiblingNodesAfter(id-of-element-to-remove, container.childNodes);
removeElement(id-of-element-to-remove);
However, you should note that with the proper content-type for the
ajax response and depending on your specific use, you might already
have a ready-made DOM object in the XMLHttpRequest object under the
property responseXML
cheers,
Arnar
Pseudo example:
html
table
trtd id=thisisatd colspan=2A text/td/tr
/table
/html
From the Ajax call I get the string back td id=thisisatd
colspan=3A new text/td/tr.
How can I replace the td with this new string?
My current function to do this looks like this:
var doReplace = function (req) {
for (var e in req.changes) {
var element = document.getElementById(e)
if (element) {
element.outerHTML = req.changes[e]; // - Does not work in
Firefox
}
else {
alert(element not found: + e);
}
}
}
--~--~-~--~~~---~--~~
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: Ajax Dom Replacement
On Sep 8, 6:48 pm, Per Cederberg [EMAIL PROTECTED] wrote: I guess it is just a matter of taste, but I'd use MochiKit.DOM.replaceChildNodes instead of multiple insert and remove calls. Yes, me too if I have to replace all children ;) Regards .. Amit Mendapara --~--~-~--~~~---~--~~ 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 Extensions
Well, the MochiKit.Query module is almost finished. Actually, it only
provides DOM related functions. I too don't like chained API for
general development, but I think it's much more natural for DOM
related operations.
Here are what it provides (see jQuery documentation ;) )
Core functions:
- length
- size()
- get(index)
- index(nodeObj)
Iter/Traversing functions:
- each(callback[, self])
- map(callback[, self])
- filter(callback[, self])
- is(expr)
- not(expr)
- eq(expr)
- slice(start[, end])
- children([expr])
- contents([expr])
- find(expr)
- next([expr])
- nextAll([expr])
- prev([expr])
- prevAll([expr])
- siblings([expr])
- andSelf()
- end()
DOM Style functions:
- attr([value])
- removeAttr(name)
- addClass(name)
- hasClass(name)
- removeClass(name)
- toggleClass(name)
- html([value])
- text([value])
- val([value])
- css(name[, value])
- position([options])
- offset()
- height()
- width()
- outerHeight()
- outerWidth()
- append(...)
- appendTo(...)
- prepend(...)
- prenendTo(...)
- after(...)
- insertAfter(...)
- before(...)
- insertBefore(...)
- wrap(content)
- wrapAll(content)
- wrapInner(content)
- replaceWith(content)
- replaceAll(content)
- empty()
- remove([expr])
- clone([events])
Event binding:
- bind(type, callback[, self])
- unbind(type[, callback, self])
- trigger(type[, event])
+ shortcut functions to common DOM events like `click, mouseover
etc`
Effect functions:
- animate(how[, options])
- hide(how[, options])
- show(how[, options])
- hover(fnOver, fnOut)
- hoverClass(name)
+ shortcut functions to all MochiKit.Visual effects
* jQuery calls the callback in the context of current element while
MochiKit.Query invokes the callback in it's original context. So the
callback signature are different then jQuery. Also, the effect
functions are totally different then jQuery, uses MochiKit.Visual
effects.
jQuery('div').each(function(i, elem){
// this refers to the current dom element
});
MochiKit.Query('div').each(function(elem, i) {
// this refers to the callback function or object to which it's
bound
});
jQuery('div').click(function(evt){
// this refers to the current dom element
});
MochiKit.Query('div').click(function(evt){
// this refers to the callback function or object to which it's
bound
});
The proposed MochiKit.Remote will provide much more clear API and will
allow much better control on the requests.
1. MochiKit.Remote.request(options)
options.url - the url
options.data - the request params
options.type = GET or POST
options.contentType - the datatype of request contents
options.async = default true, false for sync request
options.queue = queue management options for async requests
2. MochiKit.Remote.get(url[, data, options])
3. MochiKit.Remote.post(url[, data, options])
4. MochiKit.Remote.JSON.get(url[, data, options])
5. MochiKit.Remote.JSON.post(url[, data, options])
All these functions are similar to MochiKit.Async functions and
returns MochiKit.Async.Deferred.
Regards
..
Amit Mendapara
--~--~-~--~~~---~--~~
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] MochiKit Extensions
Hello Everyone,
As said before, I'm working on some extension modules for MochiKit.
Those are..
1) MochiKit.Query - provides jQuery style DOM manipulation/traversing
functionality
2) MochiKit.Remote - an implementation of MochiKit.Async
3) MochiKit.Extensions - extension helpers
The Query module is based on MochiKit.Selector so selector features
are limited then the jQuery. The Query module provides almost
identical API to jQuery but using MochiKit. Yes, there are few
differences also including callback function invocation, event
handling, effects and some iteration functions.
The MochiKit.Remote module is still under consideration but it will
provide much better control over the requests, including...
1) Async/Sync requests
2) JavaScript evaluation JSON
3) Queue of Requests
5) Global Notifications
The MochiKit.Extensions module provides some helper functions to
register new Extension modules or classes, taking care of dependencies
and existing names...
MochiKit.Extensions.registerModule('MochiKit.MyModule', {version: 1.4,
depends: ['Base', 'Iter']});
Which is similar to MochiKit.Base._deps
MochiKit.Extensions.registerClass('MochiKit.MyClass', {version: 1.4,
depends: ['Base', 'Iter']});
It will register Class (object) under the MochiKit namespace.
MochiKit.MyClass = function(...) {
...
}
IMHO registering classes to MochiKit namespace will make it truly
Pythonic ;)
Though, the MochiKit.Query and MochiKit.Extensions modules are almost
finished, I haven't released the code yet due to some licensing
issues. It contains some GPL code and portions from jQuery. So I'm
thinking of releasing the code under MIT + GPL licenses, and thus may
not get merged with the official MochiKit library but will remain as
separate project.
Any suggestions are welcome...
Regards
..
Amit Mendapara
--~--~-~--~~~---~--~~
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
What I mean is not to alter any of the native Javascript objects but
creating a new helper object. The proposed object will only support
DOM manipulation/traversal. I like the MochiKit style API for other
common tasks.
I'm working on this during my spare time. It's named
MochiKit.Query ;). Currently it's based on MochiKit.Selector but I'm
thinking of implementing new more powerful selector (probably based on
jQuery or Sizzle). I'm also thinking on reimplementing MochiKit.Async
module which might be named MochiKit.Remote (will allow async/sync
requests). As I am working during my spare time don't expect it to
happen in very near future, but within couple of months. Once in a
good state, I will open the sources at code.google.com or
launchpad.net.
What the MochiKit.Query contains...
1. MochiKit.Query.Query - the helper class that provides jQuery style
DOM manipulation/traversal functionality
2. MochiKit.Query.select - a function that returns instance or Query
3. MochiKit.select = MochiKit.Query.select
Regards
..
Amit Mendapara
On Aug 27, 3:39 pm, Per Cederberg [EMAIL PROTECTED] wrote:
Ok, I think I understand how you mean. Don't think it is a bad idea,
but it is partially breaking with the current MochiKit API style where
plain unmodified DOM objects are always returned.
The call chaining style would depend on using mix-ins, i.e. adding a
sef of function pointers to all returned DOM objects. No doubt this is
very useful, but there are perhaps drawbacks such as performance or
similar. I'm using this technique pretty extensively myself when
creating widgets from DOM objects.
Cheers,
/Per
On Thu, Aug 21, 2008 at 8:37 AM, Amit Mendapara
[EMAIL PROTECTED] wrote:
On Aug 21, 11:08 am, Per Cederberg [EMAIL PROTECTED] wrote:
Could you provide a simple example on how this MochiKit.DOMSelector
class is supposed to be used. Compared to the current way to do
things.
pre
// hide all DIV elements with CLASS hideme
MochiKit.get('div.hideme').fade({from: 1.0, to: 0.0});
// add CLASS showme to all other DIV elements then CLASS hideme
MochiKit.get('div').filter(':not(.hideme)').addClass('showme');
// show all DIV elements with CLASS showme
MochiKit.get('div').filter('.showme').appear({from: 0.0, to: 1.0});
// the above two can be chained like this
MochiKit.get('div').filter(':not(.hideme)').addClass('showme').appear({from:
0.0, to: 1.0});
/pre
I agree that there is some utility to mixing in additional functions
into DOM objects, like for instance Prototype does. But I'm not so
sure that it should be done by default in MochiKit.
No, I don't favor altering of the native JavaScript objects including
DOM objects.
The proposed DOMSelector class should use `MochiKit.Selector`
functions to
extend the library with features like JQuery.
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: Random Ideas for Mochikit.DOM
Yes, it seems promising. If this is going to be happen, I will continue on other things... Regards -- Amit Mendapara On Aug 27, 8:18 pm, Arnar Birgisson [EMAIL PROTECTED] wrote: On Wed, Aug 27, 2008 at 14:28, Amit Mendapara [EMAIL PROTECTED] wrote: I'm working on this during my spare time. It's named MochiKit.Query ;). Currently it's based on MochiKit.Selector but I'm thinking of implementing new more powerful selector (probably based on jQuery or Sizzle). You should note that I proposed that MochiKit.Selector will become simply a wrapper around Sizzle, when Sizzle is released. So far no one has objected.. See the discussion here:http://groups.google.com/group/mochikit/browse_thread/thread/ac3f576c... 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: Random Ideas for Mochikit.DOM
On Aug 27, 8:44 pm, Per Cederberg [EMAIL PROTECTED] wrote:
Ah, ok I see.
I think there is definitely a place for these kind of extensions to
MochiKit. But in order to enable the growth of whole new modules, we
must make it much easier for users of the library to package their own
customized versions by selecting only what they want. See for example
how ExtJs allows the users to download customized versions.
I don't see any difficulties to add new extension packages to
MochiKit. We can easily to that even if we keep our extension modules
separate from the MochiKit itself (which is going to be happen with my
extension modules due to licensing issues). Just what we need is
update the python scripts accordingly if required (though I haven't
looked at them yet).
You could also try hosting at github.com if you feel adventurous
enough to give Git a try. I'm using it myself for a PlotKit patchset
and it enables others to clone my repo very easily (once they learn
how to use Git of course :-)
I am using Launchpad.net which provides Bazzar vcs, which is similar
to git.
Regards
--
Amit Mendapara
Cheers,
/Per
On Wed, Aug 27, 2008 at 4:28 PM, Amit Mendapara
[EMAIL PROTECTED] wrote:
What I mean is not to alter any of the native Javascript objects but
creating a new helper object. The proposed object will only support
DOM manipulation/traversal. I like the MochiKit style API for other
common tasks.
I'm working on this during my spare time. It's named
MochiKit.Query ;). Currently it's based on MochiKit.Selector but I'm
thinking of implementing new more powerful selector (probably based on
jQuery or Sizzle). I'm also thinking on reimplementing MochiKit.Async
module which might be named MochiKit.Remote (will allow async/sync
requests). As I am working during my spare time don't expect it to
happen in very near future, but within couple of months. Once in a
good state, I will open the sources at code.google.com or
launchpad.net.
What the MochiKit.Query contains...
1. MochiKit.Query.Query - the helper class that provides jQuery style
DOM manipulation/traversal functionality
2. MochiKit.Query.select - a function that returns instance or Query
3. MochiKit.select = MochiKit.Query.select
Regards
..
Amit Mendapara
On Aug 27, 3:39 pm, Per Cederberg [EMAIL PROTECTED] wrote:
Ok, I think I understand how you mean. Don't think it is a bad idea,
but it is partially breaking with the current MochiKit API style where
plain unmodified DOM objects are always returned.
The call chaining style would depend on using mix-ins, i.e. adding a
sef of function pointers to all returned DOM objects. No doubt this is
very useful, but there are perhaps drawbacks such as performance or
similar. I'm using this technique pretty extensively myself when
creating widgets from DOM objects.
Cheers,
/Per
On Thu, Aug 21, 2008 at 8:37 AM, Amit Mendapara
[EMAIL PROTECTED] wrote:
On Aug 21, 11:08 am, Per Cederberg [EMAIL PROTECTED] wrote:
Could you provide a simple example on how this MochiKit.DOMSelector
class is supposed to be used. Compared to the current way to do
things.
pre
// hide all DIV elements with CLASS hideme
MochiKit.get('div.hideme').fade({from: 1.0, to: 0.0});
// add CLASS showme to all other DIV elements then CLASS hideme
MochiKit.get('div').filter(':not(.hideme)').addClass('showme');
// show all DIV elements with CLASS showme
MochiKit.get('div').filter('.showme').appear({from: 0.0, to: 1.0});
// the above two can be chained like this
MochiKit.get('div').filter(':not(.hideme)').addClass('showme').appear({from:
0.0, to: 1.0});
/pre
I agree that there is some utility to mixing in additional functions
into DOM objects, like for instance Prototype does. But I'm not so
sure that it should be done by default in MochiKit.
No, I don't favor altering of the native JavaScript objects including
DOM objects.
The proposed DOMSelector class should use `MochiKit.Selector`
functions to
extend the library with features like JQuery.
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: Random Ideas for Mochikit.DOM
On Aug 27, 11:25 pm, machineghost [EMAIL PROTECTED] wrote: Arnar, I apologize; I confused you with Amit (in my defense, you both have unusual names starting with A and both of you were interested in adding JQuery like functionality to MochiKit). I warned him that trying to add JQuery-like features to MochiKit will be very difficult because of MochiKit's resistance to change (and provided a link to a thread where I proposed doing just that and got essentially told go use JQuery and stop bugging us). Therefore, I warned, he would probably find it more productive to simply switch to JQuery and migrate whatever MochiKit features he wants. If MochiKit is not going to change, I don't want to change it. And why should I switch if I can do whatever I want with what I am using right now? Bob summed it up well in his post: but it does what we want it to do MochiKit does certain things, that Bob wants it to do, very well. If you want it do other things that Bob doesn't care about, you're out of luck. Jeremy P.S. BTW, I'm not trying to knock the benevolent dictator for life model. As Guido has shown with Python, when the BDL makes it very clear what the project's goals are, what the criteria for/standards of contribution are, and engages with the development community in a constructive fashion, it can be an incredibly productive system. On Aug 27, 9:55 am, Arnar Birgisson [EMAIL PROTECTED] wrote: Hi Jeremy, On Wed, Aug 27, 2008 at 16:46, machineghost [EMAIL PROTECTED] wrote: I'll be brief, as Arnar seems intent on his plans despite my warnings. Sorry, what warnings? Are you referring to using Sizzle in the Selector module? I must have missed something :/ and I can't find it in you past messages. 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: Selector speedup by using John Resig's Sizzle
Sorry, I am bit late to this discussion. It seems promising. As I said in another post, I am implementing jQuery style Query module which is currently using MochiKit.Selector (the code is not made public yet). As my proposed module is totally new, I'm not afraid of backward compatibility. That's why I have decided to implement new selector for the Query module. Though if MochiKit.Selector is going to be Sizzle based, it would be great... 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? Regards .. Amit Mendapara On Aug 25, 9:06 pm, Arnar Birgisson [EMAIL PROTECTED] wrote: Hey all, Some of you may have seen on reddit that John Resig (of jQuery) is working on a new, ultra-fast, css selector module. It is called Sizzle and although it is not released yet, John uploaded a version to github:http://github.com/jeresig/sizzle/tree/master MochiKit's Selector module (which is ported from early versions of Prototype) is unbearably slow, and thus many people steer clear of it. I asked John about the possibility of including Sizzle in MochiKit and he's ok with that, Sizzle will be released under the MIT license. I did a quick test, just deleted most of the Selector module and replaced with John's code, and modified the exported functions of the Selector module to use that instead. The MochiKit.Selector.Selector object has to go though, so this would not be an entirely backwards-compatible change. The functions findChildElements, findDocElements and $$ would be unchanged though. You can check out the speed test (included with Sizzle) where I've added both the trunk version of MochiKit and the MochiKit+Sizzle fusion here:http://www.hvergi.net/arnar/public/sizzle/speed/# For this benchmark, regular MochiKit completed all tests in 3983 milliseconds. The MochiKit+Sizzle combination does it in 61. That means we are talking about a speedup by a factor of roughly 65! It doesn't come without faults though. Sizzle didn't support all queries in MochiKit's unit tests, namely these are the ones that fail (I'm cc-ing John in case he wants to add support for any of them): a[fakeattribute] - i.e. checking for presence of attribute p[lang|=en] - membership test of hyphen-seperated string collections :nth-of-type(...) pseudo-class :enabled, :disabled and :checked pseudo-classes :root pseudo-class This change would increase the size of the packed version by about 1700 bytes (currently at 173.5 KB). Now, how do people feel about committing a change like this to the trunk? Of course, we'd wait until a fairly stable version of Sizzle is released. John told us that Sizzle will become the main selector engine behind jQuery, but will also remain a standalone component. All bugfixes will be backported to Sizzle also. As long as MochiKit keeps up, this means we'd benefit from the bugs reported by the jQuery community. A rough test, just plomping in the Sizzle source code into Selector.js is available on my website:http://www.hvergi.net/arnar/public/mochikit/MochiKit/Selector.js 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: Random Ideas for Mochikit.DOM
On Aug 21, 11:08 am, Per Cederberg [EMAIL PROTECTED] wrote:
Could you provide a simple example on how this MochiKit.DOMSelector
class is supposed to be used. Compared to the current way to do
things.
pre
// hide all DIV elements with CLASS hideme
MochiKit.get('div.hideme').fade({from: 1.0, to: 0.0});
// add CLASS showme to all other DIV elements then CLASS hideme
MochiKit.get('div').filter(':not(.hideme)').addClass('showme');
// show all DIV elements with CLASS showme
MochiKit.get('div').filter('.showme').appear({from: 0.0, to: 1.0});
// the above two can be chained like this
MochiKit.get('div').filter(':not(.hideme)').addClass('showme').appear({from:
0.0, to: 1.0});
/pre
I agree that there is some utility to mixing in additional functions
into DOM objects, like for instance Prototype does. But I'm not so
sure that it should be done by default in MochiKit.
No, I don't favor altering of the native JavaScript objects including
DOM objects.
The proposed DOMSelector class should use `MochiKit.Selector`
functions to
extend the library with features like JQuery.
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: Random Ideas for Mochikit.DOM
I don't understand why MochiKit team says somewhere (http://
trac.mochikit.com/wiki/StyleGuide) not to use aliases and short names
while enabling them by default. I personally don't like short names
and particularly the aliases `$` and `$$`. In my opinion, only fully
qualified names should be available on default inclusion of MochiKit.
If someone wants aliases and globally exported name, that should be
configurable.
Another interesting thing developers should bring to the MochiKit is
JQuery style chaining of calls on a special DOM like object. I did
some work but only MochiKit core developers can do better...
MochiKit.DOMSelector = function(query, context) {
...
}
MochiKit.DOMSelector.prototype = {
__init__ : function(query, context) {
...
},
// Iter methods
forEach : function(callback) {
return this;
}
filter : function(callback) {
...
return this;
},
map : function(callback) {
...
return this;
},
...
// DOM methods
addClass : function(className){
...
return this;
},
removeClass : function(className){
...
return this;
},
attr: function(name){
...
return this;
},
...
// Access methods
index : function() {},
size : function(){},
get : function(num) {
// return an array of all matched DOM elements
if (num) {
return this.elements[num];
}
return this.elements
},
// And lots more...
}
and of course one handy function with short name ;) to get the
DOMSelector...
MochiKit.get = function(query, context) {
return new MochiKit.DOMSelector(query, context);
}
What you think?
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
