Discussion:
Suggested API:s for MochiKit 1.5
Per Cederberg
2008-10-27 09:49:01 UTC
Permalink
Hi everyone,

Development of MochiKit 1.5 is about to start. But before we open the
flood-gates, it might be useful to have a look at a summary of all
proposed API:s. Below you'll find a comprehensive list of all API
additions that I've found (so far).

# Note 1. I've included everything, regardless of whether the
author/originator actually suggested them for inclusion into MochiKit
or not.

# Note 2. In some cases the source code exists and has been tested.
Not so in others.

# Note 3. Some of these API suggestions might be duplicates of
something already in MochiKit. Or are perhaps better implemented as
improvements to existing functions. Some of them might just be common
usage patterns that either deserve proper documentation or perhaps an
alias function.

So, in summary, please don't get too agitated about individual entries
on the list below. Nothing is set in stone and I'm only looking to
collect statistics, ideas, clarified names, generalizations, random
thoughts and such. See this as my attempt to collect your thoughts and
votes about what you want from MochiKit in the future.

I'm holding off a bit on my own analysis. Will post my comments on
individual suggestions later on.

Cheers,

/Per

Source Notations:
[trac] Enhancement suggestions in MochiKit Trac, usually without a
proposed implementation.
http://trac.mochikit.com/report/3
[me] Patches from the MochiKit Extensions project on LaunchPad
https://launchpad.net/mochikit-ext
[mp] Patches from the mochikit-patches project on GitHub.
http://github.com/cederberg/mochikit-patches/tree/master
[other] Random thoughts found elsewhere (don't know where)

MochiKit.Base
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
o extendURL -- [trac] merges name and values into a URL query string
o isFalse -- [mp] check for false, with wide interpretation
o defaultValue -- [mp] returns first non-undefined value
o dict -- [mp] merges keys and values to dictionary object
o select -- [mp] copies listed keys (and values) from an object
o mask -- [mp] removes listed keys (and values) from an object
o functionName -- [mp] returns the name of a function
o registerFunctionNames -- [mp] registers function names
- should probably be merged into nameFunctions
o stackTrace -- [mp] returns current execution stack trace
o injectStackTrace -- [mp] injects stack trace for a function
o version -- [other] returns an object for browser detection & such

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
o loadScript -- [trac] loads a JavaScript file

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)
o toApproxPeriod -- [mp] converts millis to an approximate time period

MochiKit.DOM:
o NBSP -- [trac] creates a non-breaking space node
o unescapeHTML -- [trac] creates a DOM tree from an HTML string
o selectRange -- [trac] selects text in a text box or field
o NS.XHTML -- [mp] namespace constant
o NS.XLINK -- [mp] namespace constant
o NS.SVG -- [mp] namespace constant
o NS.XUL -- [mp] namespace constant
o NS.HTML -- [mp] namespace constant
o isDOM -- [mp] checks if an object looks like a DOM node
o isHTML -- [mp] checks if an object looks like an HTML or XHTML DOM node
o reprDOM -- [mp] creates debug representation of a DOM node
o attributeArray -- [mp] make existing impl. public
o childNode -- [mp] returns an immediate child node
o createDOMExt -- [mp] creates a DOM node with a namespace
o createTextNode -- [mp] creates a DOM text node
o createDOMFuncExt -- [mp] returns function for creating DOM nodes
o blurAll -- [mp] blurs (unfocuses) a DOM node and all relevant children

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

MochiKit.Style
o setPositionFixed -- [trac] sets fixed position in cross-browser way
o getContainingBlock -- [trac] returns the containing (layout) parent node
o getMarginBox -- [trac] returns the margin widths for an HTML DOM node
o getBorderBox -- [mp] returns the border widths for an HTML DOM node
o getPaddingBox -- [mp] returns the padding widths for an HTML DOM node
o getScrollOffset -- [mp] returns the scroll offset for an HTML DOM node
o setScrollOffset -- [mp] sets the scroll offset for an HTML DOM node
o resetScrollOffset -- [mp] resets the scroll offsets to zero
o adjustScrollOffset -- [mp] ensures optimal visibility for a box
o registerSizeConstraints -- [mp] registers algebraic constraints for an
element width, height and aspect ratio
o resizeElements -- [mp] resizes DOM nodes using parent sizes and registered
constraints

