Random Ideas for Mochikit.DOM

[machineghost]

Hey All,

I use a couple of "alias" functions in every project where I use the
DOM library:

/*
Shorten getElementsByTagAndClassName, because we know that we're
getting elements (nothing else has a tag/class) and we know we're
doing it by the "name" of the class or tag, because there is no other
way to identify a tag or class (pretty much all they are is a name).
*/
var getByTagAndClass = getElementsByTagAndClassName;

/*
I use getElementsByTagAndClassName(null, "someClass") all the time,
and it seemed silly to have to repeat a longer function name and a
"null, " every time.
*/
var getByClass = partial(getByTagAndClass, null);

Any chance of either of these making it in to Mochikit proper? BTW,
even if the first one was implemented, I'd still think we should keep
it as an alias (rather than changing getElementsByTagAndClassName) to
avoid breaking old code. Also, if the maintainers' really like long
function names for some odd reason, the second one could just as
easily be implemented as "getElementsByClassName" and still provide
the same usefulness.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[machineghost]

Just noticed a few more aliases I had somewhere else (which are along
the exact same lines):

var firstByTagAndClass = getFirstElementByTagAndClassName;
var addClass = addElementClass;
var removeClass = removeElementClass;

I guess what I'm asking for in this thread is "Am I the only one who
thinks that including 'name' and 'element' in all these functions'
names makes them needlessly long? If not, how about we make some
aliases?" Well, except with "getByClass"/"getElementsByClassName";
that I think would be useful even if everyone DOES like 'name' and
'element'.

Jeremy

Post by machineghost
Hey All,
I use a couple of "alias" functions in every project where I use the
/*
Shorten getElementsByTagAndClassName, because we know that we're
getting elements (nothing else has a tag/class) and we know we're
doing it by the "name" of the class or tag, because there is no other
way to identify a tag or class (pretty much all they are is a name).
*/
var getByTagAndClass = getElementsByTagAndClassName;
/*
I use getElementsByTagAndClassName(null, "someClass") all the time,
and it seemed silly to have to repeat a longer function name and a
"null, " every time.
*/
var getByClass = partial(getByTagAndClass, null);
Any chance of either of these making it in to Mochikit proper? BTW,
even if the first one was implemented, I'd still think we should keep
it as an alias (rather than changing getElementsByTagAndClassName) to
avoid breaking old code. Also, if the maintainers' really like long
function names for some odd reason, the second one could just as
easily be implemented as "getElementsByClassName" and still provide
the same usefulness.

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jason Bunting]

Personally, in both my client-side as well as server-side code, I prefer
long names that leave little room for doubt about what a variable or
method/function is meant to be or do. My server-side code is compiled, so
long names matter little, and I used the Dojo ShrinkSafe tool to bring down
the size of my JavaScript, so I get the same benefit - long names for better
reading and writing of code, and when it is time for deployment, short names
(with the exception of those functions in MochiKit, which isn't a big deal
to me).

I think using aliases is nice, but your particular pattern of using MochiKit
may not be the same as others, so I don't see a reason to change things. I
rarely use the functions you mention, so their longs names are no problem
for me.

Just my opinion, for what little it is worth.

Jason Bunting

-----Original Message-----
Behalf Of machineghost
Sent: Tuesday, August 19, 2008 10:38 AM
To: MochiKit
Subject: [mochikit] Re: Random Ideas for Mochikit.DOM
Just noticed a few more aliases I had somewhere else (which are along
var firstByTagAndClass = getFirstElementByTagAndClassName;
var addClass = addElementClass;
var removeClass = removeElementClass;
I guess what I'm asking for in this thread is "Am I the only one who
thinks that including 'name' and 'element' in all these functions'
names makes them needlessly long? If not, how about we make some
aliases?" Well, except with "getByClass"/"getElementsByClassName";
that I think would be useful even if everyone DOES like 'name' and
'element'.
Jeremy

Post by machineghost
Hey All,
I use a couple of "alias" functions in every project where I use the
/*
Shorten getElementsByTagAndClassName, because we know that we're
getting elements (nothing else has a tag/class) and we know we're
doing it by the "name" of the class or tag, because there is no other
way to identify a tag or class (pretty much all they are is a name).
*/
var getByTagAndClass = getElementsByTagAndClassName;
/*
I use getElementsByTagAndClassName(null, "someClass") all the time,
and it seemed silly to have to repeat a longer function name and a
"null, " every time.
*/
var getByClass = partial(getByTagAndClass, null);
Any chance of either of these making it in to Mochikit proper? BTW,
even if the first one was implemented, I'd still think we should keep
it as an alias (rather than changing getElementsByTagAndClassName) to
avoid breaking old code. Also, if the maintainers' really like long
function names for some odd reason, the second one could just as
easily be implemented as "getElementsByClassName" and still provide
the same usefulness.

No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.138 / Virus Database: 270.6.5/1620 - Release Date: 8/19/2008
6:04 AM

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Arnar Birgisson]

Hey all,

Post by Jason Bunting
I think using aliases is nice, but your particular pattern of using MochiKit
may not be the same as others, so I don't see a reason to change things. I
rarely use the functions you mention, so their longs names are no problem
for me.

I tend to agree. Even so, adding various aliases and shortcuts (i.e.
partial applications) to MochiKit only makes things complicated and
clutters the documentation. Functions like partial are there for a
reason, one of them being that it is super-easy for programmers to set
up their own aliases.

