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 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 [email protected]
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
-~----------~----~----~----~------~----~------~--~---
