[mochikit] Re: Random Ideas for Mochikit.DOM
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 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
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 [EMAIL PROTECTED] wrote: 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 mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Random Ideas for Mochikit.DOM
On Tue, Aug 26, 2008 at 6:34 PM, machineghost [EMAIL PROTECTED] wrote: First off, I do 3 Mochikit. I wasn't trying to bash it, I just wanted to share my opinion of it with someone who seemed to be in a similar position. part of the reason changes are looked at with suspicion is because a lot of suggestions are not in keeping with the intent of MochiKit. Suspicion is one way to describe it; I'd lean more towards outright hostility (although said hostility is generally civil and polite, which is more than I can say for a lot of lists). And as for the intent of MochiKit, I thought it was to make JavaScript suck less. It does that to some degree right now, but do you really think it's impossible for JS to suck even less? I don't (JS sucks a lot, and I say that even though it's one of my favorite languages). Yes, it's certainly possible, but it does what we want it to do... if it didn't, you'd see a lot more commits from us. Is the lack of development necessarily indicative of a problem? Absolutely, the health of any open source project is measured by it's activity. As a JS implementer I need to know that the (JS framework) horse I bet on is going to respond to my future needs in a timely fashion. I have great confidence of that with JQuery because it has an extremely active development community; try comparing the activity on their list: http://groups.google.com/group/jquery-en?lnk=srg to the activity here and you can see why I don't have similar confidence in Mochikit. Alternatively you can compare the membership of the groups, the # of Google results for searches on MochiKit vs. JQuery, the # of commits to either library in the last year, ... whatever metric you use, Mochikit always comes in last compared to not just JQuery, but every other major JS library (prototype, YUI, dojo, etc.) as well. If you want something popular with a vocal community and lots of new developments, you're in the wrong place and that's been the situation for a long time. I don't think anyone here would try and convince you otherwise. what things is it missing? Well there are two just in this thread alone: chainability and additional element methods. Another great example from JQuery is the onDOMReadyState pseudo-event. But again, it's not just the feature by feature comparison between frameworks that matters; five years ago I could not have predicted the need for an XmlHttpRequest abstraction, but that's obviously a very essential feature for a JS library today. Chainability probably is not going to happen, but onDOMReadyState certainly should at some point. If you really like chainability, you should probably be using jQuery. That's what it's good at, but I personally don't care much for that style. jQuery is a perfectly good library for what it intends to do, if it does w hat you want it to how you want it to be done, why not just use it? MochiKit is here because it solves a lot of problems that we had a couple years ago before jQuery existed. Were it around in 2005 I might've just used it instead of writing my own, but dojo and prototype were not really worth using at the time. I have no real vested interest for you to use MochiKit. I'm not involved with any kind of consulting, I don't intend to write any books, not particularly interested in speaking at any more conferences about JS, etc. It helps me and my company out when people contribute code, file bugs, etc. because this is the library we use. In other words, I don't really care if you use MochiKit or not. If my company had adopted some framework based solely on it's feature- set back then, and that framework had never added an XmlHttpRequest abstraction, I'd be up a proverbial creek without a paddle. I'd have to convert all of our code to use a new library or else use two libraries (and have a giant download footprint); either way I'd be kicking myself for not choosing an actively developed framework. I don't see the library itself as missing anything. There are still hundreds of opportunities to make JS suck less, but Mochikit is missing all of them while libraries like JQuery either respond to them directly (by adding new stuff to the library) or indirectly (via something like JQuery's plug-in mechanism). All JavaScript frameworks have plug-in mechanisms... you can add whatever code you want to the runtime system. From what I recall, jQuery's plug-in mechanism is just there to make it easy to inject things into jQuery's namespace such that it's chainable, which is not something MochiKit needs. MochiKit is more of a collection of libraries than a framework in that sense, because you don't need a plug-in mechanism, you just add more code. Is this because they wouldn't add a few aliases for you? Hardly. I personally have proposed not just that but several other enhancements, and of course I'm not the only one who has made suggestions, yet almost no improvements have come out of any of that
[mochikit] Re: Random Ideas for Mochikit.DOM
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 On Wed, Aug 27, 2008 at 3:34 AM, machineghost [EMAIL PROTECTED] wrote: First off, I do 3 Mochikit. I wasn't trying to bash it, I just wanted to share my opinion of it with someone who seemed to be in a similar position. part of the reason changes are looked at with suspicion is because a lot of suggestions are not in keeping with the intent of MochiKit. Suspicion is one way to describe it; I'd lean more towards outright hostility (although said hostility is generally civil and polite, which is more than I can say for a lot of lists). And as for the intent of MochiKit, I thought it was to make JavaScript suck less. It does that to some degree right now, but do you really think it's impossible for JS to suck even less? I don't (JS sucks a lot, and I say that even though it's one of my favorite languages). 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. 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. 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). 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
[mochikit] Re: Random Ideas for Mochikit.DOM
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
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 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/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 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
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. 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. 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. 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. 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
[mochikit] Re: Random Ideas for Mochikit.DOM
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
[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
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
On Aug 27, 8:44 am, 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.
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
[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
[mochikit] Re: Random Ideas for Mochikit.DOM
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: Random Ideas for Mochikit.DOM
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. 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: 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: Random Ideas for Mochikit.DOM
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
On Aug 20, 11:37 pm, 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
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 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
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). 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. 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. 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). 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 On Aug 26, 3:34 pm, Jason Bunting [EMAIL PROTECTED] wrote: 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
[mochikit] Re: Random Ideas for Mochikit.DOM
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
[EMAIL PROTECTED] wrote:
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
-~--~~~~--~~--~--~---
[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
On Tue, Aug 19, 2008 at 1:26 PM, Jason Bunting [EMAIL PROTECTED] wrote: 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 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
-~--~~~~--~~--~--~---
[mochikit] Re: Random Ideas for Mochikit.DOM
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 On Aug 19, 9:28 am, machineghost [EMAIL PROTECTED] wrote: 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 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
Why wouldn't you just use $$(.someClass) rather than getElementsByTagAndClassName(null, someClass)? Just curious... Jason Bunting -Original Message- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On 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 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. 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 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
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- From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] On 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 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 On Aug 19, 9:28 am, machineghost [EMAIL PROTECTED] wrote: 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. 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 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
Hey all,
On Tue, Aug 19, 2008 at 17:26, Jason Bunting [EMAIL PROTECTED] wrote:
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 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
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 ...).
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
On Aug 19, 10:40 am, Arnar Birgisson [EMAIL PROTECTED] wrote:
Hey all,
On Tue, Aug 19, 2008 at 17:26, Jason Bunting [EMAIL PROTECTED] wrote:
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 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
-~--~~~~--~~--~--~---