As for using $$('.classname'), getElementsByTagAndClassName will
probably give you better performance as the former "compiles" down to
a traverse of the DOM and applying "hasElementClass". For a long time
I've wanted to optimize the Selector module, adding caching of
expressions (to save on "compilation") and special handling of common
patterns such as just looking for class or id. Sadly, I lack the time
to invest in it and currently it won't do myself any good. :(
Furthermore, I suspect there will be support for CSS selectors in
Javascript in near-future browsers.

cheers,
Arnar

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[machineghost]

Post by Jason Bunting
Why wouldn't you just use $$(".someClass")

As Arnar said, the performance isn't the same (in fact, I've pretty
much avoided $$ altogether because of bad CSS selector performance
experiences in the past; maybe I should give it another try
though ...).

Post by Jason Bunting
I think using aliases is nice, but your particular pattern of using MochiKit
may not be the same as others

Indeed; the whole point of my post was to find out whether or not it
was; so far it sounds like I'm the only one who minds typing
getElementsByTagAndClassName (unless that changes, I completely agree
that these aliases belong in my local copy, not the framework).

But, as the saying goes, "you'll never know if you don't ask."

Jeremy

Post by Jason Bunting
Hey all,

Post by Jason Bunting
I think using aliases is nice, but your particular pattern of using MochiKit
may not be the same as others, so I don't see a reason to change things. I
rarely use the functions you mention, so their longs names are no problem
for me.

I tend to agree. Even so, adding various aliases and shortcuts (i.e.
partial applications) to MochiKit only makes things complicated and
clutters the documentation. Functions like partial are there for a
reason, one of them being that it is super-easy for programmers to set
up their own aliases.
As for using $$('.classname'), getElementsByTagAndClassName will
probably give you better performance as the former "compiles" down to
a traverse of the DOM and applying "hasElementClass". For a long time
I've wanted to optimize the Selector module, adding caching of
expressions (to save on "compilation") and special handling of common
patterns such as just looking for class or id. Sadly, I lack the time
to invest in it and currently it won't do myself any good. :(
Furthermore, I suspect there will be support for CSS selectors in
Javascript in near-future browsers.
cheers,
Arnar

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[csnyder]

On Tue, Aug 19, 2008 at 1:26 PM, Jason Bunting

Post by Jason Bunting
I think using aliases is nice, but your particular pattern of using MochiKit
may not be the same as others, so I don't see a reason to change things.

That's exactly right.

I prefer ge = getElementsByTagAndClassName; but I would never expect
to saddle other developers with such an abstract function name.

Chris Snyder
http://chxor.chxo.com/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Amit Mendapara]

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 ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Per Cederberg]

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.

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.

Cheers,

/Per

On Thu, Aug 21, 2008 at 7:46 AM, Amit Mendapara

Post by Amit Mendapara
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 ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Amit Mendapara]

Post by Per Cederberg
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>

Post by Per Cederberg
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.

Post by Per Cederberg
Cheers,
/Per

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[machineghost]

Amit, you're barking up the wrong tree ...
http://groups.google.com/group/mochikit/browse_thread/thread/2c19e8632820270e/6d18b9075c9050f9?lnk=gst

Mochikit is VERY resistant to change, and if you try to suggest
changes people will basically tell you "why don't you go use that
other library if you like their features so much."

As a side note, that line of thinking (coupled with the lack of any
real development) has convinced me that Mochikit is far too stagnant
for my company's business needs. As a result, I'm currently in the
process of researching how to migrate us to jQuery.

So, I don't mean to be yet another voice saying "give up and go use
jQuery", but in my experience that path will be MUCH more rewarding
than trying to convince the Mochikit maintainers to change ... well,
anything.

Jeremy

Post by Amit Mendapara

Post by Per Cederberg
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
0.0, to: 1.0});
</pre>

Post by Per Cederberg
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.

Post by Per Cederberg
Cheers,
/Per

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jason Bunting]

Jeremy,

Post by machineghost
Mochikit is VERY resistant to change, and if you try to suggest
changes people will basically tell you "why don't you go use that
other library if you like their features so much."

I think the fact that MochiKit is resistant to change is a Good Thing - we
can't make changes for every Tom, Dick and Harry that think it needs some
feature. As far as I can tell, part of the reason changes are looked at with
suspicion is because a lot of suggestions are not in keeping with the intent
of MochiKit.

Post by machineghost
As a side note, that line of thinking (coupled with the lack of any
real development) has convinced me that Mochikit is far too stagnant
for my company's business needs. As a result, I'm currently in the
process of researching how to migrate us to jQuery.

Is the lack of development necessarily indicative of a problem? When fruit
matures on a tree, it stops development and is picked and eaten. I think
MochiKit is mature and I have absolutely no problems with it, what things is
it missing? I rarely find things I need that MochiKit doesn't already
provide (unless, of course, you are looking for widgets and such).

Post by machineghost
So, I don't mean to be yet another voice saying "give up and go use
jQuery", but in my experience that path will be MUCH more rewarding
than trying to convince the Mochikit maintainers to change ... well,
anything.

Is this because they wouldn't add a few aliases for you? If so, that's a
poor reason to leave. I am really curious as to what you see missing -
granted, a better community of users would be nice, as far as developing
reusable widgets and such (I develop niche stuff and have to roll my own
regardless), but other than that, I don't see the library itself as missing
anything. As your last goodwill effort, provide some useful feedback.

Jason Bunting


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[machineghost]

