[mochikit] Re: other widget toolboxes most compatbile with mochikit?
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
[mochikit] Re: other widget toolboxes most compatbile with mochikit?
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