MochiKit.Signal
o connectEventMap -- [trac] connect signals through a declarative map

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

MochiKit.Test -- publish & improve existing module [trac]

MochiKit.Cookie -- new module in [trac]
o getCookie -- [trac] retrieves an HTTP cookie value
o setCookie -- [trac] sets an HTTP cookie value

MochiKit.Queue, Stack and AsyncQueue -- new modules in [trac]
-- these are suggested data structures, should perhaps be placed in
a Data module or similar.

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

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

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.

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

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

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
SanderElias
2008-10-27 10:34:41 UTC
Permalink
Hi Per,

This is a good list! It fills is quite a number off voids in Mochikit!
However I would propose to add a few string function, to complete the
batch:

ltrim -- Trims all the left spaces in a string
rtrim -- Trims all the right spaces in a string
alltrim -- Trimms all (left an right) spaces in a string.

just my 2 eutocents ;)

regards
Sander
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
Per Cederberg
2008-10-27 11:14:08 UTC
Permalink
Post by SanderElias
ltrim -- Trims all the left spaces in a string
rtrim -- Trims all the right spaces in a string
alltrim -- Trimms all (left an right) spaces in a string.
These are available as strip(), lstrip() and rstrip() in
MochiKit.Format. But should probably be moved somewhere where people
would actually look for them. And perhaps also be renamed to trim() as
above.

Cheers,

/Per

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
David Janes
2008-10-27 11:25:53 UTC
Permalink
Post by Per Cederberg
Post by SanderElias
ltrim -- Trims all the left spaces in a string
rtrim -- Trims all the right spaces in a string
alltrim -- Trimms all (left an right) spaces in a string.
These are available as strip(), lstrip() and rstrip() in
MochiKit.Format. But should probably be moved somewhere where people
would actually look for them. And perhaps also be renamed to trim() as
above.
Renaming strip -> trim wouldn't be respecting the Pythonic roots of
Mochikit though. That said, it's not really using the Python naming
conventions either.

Regards, etc...
David


--
David Janes
Mercenary Programmer

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
Arnar Birgisson
2008-10-29 14:11:20 UTC
Permalink
Post by Per Cederberg
Post by SanderElias
ltrim -- Trims all the left spaces in a string
rtrim -- Trims all the right spaces in a string
alltrim -- Trimms all (left an right) spaces in a string.
These are available as strip(), lstrip() and rstrip() in
MochiKit.Format. But should probably be moved somewhere where people
would actually look for them.
If we implement the suggested "String" module - that would of course
be a natural spot.

cheers,
arnar

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
Arnar Birgisson
2008-10-29 14:09:50 UTC
Permalink
Post by SanderElias
ltrim -- Trims all the left spaces in a string
rtrim -- Trims all the right spaces in a string
alltrim -- Trimms all (left an right) spaces in a string.
just my 2 eutocents ;)
Let me give my 10,000 Icelandic kronas on this - MochiKit already
heavily draws on Python so I would suggest "lstrip", "rstrip" and
"strip".

cheers,
Arnar

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
Arnar Birgisson
2008-10-29 14:37:59 UTC
Permalink
Hi Per,

Good work in compiling the list. You left out the changes to the
Selector module though.
Post by Per Cederberg
MochiKit.Base
o select -- [mp] copies listed keys (and values) from an object
o mask -- [mp] removes listed keys (and values) from an object
I would suggest more descriptive names, selectAttributes and
deleteAttributes perhaps.
Post by Per Cederberg
o stackTrace -- [mp] returns current execution stack trace
o injectStackTrace -- [mp] injects stack trace for a function
These should perhaps be in an optional module called "Debug".
Post by Per Cederberg
o version -- [other] returns an object for browser detection & such
Needs more descriptive name, this suggests only MochiKit version.
Post by Per Cederberg
MochiKit.Async
MochiKit.Cookie -- new module in [trac]
MochiKit.Ajax -- new module in [me], names not exported (so no collisions)
I never liked that the XmlHttpRequest stuff was in Async. I also
dislike the name Ajax as it is imprecise and has become very
overloaded. I suggest trimming Async down to just the generic
mechanisms of deferreds etc. and creating a new module, called HTTP.
This module would contain the XmlHttpRequest wrappers (relying on
Async of course), utilities for url-encoding, dealing with HTTP
headers and cookies.
Post by Per Cederberg
MochiKit.DateTime
o toApproxPeriod -- [mp] converts millis to an approximate time period
I would vote against this. This functionality is too app specific to
add to a generic library. Rather, it should be published in a
"snippets" section on the MK website - as it will most likely require
tweaks for each use case.
Post by Per Cederberg
MochiKit.Queue, Stack and AsyncQueue -- new modules in [trac]
-- these are suggested data structures, should perhaps be placed in
a Data module or similar.
I agree these should be combined in one module. I don't know if
"Collections" is the proper name - "Data" is perhaps better.
Post by Per Cederberg
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'm not entirely convinced this fits in MochiKit. Why not just use jQuery?

