Thanks again for everyone's comments.
My conclusions:
1. I plan to look more into using YUI with my current mochikit code as
well as the above mentioned widgets others have written.
2. It sounds like everyone would benefit from a site collecting
mochikit-based widgets.
3. The best place would be something linked from the mochikit.com
site.
4. No one is leaping forward to be a maintainer to set up a trac or
wiki or other such site---I assume because like me everyone is busy.
One thought: I might be able to put together a django-based
application to collect code like django-snippets (http://
www.djangosnippets.org/) which requires registration in order to
submit. I wouldn't be able to tend it often, so it would need near
self-sufficient or some other people would need to step forward.
I will email James Bennett to see how much work his site takes now
that it's set up. I think James has open-sourced most of the code for
his site. It seems like a straightforward application but I don't
know how spam is handled.
If others are interested, perhaps we could pick a day or two to work
on it next month as a sprint. I can find some time on a weekend in
march
On Feb 17, 6:19 am, "Per Cederberg" <[EMAIL PROTECTED]> wrote:
> Interesting comments about YUI. Would be intreresting to hear comments
> about ExtJS too, if someone has tried it yet. Parts of their API seem
> to reproduce Prototype though.
>
> Starting on square one with a new library seems like a lot of
> duplication of effort. But the event handling in a widget library is
> really core functionality and is hard work to change or adapt. So, to
> make a MochiKit.Widget or MochiKit.UI effort worthwile, it must
> provide a serious number of advantages or differentiators.
>
> My current ideas are more or less these:
>
> o Compability with MochiKit.DOM by just adding JavaScript functions to
> DOM nodes (with update). I.e, not creating specific widget objects
> that refer to DOM nodes (like everybody else does), but rather attempt
> to merge the DOM and widget concepts a bit.
>
> o The API could also be more functional, instead of OO. Like
> MochiKit.DOM, allowing the mixing of code:
> TabContainer(null, TabPane({ title: "Tab 1" }, TABLE(...), TabPane(...))
>
> o Usage of MochiKit.Signal (of course).
>
> o Serialization into a text or source code format, so that the UI can
> be cleanly separated from the rest of the code, in particular the
> event handling code. I'd like my applications to first build the UI
> and then attach to any signals that I'm interested in.
>
> Don't know yet if the above is enough of a differentiator, though.
> Today I have components for Dialog, RadioGroup, TabContainer,
> SortableTable, Tree along with a set of simpler and more plain HTML
> components like Label, TextField, TextBox and others. Unfortunately
> they don't use MochiKit much, nor do they follow the API outlined
> above. Hence I'm planning to port everything to this new model... or
> just throw it all away in favor of YUI or ExtJS.
>
> /Per
>
> On Sun, Feb 17, 2008 at 2:28 AM, machineghost <[EMAIL PROTECTED]> wrote:
>
> > About a year ago I found myself in a similar situation, and began
> > looking in to other libraries besides Mochikit for all of my "widget"
> > needs. I ultimately went with the YUI (Yahoo User Interface) library,
> > and discovered that it in fact works very well with Mochikit. Not
> > seamlessly mind you, but very well.
>
> > First, the bad stuff: YUI's event handling system can't be used with
> > Mochikit's, and YUI is a bit more on the Java side philosophically (as
> > opposed to Mochikit's Pythonic bent). The event handling thing is
> > certainly annoying, as I much prefer the Signal library to YUI's
> > equivalent. However, I can still use the Signal library for any event
> > which isn't directly related to the YUI component(s), and I can still
> > use all the rest of Mochikit directly with the YUI components (for
> > instance, I often update the settings of my YUI component objects by
> > using the Mochikit "update" function). As for the Java-ish thing,
> > it's really more like a lack of the clever, intuitive feel that
> > Mochikit (and Python) has; it's occasionally frustrating, but not
> > anything that truly gets in the way of using the library.
>
> > Now for the good stuff: aside from the event managing issue, YUI and
> > Mochikit have almost no overlap. Mochikit is all about wonderful
> > functions that help you get more done faster, whereas YUI is all about
> > well constructed widgets that provide both excellent functionality and
> > flexibility. Using them together, you can let YUI help you leapfrog
> > past the basic parts of writing a component, and then write the more
> > interesting parts with all the speed and convenience of Mochikit.
>
> > I've worked with the YUI Calendar and AutoComplete libraries
> > extensively, and both allowed me to get all the base functionality I
> > wanted (the ability to render a calendar or have an auto-completing
> > search box) with some additional features I hadn't even have thought
> > of (like multi-month calendar views), and with a slick/professional
> > look that works across all major browsers. Before I tried YUI I
> > attempted to write both components from scratch, and I didn't have
> > much success. Once I discovered YUI, I was able to fully-implement
> > the core functions of these components, and then get on to the fun
> > parts, in less time than it had taken me to write even the most bare
> > bones, half-working-and-even-then-only-in-Firefox type versions of the
> > components from scratch.
>
> > I strongly encourage anyone looking for base Javascript "widgets" to
> > consider YUI. It's not Mochikit, nor does it feel like Mochikit, and
> > that is a little annoying at times, but the fact that Yahoo's web
> > engineering team does half your job for you more than makes up for it.
>
> > Jeremy
>
> > P.S. I think the idea of Mochikit Widget Library is awesome; I know
> > that if I had a choice of equally functional YUI and Mochikit versions
> > of a component, I wouldn't even think twice about picking the Mochikit
> > one. However, YUI already has A LOT of really great code, and I would
> > imagine one could get a lot farther, a lot faster, by working on some
> > sort of Mochikit port of or interface with the YUI library, rather
> > than starting all over from square one.
>
> > On Feb 15, 12:57 pm, Chris Lee-Messer <[EMAIL PROTECTED]>
> > wrote:
>
> > > First, I want to thank Bob and the rest of the mochikit team for this
> > > great library.
>
> > > As a javascript neophyte, I chose Mochikit because it seemed to fit my
> > > way of thinking. I use python a great deal and mochikit with it's good
> > > documentation and clarity of organization made javascript more
> > > rational to me.
>
> > > Thanks to Mochikit, I was able to build an in-house ajax-type web
> > > applicaton from scratch and bring it live within a few weeks.
>
> > > Now I am looking to add more features and I would like to avoid
> > > spending time writing javascript widgets if it's not necessary. There
> > > are now quite a few popular widget libraries and I have looked at
> > > several of them (yui, dojo, jquery, etc.). Quite a few people have put
> > > together comparisons and reviews and I am not looking to repeat that
> > > discussion here.
>
> > > The question for me is how compatible the mindset of a library is with
> > > what I've done before. Some of the pythonista's like to say "Python
> > > fits my brain." Mochikit fits for me and ideally, any library that I
> > > add would do the same.
>
> > > I'm interested in finding out from mochikit users if they think that
> > > ne of the javascript widget libraries best fits the mochikit way of
> > > doing things.
>
> > > Alternatively, having a place--say on google code--with mochikit-
> > > based widgets would allow the community to gradually build up a set of
> > > mochikit-based widgets.
>
> > > Many thanks.
> > > -Chris
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