First off, I do <3 Mochikit. I wasn't trying to bash it, I just
wanted to share my opinion of it with someone who seemed to be in a
similar position.

Post by Jason Bunting

part of the reason changes are looked at with suspicion is because
a lot of suggestions are not in keeping with the intent of MochiKit.

Suspicion is one way to describe it; I'd lean more towards "outright
hostility" (although said hostility is generally civil and polite,
which is more than I can say for a lot of lists). And as for the
intent of MochiKit, I thought it was to "make JavaScript suck less."
It does that to some degree right now, but do you really think it's
impossible for JS to suck even less? I don't (JS sucks a lot, and I
say that even though it's one of my favorite languages).

Post by Jason Bunting

Is the lack of development necessarily indicative of a problem?

Absolutely, the health of any open source project is measured by it's
activity. As a JS implementer I need to know that the (JS framework)
horse I bet on is going to respond to my future needs in a timely
fashion. I have great confidence of that with JQuery because it has
an extremely active development community; try comparing the activity
on their list:
http://groups.google.com/group/jquery-en?lnk=srg
to the activity here and you can see why I don't have similar
confidence in Mochikit. Alternatively you can compare the membership
of the groups, the # of Google results for searches on "MochiKit" vs.
"JQuery", the # of commits to either library in the last year, ...
whatever metric you use, Mochikit always comes in last compared to not
just JQuery, but every other major JS library (prototype, YUI, dojo,
etc.) as well.

Post by Jason Bunting

what things is it missing?

Well there are two just in this thread alone: chainability and
additional element methods. Another great example from JQuery is the
onDOMReadyState pseudo-event. But again, it's not just the feature by
feature comparison between frameworks that matters; five years ago I
could not have predicted the need for an XmlHttpRequest abstraction,
but that's obviously a very essential feature for a JS library today.

If my company had adopted some framework based solely on it's feature-
set back then, and that framework had never added an XmlHttpRequest
abstraction, I'd be up a proverbial creek without a paddle. I'd have
to convert all of our code to use a new library or else use two
libraries (and have a giant download footprint); either way I'd be
kicking myself for not choosing an actively developed framework.

Post by Jason Bunting

I don't see the library itself as missing anything.

There are still hundreds of opportunities to make JS suck less, but
Mochikit is missing all of them while libraries like JQuery either
respond to them directly (by adding new stuff to the library) or
indirectly (via something like JQuery's plug-in mechanism).

Post by Jason Bunting

Is this because they wouldn't add a few aliases for you?

Hardly. I personally have proposed not just that but several other
enhancements, and of course I'm not the only one who has made
suggestions, yet almost no improvements have come out of any of that
feedback.

Contrast my thread proposing an onDOMContentReady pseudo-event here
(my most popular suggestion ever) with the similar thread in the
JQuery group. Here I got "that'd be cool if you do all the work and
submit it ... but if you don't the idea will die with you" (and due to
my disenchantment with MochiKit, it did).

In contrast, that group had several different interested users who
came together, discussed the technical merits and disadvantages of
various implementations, and then ultimately added a very cool feature
their library. That never would have happened if the JQuery admin(s)
had created a culture of fear surrounding changes. There is a world
of difference between how that community responds to new ideas (even
the ones which are ultimately "shot down") and how this one
categorically denies the possibility of anything that doesn't
personally appeal to you or Per.

Of course I'm exaggerating a bit, but still the leadership of any
community sets the culture of that community, and here the culture is
"if it ain't broke don't fix it." That sort of culture is great for
stability, but it's not very conducive to improvement.

Ultimately, Mochikit is good enough for you and your company. That's
great, but I'm not going to bet my company's JS future on your
company's needs. I want a framework that takes advantage of all the
latest developments in the world of JS. I want a framework where new
ideas are welcomed and entertained, even if they are later ultimately
rejected. I want a framework that is constantly seeking to make
JavaScript suck less.

That framework isn't Mochikit.

Jeremy

Post by Jason Bunting
Jeremy,

Mochikit is VERY resistant to change, and if you try to suggest
changes people will basically tell you "why don't you go use that
other library if you like their features so much."

I think the fact that MochiKit is resistant to change is a Good Thing - we
can't make changes for every Tom, Dick and Harry that think it needs some
feature. As far as I can tell, part of the reason changes are looked at with
suspicion is because a lot of suggestions are not in keeping with the intent
of MochiKit.

As a side note, that line of thinking (coupled with the lack of any
real development) has convinced me that Mochikit is far too stagnant
for my company's business needs. As a result, I'm currently in the
process of researching how to migrate us to jQuery.

Is the lack of development necessarily indicative of a problem? When fruit
matures on a tree, it stops development and is picked and eaten. I think
MochiKit is mature and I have absolutely no problems with it, what things is
it missing? I rarely find things I need that MochiKit doesn't already
provide (unless, of course, you are looking for widgets and such).

So, I don't mean to be yet another voice saying "give up and go use
jQuery", but in my experience that path will be MUCH more rewarding
than trying to convince the Mochikit maintainers to change ... well,
anything.

Is this because they wouldn't add a few aliases for you? If so, that's a
poor reason to leave. I am really curious as to what you see missing -
granted, a better community of users would be nice, as far as developing
reusable widgets and such (I develop niche stuff and have to roll my own
regardless), but other than that, I don't see the library itself as missing
anything. As your last goodwill effort, provide some useful feedback.
Jason Bunting

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Bob Ippolito]