cheers,
Arnar

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
Amit Mendapara
2008-11-03 20:16:39 UTC
Permalink
Post by Arnar Birgisson
Post by Per Cederberg
MochiKit.Async
MochiKit.Cookie -- new module in [trac]
MochiKit.Ajax -- new module in [me], names not exported (so no collisions)
I never liked that the XmlHttpRequest stuff was in Async. I also
dislike the name Ajax as it is imprecise and has become very
overloaded. I suggest trimming Async down to just the generic
mechanisms of deferreds etc. and creating a new module, called HTTP.
This module would contain the XmlHttpRequest wrappers (relying on
Async of course), utilities for url-encoding, dealing with HTTP
headers and cookies.
I agree, the signal names should be renamed something like `httpStart,
httpStop, httpSuccess, httpError` for `ajaxStart, ajaxStop,
ajaxSuccess, ajaxError` respectively. Also, I think it's not good to
expose the names globally, so

MochiKit.HTTP.get(...)
MochiKit.HTTP.post(...)
MochiKit.HTTP.JSON.get(...)
MochiKit.HTTP.JSON.post(...)
MochiKit.HTTP.Cookie.get(...)
MochiKit.HTTP.Cookie.set(...)
MochiKit.HTTP.Cookie.del(...)

and so on...

would be nice.
Post by Arnar Birgisson
Post by Per Cederberg
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'm not entirely convinced this fits in MochiKit. Why not just use jQuery?
May be, but I think I have said about this in my previous response why
people like me don't like to mix them up...

Regards
--
Amit Mendapara
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
Arnar Birgisson
2008-11-04 09:58:26 UTC
Permalink
Hi Amit,
Post by Amit Mendapara
MochiKit.HTTP.get(...)
MochiKit.HTTP.post(...)
MochiKit.HTTP.JSON.get(...)
MochiKit.HTTP.JSON.post(...)
MochiKit.HTTP.Cookie.get(...)
MochiKit.HTTP.Cookie.set(...)
MochiKit.HTTP.Cookie.del(...)
and so on...
would be nice.
I agree, these do indeed look very nice - and in designing a library
from scratch I would really consider using namespaces like that.
However, we must also think of consistency with the rest of MochiKit.
Namespaces aren't really used like this and things like "getCookie"
etc. rhyme more closely with the existing naming scheme.

Say you knew all other parts of MochiKit and had to guess on the name
of the function to set a cookie. Your first guess would most likely be
"setCookie" and "Cookie.set" might not even come to mind.

cheers,
Arnar

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
Per Cederberg
2008-10-30 22:57:28 UTC
Permalink
Ok, so here are my own comments to the feature list.
Post by Per Cederberg
# 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.
Post by Per Cederberg
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.
Post by Per Cederberg
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.
Post by Per Cederberg
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.
Post by Per Cederberg
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.
Post by Per Cederberg
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...)
Post by Per Cederberg
o dict -- [mp] merges keys and values to dictionary object
Coming from Python, this can't be wrong... :-)
Post by Per Cederberg
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.
Post by Per Cederberg
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.
Post by Per Cederberg
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.
Post by Per Cederberg
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.
Post by Per Cederberg
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.
Post by Per Cederberg
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.
Post by Per Cederberg
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.
Post by Per Cederberg
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.
Post by Per Cederberg
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?
Post by Per Cederberg
o unescapeHTML -- [trac] creates a DOM tree from an HTML string
We need a clearer name, perhaps toDOM (being the inverse of toHTML)?
Post by Per Cederberg
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.
Post by Per Cederberg
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.
Post by Per Cederberg
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.
Post by Per Cederberg
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.
Post by Per Cederberg
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.
Post by Per Cederberg
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.
Post by Per Cederberg
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.
Post by Per Cederberg
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?
Post by Per Cederberg
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).
Post by Per Cederberg
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.
Post by Per Cederberg
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 ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
Arnar Birgisson
2008-10-31 00:15:18 UTC
Permalink
Post by Per Cederberg
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.
There will actually be a minor API change, the Selector.Selector
prototype will go away. Maybe we should also expose the Sizzle
prototype instead.
Post by Per Cederberg
Post by Per Cederberg
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.
We should absolutely be very picky about what goes into Base.
Post by Per Cederberg
Post by Per Cederberg
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.
To draw from Python again, both could be implemented with one function
called "bool". This would convert any object to a boolean.
Post by Per Cederberg
firstArgument(isNot(isUndefinedOrNull), arg1, arg2...)
How about a generic "first" function in Iter? Would be

