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 [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
-~----------~----~----~----~------~----~------~--~---