Post by machineghost
First off, I do <3 Mochikit. I wasn't trying to bash it, I just
wanted to share my opinion of it with someone who seemed to be in a
similar position.

part of the reason changes are looked at with suspicion is because
a lot of suggestions are not in keeping with the intent of MochiKit.

Suspicion is one way to describe it; I'd lean more towards "outright
hostility" (although said hostility is generally civil and polite,
which is more than I can say for a lot of lists). And as for the
intent of MochiKit, I thought it was to "make JavaScript suck less."
It does that to some degree right now, but do you really think it's
impossible for JS to suck even less? I don't (JS sucks a lot, and I
say that even though it's one of my favorite languages).

Yes, it's certainly possible, but it does what we want it to do... if
it didn't, you'd see a lot more commits from us.

Post by machineghost

Is the lack of development necessarily indicative of a problem?

Absolutely, the health of any open source project is measured by it's
activity. As a JS implementer I need to know that the (JS framework)
horse I bet on is going to respond to my future needs in a timely
fashion. I have great confidence of that with JQuery because it has
an extremely active development community; try comparing the activity
http://groups.google.com/group/jquery-en?lnk=srg
to the activity here and you can see why I don't have similar
confidence in Mochikit. Alternatively you can compare the membership
of the groups, the # of Google results for searches on "MochiKit" vs.
"JQuery", the # of commits to either library in the last year, ...
whatever metric you use, Mochikit always comes in last compared to not
just JQuery, but every other major JS library (prototype, YUI, dojo,
etc.) as well.

If you want something popular with a vocal community and lots of new
developments, you're in the wrong place and that's been the situation
for a long time. I don't think anyone here would try and convince you
otherwise.

Post by machineghost

what things is it missing?

Well there are two just in this thread alone: chainability and
additional element methods. Another great example from JQuery is the
onDOMReadyState pseudo-event. But again, it's not just the feature by
feature comparison between frameworks that matters; five years ago I
could not have predicted the need for an XmlHttpRequest abstraction,
but that's obviously a very essential feature for a JS library today.

Chainability probably is not going to happen, but onDOMReadyState
certainly should at some point. If you really like chainability, you
should probably be using jQuery. That's what it's good at, but I
personally don't care much for that style.

jQuery is a perfectly good library for what it intends to do, if it
does w hat you want it to how you want it to be done, why not just use
it? MochiKit is here because it solves a lot of problems that we had a
couple years ago before jQuery existed. Were it around in 2005 I
might've just used it instead of writing my own, but dojo and
prototype were not really worth using at the time. I have no real
vested interest for you to use MochiKit. I'm not involved with any
kind of consulting, I don't intend to write any books, not
particularly interested in speaking at any more conferences about JS,
etc. It helps me and my company out when people contribute code, file
bugs, etc. because this is the library we use. In other words, I don't
really care if you use MochiKit or not.

Post by machineghost
If my company had adopted some framework based solely on it's feature-
set back then, and that framework had never added an XmlHttpRequest
abstraction, I'd be up a proverbial creek without a paddle. I'd have
to convert all of our code to use a new library or else use two
libraries (and have a giant download footprint); either way I'd be
kicking myself for not choosing an actively developed framework.

I don't see the library itself as missing anything.

There are still hundreds of opportunities to make JS suck less, but
Mochikit is missing all of them while libraries like JQuery either
respond to them directly (by adding new stuff to the library) or
indirectly (via something like JQuery's plug-in mechanism).

All JavaScript frameworks have "plug-in mechanisms"... you can add
whatever code you want to the runtime system. From what I recall,
jQuery's plug-in mechanism is just there to make it easy to inject
things into jQuery's namespace such that it's chainable, which is not
something MochiKit needs. MochiKit is more of a collection of
libraries than a framework in that sense, because you don't need a
plug-in mechanism, you just add more code.

Post by machineghost

Is this because they wouldn't add a few aliases for you?

Hardly. I personally have proposed not just that but several other
enhancements, and of course I'm not the only one who has made
suggestions, yet almost no improvements have come out of any of that
feedback.
Contrast my thread proposing an onDOMContentReady pseudo-event here
(my most popular suggestion ever) with the similar thread in the
JQuery group. Here I got "that'd be cool if you do all the work and
submit it ... but if you don't the idea will die with you" (and due to
my disenchantment with MochiKit, it did).

If someone implements onDOMContentReady then the patch would almost
certainly be accepted. If nobody implements it, then it won't happen.
We're certainly welcome to it though. Clearly if we needed it bad
enough then we'd have done it ourselves by now, but it's more of a
nice-to-have than a need-to-have (at least for me). Ideas without code
are only useful if there are bored programmers sitting around willing
to write code for you for free; I don't think we have many of those
here :)

Post by machineghost
Ultimately, Mochikit is good enough for you and your company. That's
great, but I'm not going to bet my company's JS future on your
company's needs. I want a framework that takes advantage of all the
latest developments in the world of JS. I want a framework where new
ideas are welcomed and entertained, even if they are later ultimately
rejected. I want a framework that is constantly seeking to make
JavaScript suck less.
That framework isn't Mochikit.

Then what are you still doing here? Surely your effort would be better
spent on other mailing lists if you don't intend to contribute
something other than complaints about MochiKit...

-bob

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Per Cederberg]

Sorry to hear that you are discontent with MochiKit and are migrating
away from it. But I do understand your reasoning. Development has been
pretty stagnant here for a while, since we are only a small community
with a serious lack of developer time.