first(someCheck, iterable[, defaultValue=undefined])
Post by Per Cederberg
Post by Per Cederberg
o dict -- [mp] merges keys and values to dictionary object
Coming from Python, this can't be wrong... :-)
I'm not sure I understand, JS doesn't have named arguments so this
would be called with

x = dict({'key1': 'val1', 'key2': 'val2'})

right? Isn't that just the identity function?

function dict(x) { return x; }
Post by Per Cederberg
Post by Per Cederberg
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.
Should pick the one that is more consistent with JS nomenclature.
Post by Per Cederberg
Post by Per Cederberg
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.
Logging sounds find to me.
Post by Per Cederberg
Post by Per Cederberg
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?
If MK is ever used in a command-line JS interpreter, then environment
would suggest the OS environment variables. I propse platform().

platform() should return an object with keys/values if called with no
arguments, and return a the value of a key otherwise.. i.e.

platform() == {'kind': 'browser', 'name': 'Google Chrome', 'version': ...}
platform('name') == 'Google Chrome'
Post by Per Cederberg
Agree with Arnar on the HTTP module. Don't know if the JSON stuff fits
in there, though. Or perhaps they do.
Not sure if there's a better place atm.
Post by Per Cederberg
Post by Per Cederberg
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.
I agree.
Post by Per Cederberg
The default Array class provides an efficient Stack and Queue already.
So I'd like to see a solid use case here.
... also with this.
Post by Per Cederberg
But again. If I'm the only one interested in pushing [Widget] forward it
is probably better suited for a separate project.
I think it might. To me, MK is a programmer's utility library. UI
libraries should be kept separate because everyone want's a different
UI. Also, UI libraries are huge cans of worms.

cheers,
Arnar

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
Per Cederberg
2008-10-31 09:24:50 UTC
Permalink
Post by Arnar Birgisson
To draw from Python again, both could be implemented with one function
called "bool". This would convert any object to a boolean.
Nice idea!
Post by Arnar Birgisson
How about a generic "first" function in Iter? Would be
first(someCheck, iterable[, defaultValue=undefined])
This too!
Post by Arnar Birgisson
I'm not sure I understand, JS doesn't have named arguments so this
would be called with
x = dict({'key1': 'val1', 'key2': 'val2'})
right? Isn't that just the identity function?
function dict(x) { return x; }
My list was a bit too compact perhaps, but the source code explains it all:

