Ok, so here are my own comments to the feature list.
> # Note 1. I've included everything, regardless of whether the
> author/originator actually suggested them for inclusion into MochiKit
> or not.
Arnar: I didn't include the Selector module in the list since it
doesn't change the API. But naturally, the updates to Selector will
probably be one of the big features in 1.5.
> MochiKit.Base
The Base module is slowly getting larger. Perhaps this is not such a
big issue. But it will affect load times for everyone, since it cannot
be omitted.
> o rbind -- [trac] binds a function, but adds new args before bound ones
> o rpartial -- [trac] binds a function, but adds new args before bound ones
I added bindLate in 1.4 to our suite of bind-like functions. So right
now we have quite a few -- bind, partial, bindMethods, bindLate,
forwardCall, method & methodCaller. And this is confusing to me.
Probably even more so to casual users... Adding more variants to the
mix doesn't seem like the right thing to do. But we probably need to
create some more general API here.
> o extendURL -- [trac] merges name and values into a URL query string
I like the idea of having this in a HTTP module. We should probably
move the queryString and parseQueryString functions there too.
> o isFalse -- [mp] check for false, with wide interpretation
And, of couse, a corresponding isTrue function. Following Doug
Crockford terminology, these should probably be named isFalsy and
isTruthy instead.
> o defaultValue -- [mp] returns first non-undefined value
This is converting the || (default) operator into a function, which is
useful sometimes. In particular it handles values that are "falsy"
differently.
But perhaps something more generalized would be better:
firstArgument(isNot(isUndefinedOrNull), arg1, arg2...)
> o dict -- [mp] merges keys and values to dictionary object
Coming from Python, this can't be wrong... :-)
> o select -- [mp] copies listed keys (and values) from an object
> o mask -- [mp] removes listed keys (and values) from an object
I think the name suggestions from Arnar are good -- selectAttributes and
deleteAttributes. Or selectProperties and deleteProperties.
> o functionName -- [mp] returns the name of a function
> o registerFunctionNames -- [mp] registers function names
> - should probably be merged into nameFunctions
Merging into nameFunctions and skipping functionName altogther is
perhaps the right thing to do.
> o stackTrace -- [mp] returns current execution stack trace
> o injectStackTrace -- [mp] injects stack trace for a function
I'm using this for logging, so perhaps that would be a better
location. Creating a new Debug module would also be ok, but we'd need
more functionality to move there.
> o version -- [other] returns an object for browser detection & such
Others call this browser(), but MochiKit isn't necessarily used in a
web browser. Perhaps env() or environment() would be better?
While adding new stuff we should also consider moving existing
functions from Base to other (new) modules. Functions like these:
average, camelize, listMax, listMin, mean, median, objMax, objMin,
parseQueryString, queryString & urlEncode. Perhaps the JSON stuff
should also be moved elsewhere.
> MochiKit.Async
> o postSimpleXMLHttpRequest -- [trac] uses POST for a simple request
> o postJSONDoc -- [trac] same as above and also eval:s response data
> o sendJSONPrequest -- [trac] similar to the above, but different API
Agree with Arnar on the HTTP module. Don't know if the JSON stuff fits
in there, though. Or perhaps they do.
> o loadScript -- [trac] loads a JavaScript file
The loadScript function is probably best implemented by inserting a
<script> header. I've gone to great lengths to get that to work
properly in my own code, and it has the clear benefit of playing
nicely with the various consoles and Firebug. Using XMLHttpRequest and
eval() is the "standard" way of doing this, though.
> MochiKit.DateTime
> o MILLIS_PER_SECOND -- [mp] constant millisecond value
> o MILLIS_PER_MINUTE -- [mp] constant millisecond value
> o MILLIS_PER_HOUR -- [mp] constant millisecond value
> o MILLIS_PER_DAY -- [mp] constant millisecond value
> o MILLIS_PER_WEEK -- [mp] constant millisecond value
> o TimePeriod -- [mp] creates a new time period object
> (with days, hours, minutes, seconds & millis)
Perhaps splitDate would be a better name.
> o toApproxPeriod -- [mp] converts millis to an approximate time period
Yes, this function is probably too application-specific. I use it in
the ProgressBar widget to print the estimated time to completion.
> MochiKit.DOM:
> o NBSP -- [trac] creates a non-breaking space node
Perhaps we could add something more generic for HTML entities? Or
would we need a lookup table for that?
> o unescapeHTML -- [trac] creates a DOM tree from an HTML string
We need a clearer name, perhaps toDOM (being the inverse of toHTML)?
> MochiKit.Format
> o truncate -- [mp] returns a right-truncated copy of a string
> o formatter -- [mp] creates a generic formatter function
> o format -- [mp] formats the arguments with a formatter pattern
> o FormatPatternError -- [mp] a format pattern error class
Perhaps all the formatting should go to a new String module instead.
It kind of makes sense, as we are always formatting to a string.
> MochiKit.Signal
> o connectEventMap -- [trac] connect signals through a declarative map
I don't see any clear benefit with this. Personally kind of like to
declare the signals one by one in code.
> MochiKit.Visual
> o slideOnLeft -- [trac] slides an element while moving from right to left
> o slideOnRight -- [trac] variation of the theme above
> o slideOffLeft -- [trac] variation of the theme above
> o slideOffRight -- [trac] variation of the theme above
> o slidePairLeft -- [trac] variation of the theme above
> o slidePairRight -- [trac] variation of the theme above
> o slidePair -- [trac] variation of the theme above
A more general version would be nice. And I think the Move effect
should suffice here. Could have misunderstood things though.
> MochiKit.Test -- publish & improve existing module [trac]
I'll probably work on this a bit later on. So I don't know what API
would be appropriate yet.
> MochiKit.Cookie -- new module in [trac]
> o getCookie -- [trac] retrieves an HTTP cookie value
> o setCookie -- [trac] sets an HTTP cookie value
Would be a great addition, but in the HTTP module.
> MochiKit.Queue, Stack and AsyncQueue -- new modules in [trac]
> -- these are suggested data structures, should perhaps be placed in
> a Data module or similar.
The default Array class provides an efficient Stack and Queue already.
So I'd like to see a solid use case here.
> MochiKit.String -- new module in [me], here only missing MochiKit
> functions are presented
> o isalnum -- [me] checks if a string contains only alphanumeric characters
> o isalpha -- [me] checks if a string contains only A-Z characters
> o isdigit -- [me] checks if a string contains only numeric characters
> o isupper -- [me] checks if a string contains only upper-case characters
> o islower -- [me] checks if a string contains only lower-case characters
> o istitle -- [me] checks if a string is in title-case (is this same
> as camelCase?)
> o startswith -- [me] checks if a string starts with a substring
> o endswith -- [me] checks if a string ends with a substring
> o capitalize -- [me] converts the first character to upper-case and
> the rest to lower-case
> o swapcase -- [me] swaps the character case for a string
> o title -- [me] converts a string to title case
> o center -- [me] centers a string inside the specified width,
> padding with spaces
> o ljust -- [me] left-justifies a string inside the specified width,
> padding with spaces
> o rjust -- [me] right-justifies a string inside the specified width,
> padding with spaces
Some of these seem extremely useful to me. But instead of using a
String-wrapper like in the original code, I think we should just
continue the MochiKit-way and use plain utility functions. A String
(or Text) module would also be great for consolidating a few loose
functions here and there.
> MochiKit.Ajax -- new module in [me], names not exported (so no collisions)
> o bind -- [me] connects a signal for HTTP responses
> o unbind -- [me] disconnects a signal for HTTP responses
> o request -- [me] sends an HTTP request
> o get -- [me] sends an HTTP GET request
> o post -- [me] sends an HTTP POST request
We should simplify Async a bit further when using POST requests. And
it would be nice to be able to wrap Deferred objects into plain
signals. But perhaps we don't need a new module for that?
> MochiKit.Query -- new module in [me]
> -- I won't document this module here, but it seems (mostly?) API
> compatible with jQuery. It uses MochiKit to implement (part of) that
> API.
I find this idea intriguing. I know some people don't like to mix two
libraries on their web sites. So the idea of having some
API-compability layer for jQuery and others seem attractive. On the
other hand, we'd get into a nightmare of compability issues. And would
quite possibly have to reproduce code from other libraries. To little
gain in download size, I guess.
So perhaps I'm more thinking that we should stick to our MochiKit
function-style. Allowing people to mix MochiKit with jQuery on a
single page instead (i.e. providing docs on compability).
> MochiKit.SVG -- new module in [mp]
> o SVG -- [mp] creates an SVG document node
> o DEFS -- [mp] creates an SVG definitions node
> o G -- [mp] creates an SVG group node
> o LINE -- [mp] creates an SVG line node
> o RECT -- [mp] creates an SVG rectangle node
> o CIRCLE -- [mp] creates an SVG circle node
> o PATH -- [mp] creates an SVG path node
> o TEXT -- [mp] creates an SVG text node
> o RADIALGRADIENT -- [mp] creates an SVG radial gradient node
> o STOP -- [mp] creates an SVG gradient stop node
> o moveToTop -- [mp] moves a node to the top of the SVG drawing order
> o moveToBottom -- [mp] moves a node to the bottom of the SVG drawing order
> o rotate -- [mp] adds a rotation transform to an SVG DOM node
If I'm the only one interested in this module, I don't think it merits
inclusion.
> MochiKit.Widget -- new module in [mp]
> o isWidget -- [mp] checks if an object is a widget
> o isFormField -- [mp] checks if an object is a form field
> o createWidget -- [mp] creates a new widget
> o createWidgetTree -- [mp] creates a tree of DOM nodes and widgets
> o destroyWidget -- [mp] destroys a widget or a DOM node
> o Widget -- [mp] prototype widget object, not used directly
> o Button -- [mp] creates a new button widget
> o Dialog -- [mp] creates a new dialog widget
> o Field -- [mp] creates a new field widget
> o Form -- [mp] creates a new form widget
> o FormValidator -- [mp] creates a new form validator widget
> o Icon -- [mp] creates a new icon widget
> o Overlay -- [mp] creates a new overlay widget
> o Pane -- [mp] creates a new pane widget
> o Popup -- [mp] creates a new popup widget
> o ProgressBar -- [mp] creates a new progress bar widget
> o TabContainer -- [mp] creates a new tab container widget
> o Table -- [mp] creates a new data table widget
> o TableColumn -- [mp] creates a new data table column widget
> o TextArea -- [mp] creates a new text area (or text box) widget
> o TextField -- [mp] creates a new text field widget
> o Tree -- [mp] creates a new tree widget
> o TreeNode -- [mp] creates a new tree node widget.
> o Wizard -- [mp] creates a new wizard widget
I've received no feedback at all regarding the suggested Widget
library. So I've set up a new web page where you can play with at
least some of them:
http://www.percederberg.net/mochikit/xmlwidgets.html
Also, compared to YUI, Dojo, or ExtJS, the claim to fame for this
widget setup is that it does things a little bit differently:
1. It doesn't wrap DOM nodes, but uses a mixin approach instead.
That is, it adds functions and properties directly into the widget DOM
nodes. This means that all standard DOM functions and effects still
work on widgets.
2. The Widget API is similar to MochiKit.DOM and also returns DOM
nodes (see 1).
3. It supports creating widgets (and plain DOM nodes) from a UI
XML specification. This is similar in spirit to XAML (and some
others). It does NOT attach to existing DOM nodes (with special tags)
or use extended HTML, like most other widget libraries do.
But again. If I'm the only one interested in pushing this forward it
is probably better suited for a separate project.
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
-~----------~----~----~----~------~----~------~--~---