It has not been my intent to discourage changes or suggestions to
MochiKit. But my personal focus right now is on fixing and
investigating all outstanding issues before a 1.4 release (moving very
slowly, I admit). Hence the stop-energy I emit from time to time.

For what it's worth, I hope we can improve development speed after the
1.4 release. I've got a MochiKit-styled widget library that I intend
to contribute in due time and there is a bunch of other stuff floating
around. I also do have a vested interest in MochiKit staying
reasonably up-to-date, since I'm using it to create a web-based
development environment.

But since people are using svn trunk in production, I'm reluctant to
change stuff there until we have forked off a release.

Wish you all the best with jQuery and thanks for your suggestions here!

Cheers,

/Per

Post by machineghost
First off, I do <3 Mochikit. I wasn't trying to bash it, I just
wanted to share my opinion of it with someone who seemed to be in a
similar position.

Post by Jason Bunting

part of the reason changes are looked at with suspicion is because
a lot of suggestions are not in keeping with the intent of MochiKit.

Suspicion is one way to describe it; I'd lean more towards "outright
hostility" (although said hostility is generally civil and polite,
which is more than I can say for a lot of lists). And as for the
intent of MochiKit, I thought it was to "make JavaScript suck less."
It does that to some degree right now, but do you really think it's
impossible for JS to suck even less? I don't (JS sucks a lot, and I
say that even though it's one of my favorite languages).

Post by Jason Bunting

Is the lack of development necessarily indicative of a problem?

Absolutely, the health of any open source project is measured by it's
activity. As a JS implementer I need to know that the (JS framework)
horse I bet on is going to respond to my future needs in a timely
fashion. I have great confidence of that with JQuery because it has
an extremely active development community; try comparing the activity
http://groups.google.com/group/jquery-en?lnk=srg
to the activity here and you can see why I don't have similar
confidence in Mochikit. Alternatively you can compare the membership
of the groups, the # of Google results for searches on "MochiKit" vs.
"JQuery", the # of commits to either library in the last year, ...
whatever metric you use, Mochikit always comes in last compared to not
just JQuery, but every other major JS library (prototype, YUI, dojo,
etc.) as well.

Post by Jason Bunting

what things is it missing?

Well there are two just in this thread alone: chainability and
additional element methods. Another great example from JQuery is the
onDOMReadyState pseudo-event. But again, it's not just the feature by
feature comparison between frameworks that matters; five years ago I
could not have predicted the need for an XmlHttpRequest abstraction,
but that's obviously a very essential feature for a JS library today.
If my company had adopted some framework based solely on it's feature-
set back then, and that framework had never added an XmlHttpRequest
abstraction, I'd be up a proverbial creek without a paddle. I'd have
to convert all of our code to use a new library or else use two
libraries (and have a giant download footprint); either way I'd be
kicking myself for not choosing an actively developed framework.

Post by Jason Bunting

I don't see the library itself as missing anything.

There are still hundreds of opportunities to make JS suck less, but
Mochikit is missing all of them while libraries like JQuery either
respond to them directly (by adding new stuff to the library) or
indirectly (via something like JQuery's plug-in mechanism).

Post by Jason Bunting

Is this because they wouldn't add a few aliases for you?

Hardly. I personally have proposed not just that but several other
enhancements, and of course I'm not the only one who has made
suggestions, yet almost no improvements have come out of any of that
feedback.
Contrast my thread proposing an onDOMContentReady pseudo-event here
(my most popular suggestion ever) with the similar thread in the
JQuery group. Here I got "that'd be cool if you do all the work and
submit it ... but if you don't the idea will die with you" (and due to
my disenchantment with MochiKit, it did).
In contrast, that group had several different interested users who
came together, discussed the technical merits and disadvantages of
various implementations, and then ultimately added a very cool feature
their library. That never would have happened if the JQuery admin(s)
had created a culture of fear surrounding changes. There is a world
of difference between how that community responds to new ideas (even
the ones which are ultimately "shot down") and how this one
categorically denies the possibility of anything that doesn't
personally appeal to you or Per.
Of course I'm exaggerating a bit, but still the leadership of any
community sets the culture of that community, and here the culture is
"if it ain't broke don't fix it." That sort of culture is great for
stability, but it's not very conducive to improvement.
Ultimately, Mochikit is good enough for you and your company. That's
great, but I'm not going to bet my company's JS future on your
company's needs. I want a framework that takes advantage of all the
latest developments in the world of JS. I want a framework where new
ideas are welcomed and entertained, even if they are later ultimately
rejected. I want a framework that is constantly seeking to make
JavaScript suck less.
That framework isn't Mochikit.
Jeremy

Post by Jason Bunting
Jeremy,

Mochikit is VERY resistant to change, and if you try to suggest
changes people will basically tell you "why don't you go use that
other library if you like their features so much."

I think the fact that MochiKit is resistant to change is a Good Thing - we
can't make changes for every Tom, Dick and Harry that think it needs some
feature. As far as I can tell, part of the reason changes are looked at with
suspicion is because a lot of suggestions are not in keeping with the intent
of MochiKit.

As a side note, that line of thinking (coupled with the lack of any
real development) has convinced me that Mochikit is far too stagnant
for my company's business needs. As a result, I'm currently in the
process of researching how to migrate us to jQuery.

Is the lack of development necessarily indicative of a problem? When fruit
matures on a tree, it stops development and is picked and eaten. I think
MochiKit is mature and I have absolutely no problems with it, what things is
it missing? I rarely find things I need that MochiKit doesn't already
provide (unless, of course, you are looking for widgets and such).

