>>I assume because like me everyone is busy. While I certainly fall in to that category, I can still probably find a few hours to help out with this on "sprint day" (and, as a fellow djangonaut, I should be able to be of some use).
Jeremy On Feb 21, 8:36 am, Chris Lee-Messer <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
