[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: Highlighting input fields
The Highlight effect must modify the style, but there should be an
option to restore any modified style after completion. Actually, there
is an undocumented restoreAfterFinish flag for the Scale effect that
does just that.
Perhaps what we should do is to add support for such a flag to all the
base effect classes. Or have another look at all the various
afterFinishInternal in the code that seem to cause a lot of code
replication (also indicating that the current API is far from
perfect).
Cheers,
/Per
On Tue, Aug 26, 2008 at 5:13 PM, Christoph Zwerschke [EMAIL PROTECTED] wrote:
When I highlight an input field using MochiKit.Visual.Highlight, its
background-color and background-image will be reset to white and
none. The problem is, when the input field had no style at all, it
used the default browser style, which looks different.
It's probably best to show this using the interactive JavaScript
interpreter demo of MochiKit. Enter the following commands:
a=INPUT(); b=INPUT();
writeln(FORM(null, a, b)); Highlight(a);
The left input field will be highlighted,
and after that, it will look different from the right one.
The following is even more obvious:
a=INPUT({readonly:true}); b=INPUT({readonly:true});
writeln(FORM(null, a, b)); Highlight(a);
It seems I can reset the style like this:
s = a.style; s.backgroundColor = s.backgroundImage = '';
Unfortunately, it does still not redraw automatically, the old style
will only come back when I hover over the input field with the mouse.
Has anybody an idea how to properly reset the style or even improve the
Highlight function in MochiKit so that it does not change the style?
-- Christoph
--~--~-~--~~~---~--~~
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: Morph with font-weight in IE
Slow response here, sorry. I think the behavior you describe below merits a bug report: http://trac.mochikit.com/ticket/318 Cheers, /Per On Mon, Jun 30, 2008 at 10:12 PM, diefans [EMAIL PROTECTED] wrote: hello, since IE is complaining (stopping execution of running function) about bad values in font-weight (everything except 100,200,300,400,500,600,700,800,900) is it possible to put the code within the Morph.update function into a try/catch block so that at least IE does not stop morphing the other styles? best regards Oliver --~--~-~--~~~---~--~~ 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: Selector speedup by using John Resig's Sizzle
Sorry, I am bit late to this discussion. It seems promising. As I said in another post, I am implementing jQuery style Query module which is currently using MochiKit.Selector (the code is not made public yet). As my proposed module is totally new, I'm not afraid of backward compatibility. That's why I have decided to implement new selector for the Query module. Though if MochiKit.Selector is going to be Sizzle based, it would be great... Another problem to which I am not sure is licensing issue, Sizzle is MIT licensed while MochiKit has dual MIT/AFL license. I myself thinking of releasing my code under any FSF approved licenses like MIT or GLP. Do you see any difficulties of including these sources to MochiKit particularly under AFL? Regards .. Amit Mendapara On Aug 25, 9:06 pm, Arnar Birgisson [EMAIL PROTECTED] wrote: Hey all, Some of you may have seen on reddit that John Resig (of jQuery) is working on a new, ultra-fast, css selector module. It is called Sizzle and although it is not released yet, John uploaded a version to github:http://github.com/jeresig/sizzle/tree/master MochiKit's Selector module (which is ported from early versions of Prototype) is unbearably slow, and thus many people steer clear of it. I asked John about the possibility of including Sizzle in MochiKit and he's ok with that, Sizzle will be released under the MIT license. I did a quick test, just deleted most of the Selector module and replaced with John's code, and modified the exported functions of the Selector module to use that instead. The MochiKit.Selector.Selector object has to go though, so this would not be an entirely backwards-compatible change. The functions findChildElements, findDocElements and $$ would be unchanged though. You can check out the speed test (included with Sizzle) where I've added both the trunk version of MochiKit and the MochiKit+Sizzle fusion here:http://www.hvergi.net/arnar/public/sizzle/speed/# For this benchmark, regular MochiKit completed all tests in 3983 milliseconds. The MochiKit+Sizzle combination does it in 61. That means we are talking about a speedup by a factor of roughly 65! It doesn't come without faults though. Sizzle didn't support all queries in MochiKit's unit tests, namely these are the ones that fail (I'm cc-ing John in case he wants to add support for any of them): a[fakeattribute] - i.e. checking for presence of attribute p[lang|=en] - membership test of hyphen-seperated string collections :nth-of-type(...) pseudo-class :enabled, :disabled and :checked pseudo-classes :root pseudo-class This change would increase the size of the packed version by about 1700 bytes (currently at 173.5 KB). Now, how do people feel about committing a change like this to the trunk? Of course, we'd wait until a fairly stable version of Sizzle is released. John told us that Sizzle will become the main selector engine behind jQuery, but will also remain a standalone component. All bugfixes will be backported to Sizzle also. As long as MochiKit keeps up, this means we'd benefit from the bugs reported by the jQuery community. A rough test, just plomping in the Sizzle source code into Selector.js is available on my website:http://www.hvergi.net/arnar/public/mochikit/MochiKit/Selector.js cheers, Arnar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