So, I don't mean to be yet another voice saying "give up and go use
jQuery", but in my experience that path will be MUCH more rewarding
than trying to convince the Mochikit maintainers to change ... well,
anything.

Is this because they wouldn't add a few aliases for you? If so, that's a
poor reason to leave. I am really curious as to what you see missing -
granted, a better community of users would be nice, as far as developing
reusable widgets and such (I develop niche stuff and have to roll my own
regardless), but other than that, I don't see the library itself as missing
anything. As your last goodwill effort, provide some useful feedback.
Jason Bunting

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jason Bunting]

But my personal focus right now is on fixing and investigating all
outstanding issues before a 1.4 release (moving very slowly, I
admit).

What's left to do before we hit that? I would love to help, if I am able to work it in, but am not current on what the outstanding issues are...

I've got a MochiKit-styled widget library that I intend to
contribute in due time and there is a bunch of other stuff
floating around.

Yeah, I not only have some MochiKit-based widgets/controls/whatever in various states of development, but would love to see us gather everything similar that exists out there and make it available in one place, create and improve existing demo code, etc. Maybe those of us interested in doing this should come up with an actual plan instead of just mentioning it on this list every 3 months. :) We should formalize the end goal and how we plan on accomplishing it.

Where would we host this widget library? Would Bob be willing to host that kind of stuff? Does it belong with the rest of the MochiKit code in the same repository? I know we once loosely discussed this, but maybe we should once again just to get some momentum going, I don't know. All I do know is that I love using this library and have a vested interest in keeping it around and building support around it (makes it an easier sell to clients that hear about nothing but jQuery, Dojo, YUI and prototype/scriptaculous).

Hope everyone has a nice weekend!

Jason Bunting

_________________________________________________________________
Get thousands of games on your PC, your mobile phone, and the web with Windows®.
http://clk.atdmt.com/MRT/go/108588800/direct/01/
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Per Cederberg]

See http://trac.mochikit.com/report/3 for the bug report summary. I've
been occupied elsewhere most of the summer, so not much progress there
from me. Hope to start working on MochiKit again next week or so.

I guess people might object to a MochiKit.Widget module due to
footprint. My current source version is 133841 bytes (including doc
comments). MochiKit as a whole is 381328 right now.

So I think it will become more important for users to be able to
easily pick among different pre-packed versions of MochiKit. Like
"minimal", "full", "nowidget"...

If you want I can clean up my code a bit and push it to github in a
week or so. Or alternatively create a branch in svn and host it there.
But it is really not ready for inclusion due to poor documentation and
lack of tests right now. And I don't want to pollute the 1.4 version
with it.

Cheers,

/Per

On Fri, Aug 29, 2008 at 9:21 PM, Jason Bunting

Post by Jason Bunting

But my personal focus right now is on fixing and investigating all
outstanding issues before a 1.4 release (moving very slowly, I
admit).

What's left to do before we hit that? I would love to help, if I am able to
work it in, but am not current on what the outstanding issues are...

I've got a MochiKit-styled widget library that I intend to
contribute in due time and there is a bunch of other stuff
floating around.

Yeah, I not only have some MochiKit-based widgets/controls/whatever in
various states of development, but would love to see us gather everything
similar that exists out there and make it available in one place, create and
improve existing demo code, etc. Maybe those of us interested in doing this
should come up with an actual plan instead of just mentioning it on this
list every 3 months. :) We should formalize the end goal and how we plan on
accomplishing it.
Where would we host this widget library? Would Bob be willing to host that
kind of stuff? Does it belong with the rest of the MochiKit code in the same
repository? I know we once loosely discussed this, but maybe we should once
again just to get some momentum going, I don't know. All I do know is that I
love using this library and have a vested interest in keeping it around and
building support around it (makes it an easier sell to clients that hear
about nothing but jQuery, Dojo, YUI and prototype/scriptaculous).
Hope everyone has a nice weekend!
Jason Bunting
________________________________
Get thousands of games on your PC, your mobile phone, and the web with
Windows(R). Game with Windows

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jason Bunting]

Jeremy,

...do you really think it's impossible for JS to suck even less?
I don't (JS sucks a lot, and I say that even though it's one of
my favorite languages).

I consider myself a decent JavaScript programmer (i.e. I know how to write
it pretty well *without* a library like MK) and don't see that there really
are many things that need improvement, to be honest. Maybe I am not doing
enough interesting JavaScript hacking (I write it most every day though),
but there are few things I end up adding to my projects that I would
consider general purpose enough to end up as part of my personal JavaScript
toolkit - are there some? Why yes. Are there things that might be a good fit
for MochiKit? Yes, quite possibly. If they were rejected, would I get ticked
off? Probably not - I recognize that everyone has their own styles,
opinions, preferences, etc. and don't expect others to find value in the
same things I do. I find value in discussions about politics, but I have
many friends that don't - it doesn't mean I don't value their friendship or
that I quite hanging out with them.

Post by Jason Bunting
Is the lack of development necessarily indicative of a problem?

Absolutely, the health of any open source project is measured by it's
activity.

According to whom? I think this is poor rhetoric - MochiKit is mature, and
thus needs no more development. The human body reaches a point of maturity,
at which point it stops developing - we don't continue to increase in height
as we get past a certain point in life. Why should MochiKit be a busy hub of
activity all the time? Activity does not necessarily mean meaningful growth.