/**
* Creates a dictionary object from a list of keys and values. It
* can be used either as a reverse of items(), or as a reverse of
* keys() and values(). That is, either the function take a single
* list where each element contains both key and value, or it takes
* two separate lists, one with keys and the other with values. If
* a key is specified twice, only the last value will be used.
*
* @code dict([['a', 1], ['b', 2]]) --> { a: 1, b: 2 }
* dict(['a','b'], [1, 2]) --> { a: 1, b: 2 }
*
* @param {Array} itemsOrKeys the list of items or keys
* @param {Array} [values] the optional list of values
*
* @return {Object} a dictionary object with all the keys set to the
* corresponding value
*/
MochiKit.Base.dict = function(itemsOrKeys, values) {
var o = {};
if (!MochiKit.Base.isArrayLike(itemsOrKeys)) {
throw new TypeError("First argument must be array-like");
}
if (MochiKit.Base.isArrayLike(values) && itemsOrKeys.length !==
values.length) {
throw new TypeError("Both arrays must be of same length");
}
for (var i = 0; i < itemsOrKeys.length; i++) {
var k = itemsOrKeys[i];
if (k === null || k === undefined) {
throw new TypeError("Key at index " + i + " is null or undefined");
} else if (MochiKit.Base.isArrayLike(k)) {
o[k[0]] = k[1];
} else if (MochiKit.Base.isArrayLike(values)) {
o[k] = values[i];
} else {
o[k] = values;
}
}
return o;
}
Post by Arnar Birgisson
If MK is ever used in a command-line JS interpreter, then environment
would suggest the OS environment variables. I propse platform().
platform() should return an object with keys/values if called with no
arguments, and return a the value of a key otherwise.. i.e.
platform() == {'kind': 'browser', 'name': 'Google Chrome', 'version': ...}
platform('name') == 'Google Chrome'
That's the name I was looking for! Thanks!
Post by Arnar Birgisson
Post by Per Cederberg
But again. If I'm the only one interested in pushing [Widget] forward it
is probably better suited for a separate project.
I think it might. To me, MK is a programmer's utility library. UI
libraries should be kept separate because everyone want's a different
UI. Also, UI libraries are huge cans of worms.
I hear what you are saying. MK already has lots of UI stuff, but only
as a thin wrapper on the HTML DOM. And I don't think adding another
layer has to be very intrusive. Actually, it is the very reason for my
recent interest in making it easier to pack your own MochiKit version
when downloading. I'll probably push my prototype for that onto the
download page any year now.

Cheers,

/Per

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
Arnar Birgisson
2008-11-01 21:18:24 UTC
Permalink
Actually the documentation comments explain it well :)
Post by Per Cederberg
I hear what you are saying. MK already has lots of UI stuff, but only
as a thin wrapper on the HTML DOM. And I don't think adding another
layer has to be very intrusive. Actually, it is the very reason for my
recent interest in making it easier to pack your own MochiKit version
when downloading. I'll probably push my prototype for that onto the
download page any year now.
Right, I can get behind it if the module selection thingie will be set up.

I cannot really disagree with you after you agreed so heartily to all
my comments :D

cheers,
Arnar

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
Eoghan
2008-12-01 14:26:44 UTC
Permalink
Post by Per Cederberg
Arnar: I didn't include the Selector module in the list since it
doesn't change theAPI. But naturally, the updates to Selector will
probably be one of the big features in 1.5.
There will actually be a minorAPIchange, the Selector.Selector
prototype will go away. Maybe we should also expose the Sizzle
prototype instead.
It took me a while to figure this out, but at the moment I can do:

var selector = new MochiKit.Selector.Selector('*');
selector.findElements(myElement, '~');

To find right hand siblings of myElement (which doesn't have an id in
this case)

If this is going away in 1.5, it would be nice to be able to do:

MochiKit.Selector.findRelativeTo(myElement, '~ *');

which (if the element had an id) would be equivalent to the current:

MochiKit.Selector.findDocElements('#myElementId ~ *');

Eoghan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
Arnar Birgisson
2008-12-02 17:19:11 UTC
Permalink
Hi,
Post by Eoghan
Post by Per Cederberg
Arnar: I didn't include the Selector module in the list since it
doesn't change theAPI. But naturally, the updates to Selector will
probably be one of the big features in 1.5.
There will actually be a minorAPIchange, the Selector.Selector
prototype will go away. Maybe we should also expose the Sizzle
prototype instead.
var selector = new MochiKit.Selector.Selector('*');
selector.findElements(myElement, '~');
To find right hand siblings of myElement (which doesn't have an id in
this case)
MochiKit.Selector.findRelativeTo(myElement, '~ *');
MochiKit.Selector.findDocElements('#myElementId ~ *');
Are you using the selector_sizzle branch? Can you try '~ +' with
findChildElements?

cheers,
Arnar

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
Eoghan
2008-12-04 14:01:59 UTC
Permalink
Post by Arnar Birgisson
   var selector = new MochiKit.Selector.Selector('*');
   selector.findElements(myElement, '~');
To find right hand siblings of myElement (which doesn't have an id in
this case)
   MochiKit.Selector.findRelativeTo(myElement, '~ *');
   MochiKit.Selector.findDocElements('#myElementId ~ *');
