[mochikit] Re: Suggested API:s for MochiKit 1.5
On Fri, Oct 31, 2008 at 1:15 AM, Arnar Birgisson [EMAIL PROTECTED] wrote:
To draw from Python again, both could be implemented with one function
called bool. This would convert any object to a boolean.
Nice idea!
How about a generic first function in Iter? Would be
first(someCheck, iterable[, defaultValue=undefined])
This too!
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;
}
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!
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 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
-~--~~~~--~~--~--~---
[mochikit] Re: Ticket #325 follow-up
Oups, sorry.
What I meant is that W3C provides a sample HTML4 stylesheet that, even
though not autoritative, may be a useful guideline to complete the
_defaultDisplay dictionary introduced in changeset 1449.
2008/10/31 Yoann Aubineau [EMAIL PROTECTED]:
http://www.w3.org/TR/CSS21/sample.html
head { display: none }
dir, hr, menu, pre { display: block }
li { display: list-item }
table { display: table }
tr { display: table-row }
td, th { display: table-cell }
thead { display: table-header-group }
tbody { display: table-row-group }
tfoot { display: table-footer-group }
colgroup { display: table-column-group }
col{ display: table-column }
caption{ display: table-caption }
input, select { display: inline-block }
2008/10/25 Yoann Aubineau [EMAIL PROTECTED]:
And the associated test coverage.
Note that the test doesn't fail when display:none is applied inline,
at least in Safari 3.1. But it does when the property is set from a
style block.
PS: Thanks for who attached those files to the ticket in Trac.
2008/10/25 Yoann Aubineau [EMAIL PROTECTED]:
As Mochikit's Trac doesn't allow new registration for the moment, I
can't attach new files or add comments to the ticket I've just opened.
Here they are :
- test.html : an HTML showing the problem in action
- patch : a proposed patch
Test coverage is coming up.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[mochikit] Re: Ticket #325 follow-up
Ok, thanks! I was a bit sloppy in my first implementation, but in
r1453 I added all the display styles below. Some of them might break
in IE6 and so, but it is still better than being broken all the time
(as you pointed out).
Thanks for reviewing the code!
Cheers,
/Per
On Fri, Oct 31, 2008 at 7:15 PM, Yoann Aubineau
[EMAIL PROTECTED] wrote:
Oups, sorry.
What I meant is that W3C provides a sample HTML4 stylesheet that, even
though not autoritative, may be a useful guideline to complete the
_defaultDisplay dictionary introduced in changeset 1449.
2008/10/31 Yoann Aubineau [EMAIL PROTECTED]:
http://www.w3.org/TR/CSS21/sample.html
head { display: none }
dir, hr, menu, pre { display: block }
li { display: list-item }
table { display: table }
tr { display: table-row }
td, th { display: table-cell }
thead { display: table-header-group }
tbody { display: table-row-group }
tfoot { display: table-footer-group }
colgroup { display: table-column-group }
col{ display: table-column }
caption{ display: table-caption }
input, select { display: inline-block }
2008/10/25 Yoann Aubineau [EMAIL PROTECTED]:
And the associated test coverage.
Note that the test doesn't fail when display:none is applied inline,
at least in Safari 3.1. But it does when the property is set from a
style block.
PS: Thanks for who attached those files to the ticket in Trac.
2008/10/25 Yoann Aubineau [EMAIL PROTECTED]:
As Mochikit's Trac doesn't allow new registration for the moment, I
can't attach new files or add comments to the ticket I've just opened.
Here they are :
- test.html : an HTML showing the problem in action
- patch : a proposed patch
Test coverage is coming up.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