Post by Jason Bunting
what things is it missing?

Well there are two just in this thread alone: chainability and
additional element methods.

The fluent interface is a preference, it is not necessary and I don't feel
buys much of anything.

Another great example from JQuery is the onDOMReadyState pseudo-event.

I second what Bob said about this, both about the value of it, but also
about the fact that, if you want it, submit the patch. Do you expect to be
able to simply walk into a place, offer the suggestion, and have it done for
you? Open source thrives on *actual* contributions - ideas are nice to have,
but have little value until implemented.

But again, it's not just the feature by feature comparison between
frameworks that matters; five years ago I could not have predicted
the need for an XmlHttpRequest abstraction, but that's obviously a
very essential feature for a JS library today.

And I am willing to bet that if such a need arose today, MochiKit would
shortly have such a feature - but your personal preferences for aliases, the
onDOMReadyState pseudo-event and a fluent interface hardly qualify as being
in the same class as an XmlHttpRequest abstraction. There are some major
qualitative differences there...apples and oranges.

Post by Jason Bunting
I don't see the library itself as missing anything.

There are still hundreds of opportunities to make JS suck less, but
Mochikit is missing all of them while libraries like JQuery either
respond to them directly (by adding new stuff to the library) or
indirectly (via something like JQuery's plug-in mechanism).

"Hundreds," huh? Doubtful. And as for the "plug-in mechanism" you are
referring to, I again point to Bob's comments. This is JavaScript after all,
it isn't too hard to add your own code. I don't even understand what you are
getting at with this comment, it is almost a non-sequitur.

Post by Jason Bunting
Is this because they wouldn't add a few aliases for you?

Hardly. I personally have proposed not just that but several other
enhancements, and of course I'm not the only one who has made
suggestions, yet almost no improvements have come out of any of that
feedback.

Again, there must be someone to do the work - what work have you done as a
means to your suggested ends?

Contrast my thread proposing an onDOMContentReady pseudo-event here
(my most popular suggestion ever) with the similar thread in the
JQuery group. Here I got "that'd be cool if you do all the work and
submit it ... but if you don't the idea will die with you" (and due to
my disenchantment with MochiKit, it did).
In contrast, that group had several different interested users who
came together, discussed the technical merits and disadvantages of
various implementations, and then ultimately added a very cool feature
their library.

Well, here there are not as many users, so that group of "several different
interested users" becomes maybe one or two here - and you were one of them.
Why didn't you implement it? I would love to hear your answer.

this [group] categorically denies the possibility of anything that
doesn't personally appeal to you or Per.

Nice of you to include me on the decision making process, but I don't have
anything to do with that other than being a regular member of this group, no
different than you.

Of course I'm exaggerating a bit, but still the leadership of any
community sets the culture of that community, and here the culture is
"if it ain't broke don't fix it." That sort of culture is great for
stability, but it's not very conducive to improvement.

I think when you say "improvement" in this last statement you mean "changes
I want, which I also want you to implement," because improvements do seem
welcome here to me. And by the way, "if it ain't broke don't fix it" is a
wonderful policy, as far as I am concerned.

I want a framework that takes advantage of all the latest developments
in the world of JS.

You do know that the last official changes to the ECMA spec were made in
1999, right? Until another is made and there is wide-spread adoption, I
don't see there being any "developments in the world of JS" in the way that
you seem to imply. And again, if there are useful things that somehow come
about, as earlier alluded to in the comments about the XmlHttpRequest
abstraction, I am certain the few of us that use MochiKit will make sure
such features are implemented.

That framework isn't Mochikit.

Well, "hasta la vista" then - hope you enjoy using jQuery; may it be
everything you, and the thousands of other people using it, want it to be.
Who knows, maybe someday I will be using it as well - only it will not be
because I feel MochiKit has grown stagnant or because my ideas aren't
implemented; rather, it will be because of a conscious choice based on an
actual need.

Jason Bunting



--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Per Cederberg]

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

Post by Amit Mendapara

Post by Per Cederberg
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
0.0, to: 1.0});
</pre>

Post by Per Cederberg
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.

Post by Per Cederberg
Cheers,
/Per

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Amit Mendapara]

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

Post by Per Cederberg
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

Post by Amit Mendapara

Post by Per Cederberg
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
0.0, to: 1.0});
</pre>

Post by Per Cederberg
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.

Post by Per Cederberg
Cheers,
/Per

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Arnar Birgisson]

Post by Amit Mendapara
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/ac3f576c5696ec45

cheers,
Arnar

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Amit Mendapara]

Yes, it seems promising. If this is going to be happen, I will
continue on other things...

Regards
--
Amit Mendapara

Post by Arnar Birgisson

Post by Amit Mendapara
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 ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Per Cederberg]

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.

A better download system for MochiKit would also allow us to deprecate
submodules and replace them with new functionality under other names
in the future (thinking about Visual here).

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

Cheers,

/Per

On Wed, Aug 27, 2008 at 4:28 PM, Amit Mendapara

Post by Amit Mendapara
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

Post by Per Cederberg
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

Post by Amit Mendapara

Post by Per Cederberg
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
0.0, to: 1.0});
</pre>

Post by Per Cederberg
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.

Post by Per Cederberg
Cheers,
/Per

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[machineghost]

I'll be brief, as Arnar seems intent on his plans despite my warnings.