Are you using the selector_sizzle branch? Can you try '~ +' with
findChildElements?
cheers,
Arnar
I haven't been able to get it to work with the sizzle branch (r1425) —
it fails on Selector.js L352

That version has e.g.
TAG: function(match, context){
return context.getElementsByTagName(match[1]);
}
Which assumes the descendant axis (which is obviously the intention
given the name 'findChildElements').

What I'd like to see from the API would be instead of
'findChildElements', the more general:
findRelatedElements(element, expressions)

If the axis part of the expression was left out it would be equivalent
to the current findChildElements e.g.
findRelatedElements(my_table, ['td.myclass']);

But you could also start an expression with an axis:
findRelatedElements(my_td, ['~ td.myclass']);
To find sibling nodes of a given td.

Eoghan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
Arnar Birgisson
2008-12-04 14:09:21 UTC
Permalink
Hi,
Post by Eoghan
What I'd like to see from the API would be instead of
findRelatedElements(element, expressions)
If the axis part of the expression was left out it would be equivalent
to the current findChildElements e.g.
findRelatedElements(my_table, ['td.myclass']);
findRelatedElements(my_td, ['~ td.myclass']);
To find sibling nodes of a given td.
I think this is a good suggestion for the new Sizzle group, I'd submit
it my self but it is your idea.

http://groups.google.com/group/sizzlejs

cheers,
Arnar

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---

Amit Mendapara
2008-11-03 20:29:02 UTC
Permalink
Post by Per Cederberg
 o unescapeHTML -- [trac] creates a DOM tree from an HTML string
We need a clearer name, perhaps toDOM (being the inverse of toHTML)?
I think, a helper function `makeDOM` in `MochiKit.Query` module would
serve as a base for such implementation. I have taken ideas from
jQuery...
Post by Per Cederberg
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?
I think no, if we can rename those signal names (ajaxStart etc)
accordingly...
Post by Per Cederberg
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.
I don't think that we'd have any compatibility issues. If you compare
them both, you might found that MochiKit.Query tries to imitate jQuery
using MochiKit functions as much as possible and there are room to
remove those jQuery code from the current implementation.

Regards
--
Amit Mendapara
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
Bob Ippolito
2008-11-03 18:29:26 UTC
Permalink
Post by Per Cederberg
Hi everyone,
Development of MochiKit 1.5 is about to start. But before we open the
flood-gates, it might be useful to have a look at a summary of all
proposed API:s. Below you'll find a comprehensive list of all API
additions that I've found (so far).
I'd like to have an onDOMReady event and change addLoadEvent to use
that, basically a subset of the facilities available in YUI:
http://developer.yahoo.com/yui/examples/event/event-timing.html

(haven't made any associated tickets yet)

-bob

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
Amit Mendapara
2008-11-03 19:53:38 UTC
Permalink
Little bit late to this discussion, but I am happy to see discussion
about `Mochichit Extensions` here. I too don't like mixing up two
different JS libraries while my preferred library (MK) is capable
enough to do what the others can. I like the jQuery very much for it's
powerful DOM manipulation and traversing functions but it's not good
enough for other generic usages. That's why, I have started making
something similar to jQuery for MochiKit. If you compare both, you
would found that MochiKit.Query tries to implement most of the DOM
traversing & iterating functions using MochiKit whenever possible and
contains little code from jQuery where it can't (that's why, I have
released ME under the GPL/MIT licences. Though, personally I always
prefer FSF approved licenses).

Regards
--
Amit Mendapara
Post by Per Cederberg
Hi everyone,
Development of MochiKit 1.5 is about to start. But before we open the
flood-gates, it might be useful to have a look at a summary of all
proposed API:s. Below you'll find a comprehensive list of all API
additions that I've found (so far).
# Note 1. I've included everything, regardless of whether the
author/originator actually suggested them for inclusion into MochiKit
or not.
# Note 2. In some cases the source code exists and has been tested.
Not so in others.
# Note 3. Some of these API suggestions might be duplicates of
something already in MochiKit. Or are perhaps better implemented as
improvements to existing functions. Some of them might just be common
usage patterns that either deserve proper documentation or perhaps an
alias function.
So, in summary, please don't get too agitated about individual entries
on the list below. Nothing is set in stone and I'm only looking to
collect statistics, ideas, clarified names, generalizations, random
thoughts and such. See this as my attempt to collect your thoughts and
votes about what you want from MochiKit in the future.
I'm holding off a bit on my own analysis. Will post my comments on
individual suggestions later on.
Cheers,
/Per
[trac] Enhancement suggestions in MochiKit Trac, usually without a
proposed implementation.
   http://trac.mochikit.com/report/3
