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
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
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
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
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
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 ;).
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
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
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
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.
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
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
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.
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
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
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
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
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.
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
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,
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 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
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
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:
:[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
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
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
27 matches
Mail list logo