Basically I'd just like to clarify my previous criticisms: my primary
concern is NOT that MochiKit is unpopular, NOT that it has certain
really long function names, and NOT that I expect someone else to
implement code for me. My primary concern is that the leaders of the
community (which I see as being you Per, Bob, and one or two others)
do not foster an active development culture. Stuff like the lack of
onDOMContentReady isn't MochiKit's problem, but it is the symptom of
MochiKit's problem, which is the poor health of it's development
community.

IMHO you Per are actually the best in this regard; you generally
respond to new ideas with questions rather than outright
discouragement. However, Bob and others typically respond very
negatively to anything they personally can't use, and when you couple
that with a lack of clear criteria for what new things go in to the
framework or clear processes for contributing to the framework, you
get (again, IMHO) a project culture which strongly discourages
contributions and improvements.

Anyhow, I really hope that changes in the future, even though I'll
probably in JQuery land by the time it happens. As I said before, I
<3 MochiKit, I think that in many respects it's an awesome library,
and if the culture of the project were to change I fully believe it
could become the best JS framework available.

Jeremy

Post by Per Cederberg
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.
A better download system for MochiKit would also allow us to deprecate
submodules and replace them with new functionality under other names
in the future (thinking about Visual here).
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 :-)
Cheers,
/Per
On Wed, Aug 27, 2008 at 4:28 PM, Amit Mendapara

Post by Amit Mendapara
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

Post by Per Cederberg
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

Post by Amit Mendapara

Post by Per Cederberg
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
0.0, to: 1.0});
</pre>

Post by Per Cederberg
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.

Post by Per Cederberg
Cheers,
/Per

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Arnar Birgisson]

Hi Jeremy,

Post by machineghost
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 ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[machineghost]

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.

Post by Arnar Birgisson

Post by Bob Ippolito
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.

Post by Arnar Birgisson
Hi Jeremy,

Post by Bob Ippolito
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 ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Arnar Birgisson]

Hey all,

Post by machineghost
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).

No worries, I'm used to having my name mixed up :)

I have no intention of adding jQuery functionality to MochiKit though
(and I oppose doing soe), I'm a very happy user of both frameworks -
using the one that fits each project better.

Post by machineghost

Post by Bob Ippolito
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.

First of all, we all owe Bob and the other maintainers a lot of
thanks. Maintaining an open source project is a volunteering job after
all. Believe me, I've been a maintainer on few and it takes a lot of
time and effort, time that is not always available when you have a
job, run a business, go to school and/or have a family.

So, as long as Bob (or anyone else for that matter) is willing and
able to take on this responsibility of being the BDFL of MochiKit - he
(or they) can run things however they see fit as far as I'm concerned.
I'm just glad someone does it.

As for being out of luck, if you really think there is room for yet
another JavaScript library out there, and others are unwilling to
implement your ideas, there really is nothing stopping you from
forking either jQuery or MochiKit and publishing a hybrid. Who knows,
maybe that would even become the most popular framework out there!

Post by machineghost
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.

While I understand where you are coming from, for what it's worth _I_
very much like the way the MochiKit community is. I've had ideas, some
good, some bad. The good ones were met with positive attitude, I
implemented them and submitted patches and Bob, Thomas and Beu were
happy to donate their time in reviewing and allowing me to commit
them. I'd much rather have leaders that speak their mind candidly than
treading the political path of trying to please everyone.

So just to voice my opinion: The community is fine, let's not change it.

cheers,
Arnar

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Amit Mendapara]

Post by machineghost
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?

Post by machineghost
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.

Post by Arnar Birgisson
Hi Jeremy,

Post by machineghost
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 ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Amit Mendapara]

Post by Per Cederberg
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).

Post by Per Cederberg
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

Post by Per Cederberg
Cheers,
/Per
On Wed, Aug 27, 2008 at 4:28 PM, Amit Mendapara

Post by Amit Mendapara
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

Post by Per Cederberg
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

Post by Amit Mendapara

Post by Per Cederberg
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
0.0, to: 1.0});
</pre>

Post by Per Cederberg
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.

Post by Per Cederberg
Cheers,
/Per

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

[Jason Bunting]

Why wouldn't you just use $$(".someClass") rather than
getElementsByTagAndClassName(null, "someClass")?

Just curious...

Jason Bunting

-----Original Message-----
Behalf Of machineghost
Sent: Tuesday, August 19, 2008 10:29 AM
To: MochiKit
Subject: [mochikit] Random Ideas for Mochikit.DOM
Hey All,
I use a couple of "alias" functions in every project where I use the
/*
Shorten getElementsByTagAndClassName, because we know that we're
getting elements (nothing else has a tag/class) and we know we're
doing it by the "name" of the class or tag, because there is no other
way to identify a tag or class (pretty much all they are is a name).
*/
var getByTagAndClass = getElementsByTagAndClassName;
/*
I use getElementsByTagAndClassName(null, "someClass") all the time,
and it seemed silly to have to repeat a longer function name and a
"null, " every time.
*/
var getByClass = partial(getByTagAndClass, null);
Any chance of either of these making it in to Mochikit proper? BTW,
even if the first one was implemented, I'd still think we should keep
it as an alias (rather than changing getElementsByTagAndClassName) to
avoid breaking old code. Also, if the maintainers' really like long
function names for some odd reason, the second one could just as
easily be implemented as "getElementsByClassName" and still provide
the same usefulness.
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 8.0.138 / Virus Database: 270.6.5/1620 - Release Date: 8/19/2008
6:04 AM

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---