[me] Patches from the MochiKit Extensions project on LaunchPad
   https://launchpad.net/mochikit-ext
[mp] Patches from the mochikit-patches project on GitHub.
   http://github.com/cederberg/mochikit-patches/tree/master
[other] Random thoughts found elsewhere (don't know where)
MochiKit.Base
  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
  o extendURL -- [trac] merges name and values into a URL query string
  o isFalse -- [mp] check for false, with wide interpretation
  o defaultValue -- [mp] returns first non-undefined value
  o dict -- [mp] merges keys and values to dictionary object
  o select -- [mp] copies listed keys (and values) from an object
  o mask -- [mp] removes listed keys (and values) from an object
  o functionName -- [mp] returns the name of a function
  o registerFunctionNames -- [mp] registers function names
     - should probably be merged into nameFunctions
  o stackTrace -- [mp] returns current execution stack trace
  o injectStackTrace -- [mp] injects stack trace for a function
  o version -- [other] returns an object for browser detection & such
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
  o loadScript -- [trac] loads a JavaScript file
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)
  o toApproxPeriod -- [mp] converts millis to an approximate time period
  o NBSP -- [trac] creates a non-breaking space node
  o unescapeHTML -- [trac] creates a DOM tree from an HTML string
  o selectRange -- [trac] selects text in a text box or field
  o NS.XHTML -- [mp] namespace constant
  o NS.XLINK -- [mp] namespace constant
  o NS.SVG -- [mp] namespace constant
  o NS.XUL -- [mp] namespace constant
  o NS.HTML -- [mp] namespace constant
  o isDOM -- [mp] checks if an object looks like a DOM node
  o isHTML -- [mp] checks if an object looks like an HTML or XHTML DOM node
  o reprDOM -- [mp] creates debug representation of a DOM node
  o attributeArray -- [mp] make existing impl. public
  o childNode -- [mp] returns an immediate child node
  o createDOMExt -- [mp] creates a DOM node with a namespace
  o createTextNode -- [mp] creates a DOM text node
  o createDOMFuncExt -- [mp] returns function for creating DOM nodes
  o blurAll -- [mp] blurs (unfocuses) a DOM node and all relevant children
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
MochiKit.Style
  o setPositionFixed -- [trac] sets fixed position in cross-browser way
  o getContainingBlock -- [trac] returns the containing (layout) parent node
  o getMarginBox -- [trac] returns the margin widths for an HTML DOM node
  o getBorderBox -- [mp] returns the border widths for an HTML DOM node
  o getPaddingBox -- [mp] returns the padding widths for an HTML DOM node
  o getScrollOffset -- [mp] returns the scroll offset for an HTML DOM node
  o setScrollOffset -- [mp] sets the scroll offset for an HTML DOM node
  o resetScrollOffset -- [mp] resets the scroll offsets to zero
  o adjustScrollOffset -- [mp] ensures optimal visibility for a box
  o registerSizeConstraints -- [mp] registers algebraic constraints for an
      element width, height and aspect ratio
  o resizeElements -- [mp] resizes DOM nodes using parent sizes and registered
      constraints
MochiKit.Signal
  o connectEventMap -- [trac] connect signals through a declarative map
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
MochiKit.Test -- publish & improve existing module [trac]
MochiKit.Cookie -- new module in [trac]
  o getCookie -- [trac] retrieves an HTTP cookie value
  o setCookie -- [trac] sets an HTTP cookie value
MochiKit.Queue, Stack and AsyncQueue -- new modules in [trac]
  -- these are suggested data structures, should perhaps be placed in
a Data module or similar.
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
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
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.
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
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
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "MochiKit" group.
To post to this group, send email to ***@googlegroups.com
To unsubscribe from this group, send email to mochikit+***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/mochikit?hl=en
-~----------~----~----~----~------~----~------~--~---
Loading...