Re: [mochikit] Is MochiKit Dead?
Agreed. Nowadays I'm also in maintenance-only-mode with respect to MochiKit. Meaning that I'll only address critical bugs or merge well-documented tested patches. The MochiKit.Text module and version 1.5 won't progress further unless someone else steps up to do the work. That said, I'm still using MochiKit where it makes sense. Preferably in conjunction with jQuery. Would be nice to eventually package up MochiKit into separate pieces that glue better into jQuery in some ways. But the custom packaging solution we have right now also allows to strip out some obvious duplicated stuff... Cheers, /Per On Sat, Aug 13, 2011 at 20:45, Bob Ippolito b...@redivi.com wrote: On Sat, Aug 13, 2011 at 11:35 AM, machineghost machinegh...@gmail.com wrote: So, given that: * There hasn't been a blog post on the website in ... ever (according to the front of the site; in reality there was a post back in 2008) * There hasn't been a release since 2008 * This mailing list gets a post (with no response) once every other month or so, if that * MochiKit is less popular than random frameworks I've never heard of (xajax? what's that?) by a factor of six (http://www.readwriteweb.com/ hack/2011/08/javascript-framework-popularit.php) it really seems like MochiKit is a dead project, or at best a zombie project. Is that accurate? I mean, obviously people currently using it aren't going to stop, but is new development, promotion of the framework, improvement of the website/docs/etc. dead? Zombie sounds about accurate to me, we still use it but it's done what we've needed it to do for quite a few years so we haven't bothered to make any changes to it. We don't have a lot of incentive to encourage other people to use it, especially at this point. If someone is interested in making improvements they're more than welcome to do so, it's all pretty much github based these days so accepting pull requests, adding contributors and updating the site is very easy. -bob -- 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 mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en. -- 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 mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Re: MochiKit.I18n -- proposed new module for internationalization
Once again, the jQuery-route seems to be the way to go. I'll abandon my dev branch for now. Cheers, /Per On Wed, Jan 12, 2011 at 00:59, Fredrik Blomqvist fblomqv...@gmail.com wrote: FYI. Before I noticed this thread I and Per exchanged couple of ideas @github. https://github.com/cederberg/mochikit/commit/4b69ff89ae1cd2ce6b2380933c10d52f57454a39#comments Summary: both Per and I have had a look at Google Closure i18n module. comprehensive coverage. An upcoming (Microsoft sponsored) jQuery-glob lib also seems very promising, better calendar support for example. It's available in a non jQuery version here (nice move!): https://github.com/nje/jquery-glob/blob/master/globalization.js Perhaps simply add a thin wrapper (using Per's interface) for MochiKit? // Fredrik On Jan 11, 2:56 pm, Bob Ippolito b...@redivi.com wrote: This is pretty cool, something I always imagined that I might do if I were doing this kind of localization. We've only done en and zh at Mochi, so haven't needed anything outside of the system format. On Mon, Jan 10, 2011 at 6:38 PM, Per Cederberg cederb...@gmail.com wrote: Since I found the MochiKit.Format.formatLocale() function too limited, I hacked up a new MochiKit.I18n module: https://github.com/cederberg/mochikit/blob/i18n/MochiKit/I18n.js It is backwards compatible and adds locales for most languages on earth (data derived from Wikipedia and Google Closure sources). At the moment it only contains numeric formatting information, but can be extended with currency and datetime formatting information if needed. My intention is to include this in the default MochiKit 1.4 tree and update the MochiKit.Text module to properly support the number formatting specified in these locales (some are not currently supported). Please let me know if you have any issues with this. Cheers, /Per PS. Pasting in the source rst docs below to give a clue as to how it is supposed to work. Name MochiKit.I18n - internationalization, localization and globalization Synopsis :: assert( locale().decimal == . ); assert( locale(sv_SE).decimal == , ); Description === This module contains numeric localization information for most languages and regions on earth. Actual text formatting lives in other modules (such as :mochiref:`MochiKit.Text`). Dependencies - :mochiref:`MochiKit.Base` Overview Locale Names MochiKit uses IETF language codes [1] to identify a locale, e.g. ``en_US``. The locale database also supports the use of previously unknown locale identifiers by creating a new locale based on the language code or the default locale. A number of built-in locale identifiers are also supported: +-+-+ | Language | Description | +=+=+ | ``system`` | The built-in system locale. It is identical to a | | | ``en_US`` locale for backward compatibility. | +-+-+ | ``user`` | The user locale, as reported by the browser. This | | | points to a specific language locale (or the | | | ``system`` locale.) | +-+-+ | ``default`` | The default locale, used when no language code is | | | provided. This points to the ``system`` locale by | | | default. | +-+-+ The default locale is modified by accessing the ``MochiKit.I18n.LOCALE`` cache of resolved locale objects: :: MochiKit.I18n.LOCALE[default] = locale(user); Locale Objects -- The locale objects returned by :mochiref:`locale()` and stored in the ``MochiKit.I18n.LOCALE`` cache all have the following properties (some inherited through the prototype chain): +-+-+ | Name | Description | +=+=+ | ``decimal`` | The decimal dot character. | +-+-+ | ``separator`` | The thousands grouping character. | +-+-+ | ``separatorGroups`` | The size of thousands groups (from | | | right to left). Repeats when exhausted
[mochikit] MochiKit.I18n -- proposed new module for internationalization
Since I found the MochiKit.Format.formatLocale() function too limited, I hacked up a new MochiKit.I18n module: https://github.com/cederberg/mochikit/blob/i18n/MochiKit/I18n.js It is backwards compatible and adds locales for most languages on earth (data derived from Wikipedia and Google Closure sources). At the moment it only contains numeric formatting information, but can be extended with currency and datetime formatting information if needed. My intention is to include this in the default MochiKit 1.4 tree and update the MochiKit.Text module to properly support the number formatting specified in these locales (some are not currently supported). Please let me know if you have any issues with this. Cheers, /Per PS. Pasting in the source rst docs below to give a clue as to how it is supposed to work. Name MochiKit.I18n - internationalization, localization and globalization Synopsis :: assert( locale().decimal == . ); assert( locale(sv_SE).decimal == , ); Description === This module contains numeric localization information for most languages and regions on earth. Actual text formatting lives in other modules (such as :mochiref:`MochiKit.Text`). Dependencies - :mochiref:`MochiKit.Base` Overview Locale Names MochiKit uses IETF language codes [1] to identify a locale, e.g. ``en_US``. The locale database also supports the use of previously unknown locale identifiers by creating a new locale based on the language code or the default locale. A number of built-in locale identifiers are also supported: +-+-+ | Language| Description | +=+=+ | ``system`` | The built-in system locale. It is identical to a| | | ``en_US`` locale for backward compatibility. | +-+-+ | ``user``| The user locale, as reported by the browser. This | | | points to a specific language locale (or the| | | ``system`` locale.) | +-+-+ | ``default`` | The default locale, used when no language code is | | | provided. This points to the ``system`` locale by | | | default.| +-+-+ The default locale is modified by accessing the ``MochiKit.I18n.LOCALE`` cache of resolved locale objects: :: MochiKit.I18n.LOCALE[default] = locale(user); Locale Objects -- The locale objects returned by :mochiref:`locale()` and stored in the ``MochiKit.I18n.LOCALE`` cache all have the following properties (some inherited through the prototype chain): +-+-+ | Name| Description | +=+=+ | ``decimal`` | The decimal dot character. | +-+-+ | ``separator`` | The thousands grouping character. | +-+-+ | ``separatorGroups`` | The size of thousands groups (from | | | right to left). Repeats when exhausted. | +-+-+ | ``percent`` | The percent character. | +-+-+ | ``permille``| The permille character. | +-+-+ | ``plus``| The plus sign character.| +-+-+ | ``minus`` | The minus sign character. | +-+-+ | ``signAtEnd`` | The boolean sign at end of string flag. | +-+-+ | ``infinity``| The infinity character. | +-+-+ API Reference = Functions - :mochidef:`locale(spec=default)`: Returns the locale object corresponding to ``spec``. The locale object returned contains formatting and localization information that is used when displaying data in non-English languages (see description above for details). Note that the cached locale database entry is
[mochikit] typeName() function -- introspecting object types
Being tired of all the idiosyncrasies of the typeof() operator, I
tried to make something better:
function typeName(value) {
if (typeof(value) !== object !(value instanceof RegExp)) {
return typeof(value);
} else if (value == null) {
return null;
} else {
var c = value.constructor || {};
return c.name || c.NAME || Object;
}
}
See here:
https://github.com/cederberg/mochikit/commit/582a51531f68a17aa0ddea41df5957cd09424a25
I was thinking about including this in MochiKit.Base, possibly
modifying typeMatcher() on the go. That would break backward
compatibility a bit, so the question is if it would be worthwhile?
This is how typeName() works right now:
undefined == undefined
null == null
false == boolean
new Boolean(true) == Boolean
42 == number
new Number(42) == Number [1]
test == string
new String() == String [1]
{ a: 1 } == Object [2]
[1,2,3] == Array
new Date() == Date
/\d+/ == RegExp
new MyClass() == MyClass [3]
Notes:
[1]: There are two forms of these built-in types, but normally the
constructor form is not used much.
[2]: These objects constructor actually point to the Object function,
hence the upper-case initial.
[3]: For this to work, the constructor property must be set and the
constructor function must have either a name or a NAME property.
Cheers,
/Per
--
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochi...@googlegroups.com.
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Mochikit.signal and DOM objects that don't exist yet (like jQuery.live)
Thanks for your input to the project, but I don't think we can
consider this a bug. Referring to objects that do not yet exist is an
error in almost any programming language, so it is to be expected. The
MochiKit docs do not explicitly make it clear that the id lookup is
immediate, but they definitely do not discuss any lazy or delayed
lookup of the signal source. The documentation is explicit regarding
that the destination slot will be looked up on the first signal,
though.
In your case, why wouldn't you just attach the signal when creating
the element? Otherwise you'd have to listen to any DOM modification
and possibly attach signals to elements added. And that use case
sounds pretty specific to me.
BTW. If you'd like to contribute patches to the MochiKit project, it
would be much easier if you forked the project on GitHub I think. The
move happened quite recently, so I haven't moved all my own patches
yet, but by forking on GitHub it becomes much easier for us
maintainers to pick up patches and ideas.
Cheers,
/Per
On Fri, Dec 3, 2010 at 16:37, ryanwil...@gmail.com ryanwil...@gmail.com wrote:
Hi all,
I was playing around with MochiKit.Signal, specifically asking the
question: Can I use MochiKit.Signal.connect to set event handlers for
objects that don't exist yet.
Like so:
// connect to our make a new button button
MochiKit.Signal.connect(button_that_exists, 'onclick',
function(evt ) {
var new_button = MochiKit.DOM.BUTTON({'id':
newly_created_button}, Hello world, I'm new);
MochiKit.DOM.appendChildNodes( MochiKit.DOM.getElement(main_content_div),
new_button );
});
MochiKit.Signal.connect(newly_created_button, 'onclick',
function(evt) {
alert(hey world);
});
NOTE that newly_created_button won't exist until the user clicks the
button_that_exists.
When I try this I get an error in MochiKit.Signal, about src being
null.
Is this a bug (MochiKit.Signal should allow connecting to DOM objects
that don't exist yet), or a limitation of how MochiKit.Signal was
designed (MochiKit.Signal.connect supports only objects that live on
the DOM when it is called)?
I do see that MochiKit.Signal.signal DOES seem to support the src
object being a string, so I suspect the former answer.
If it is the former answer (if this error is a bug) I can try to put
together a patch to try and allow this behavior, BUT I wanted to check
before I went down this road.
To see my full example, I've pushed it up to Bitbucket (as part of a
learning repository, so there's a lot of extra stuff in there :( ):
http://bitbucket.org/rwilcox/learning_javascript/src/tip/MochiKit/
signals_and_slots/
--
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochi...@googlegroups.com.
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en.
--
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochi...@googlegroups.com.
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Does the BSD license need to be mentioned?
Thanks for your feedback! I've updated the license text in the MochiKit repository with your patch: http://github.com/mochi/mochikit/commit/60ac9815cb6a4d63a90936777ea7dc836caf7e94 We'll use the updated license for the 1.5 release (whenever that'll be), but there are no current plans for patching the 1.4.x release further (unless critical bugs are discovered). Feel free to apply you patch to the version packaged in Fedora. Cheers, /Per On Fri, Dec 3, 2010 at 21:45, Toshio Kuratomi a.bad...@gmail.com wrote: Greetings, I was working on MochiKit for Fedora and someone pointed out this bit of licensing: https://github.com/mochi/mochikit/blob/master/MochiKit/Style.js#L165 /* * getElementPosition is adapted from YAHOO.util.Dom.getXY v0.9.0. * Copyright: Copyright (c) 2006, Yahoo! Inc. All rights reserved. * License: BSD, http://developer.yahoo.net/yui/license.txt * */ BSD is compatible with MIT (I haven't checked AFL but we can package under BSD-MIT only if that's an issue) so the issue that was pointed out isn't license compatibility. It's being sure that we comply with the terms of the License. The license text from the yahoo URL says: * Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. * Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. I think that means that LICENSE.txt needs to include the Yahoo BSD license and copyright terms for that function. I'm not sure if the license information should also be included verbatim in the Style.js file. I'll attach a patch to modify LICENSE.txt. -Toshio -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
[mochikit] Introspecting object types
Being tired of all the idiosyncrasies of the typeof() operator, I
tried to make something better:
function typeName(value) {
if (typeof(value) !== object !(value instanceof RegExp)) {
return typeof(value);
} else if (value == null) {
return null;
} else {
var c = value.constructor || {};
return c.name || c.NAME || Object;
}
}
Thinking about including this in MochiKit.Base, possibly modifying
typeMatcher() on the go. That would break backward compatibility a
bit, so the question is if it would be worthwhile?
This is how typeName() works right now:
undefined
== undefined
null
== null
false
== boolean
new Boolean(true)
== Boolean
42
== number
new Number(42)
== Number [1]
test
== string
new String()
== String [1]
{ a: 1 }
== Object [2]
[1,2,3]
== Array
new Date()
== Date
/\d+/
== RegExp
new MyClass()
== MyClass [3]
Notes:
[1]: There are two forms of these built-in types, but normally the
constructor form is not used much.
[2]: These objects constructor actually point to the Object function,
hence the upper-case initial.
[3]: For this to work, the constructor property must be set and the
constructor function must have either a name or a NAME property.
Cheers,
/Per
--
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochi...@googlegroups.com.
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en.
[mochikit] Possible bug in MochiKit.Base.compare
While writing some MochiKit tests, I stumbled upon the following:
# compare(, [])
== 0
# == []
== true
Seems like the JavaScript type coercion is used inside compare():
compare: function (a, b) {
if (a == b) {
return 0;
}
...
But perhaps that was just a mistake? It seems to be at odds with the
idea of a safe compare function... If nobody is terribly dependent
on this I'll fix it for 1.5. But please verify this if you are
extensive users of compare().
Cheers,
/Per
--
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochi...@googlegroups.com.
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en.
[mochikit] Code comments in MochiKit sources
Does anyone (Bob?) know why the MochiKit source code has these types of comments for most exported functions: /** @id MochiKit.Signal.connect */ Cheers, /Per -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] MochiKit moving to github
The download customization is now working. You can reach it here (also linked from the new web site): http://mochi.github.com/mochikit/packed/MochiKit/customize.html Regarding tickets, if you are a stakeholder, please look through the list and re-submit the ones you still think applies in the new GitHub issue tracker. I've fixed a few today and will probably celebrate the GitHub migration by pushing in a few others tomorrow. https://trac.mochikit.com/report/3 -- current issues http://github.com/mochi/mochikit/issues -- new issues Also, if you have code fixes, feel free to perform a proper fork pull-request via GitHub. Will make it easier to import any code changes verbatim. Cheers, /Per On Mon, Oct 11, 2010 at 06:04, Bob Ippolito b...@redivi.com wrote: I'm in the process of moving MochiKit to github to remove the maintenance burden from the Mochi ops team, and make it easier to contribute. We're in the process of switching everything to git internally anyway, so it's about time: http://github.com/mochi/mochikit I think that we'll just go ahead and use github pages for the site once the transition is complete. I have most of it set up here (the customize functionality still uses SVN): http://mochi.github.com/mochikit We haven't migrated anything in Trac yet. I'm not sure how much of it is really useful these days. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Re: SpiderMonkey and MockDOM Issues
When svn.mochikit.com is back up you can easily create your own
packaged version without any of the DOM packages. Don't know if any of
the magic initialization code in MochiKit uses the navigator, window
or document objects, but I guess they should detect if they are
missing. Otherwise we have a bug that should be fixed.
Let us know how it goes with a more minimal version of MochiKit,
preferably customized from the special download site.
Cheers,
/Per
On Thu, Oct 7, 2010 at 15:21, Kaleb Hornsby theka...@gmail.com wrote:
Since MochiKit makes JavaScript a more robust programming language, I
am trying to use both to do some server side programming. That's why
MochiKit provides a MockDOM. I think that overall, it should not be
coupled to the DOM at all.
On Oct 7, 7:54 am, Bob Ippolito b...@redivi.com wrote:
No idea what you're trying to do but it sounds like whoever packaged
this with Ubuntu did the wrong thing.
Surely there must be an up to date mirror of mochikit on github or
something that can be used until service is restored.
On Thu, Oct 7, 2010 at 1:25 AM, Kaleb Hornsby theka...@gmail.com wrote:
I am running Ubuntu and have just discovered MochiKit in the
repositories. I attempted to start it with smjs, but I ran into an
error. I apparently needed MochiKit.MockDOM. I found it [online] [1]
on another site than mochikit's because their track server is down.
This seemed rather old. Sure enough, though, I loaded mockdom.js and
then loaded mochikit.js and it solved the error, but created another.
Sample output:
$ js
js load('MochiKit.js')
MochiKit.js:3506: TypeError: this._document has no properties
js load('MockDOM.js')
js load('MochiKit.js')
MochiKit.js:4323: ReferenceError: navigator is not defined
js
Does somebody have a more recent version of mockdom that works with
mochikit?
[1]:http://bknr.net/trac/browser/trunk/projects/quickhoney/website/static...
--
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochi...@googlegroups.com.
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/mochikit?hl=en.
--
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochi...@googlegroups.com.
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en.
--
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochi...@googlegroups.com.
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Future plans/timeline for Mochikit?
No, there is no timeline. I planned a 1.4.3 bugfix release, but haven't noted any particular interest for it. Seems most people (like me) just use the svn trunk version right now. On the topic of version 1.5, it seems work on it has mostly paused. Some additions are included, but my own time for MochiKit work has been cut down to next-to-nothing for about a year now. And no end in sight. There are a bunch of additions floating around here and there, but most need some polishing in the form of tests documentation in order to be properly included. Cheers, /Per On Thu, Mar 11, 2010 at 10:18, Masklinn maskl...@gmail.com wrote: I only recently discovered that, as opposed to what the website itself let believe (release feed, official blog, and even Bob's blog), MochiKit was not unmaintained since November 2008, and that there was in fact quite a bit of activity on 1.4.3 and 1.5 branches, and even a sizzle/selectors branch. So my question is, is there any timeline for the 1.4.3 release, and further down the line for 1.5? -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Providing patch for ticket #361
Thanks for the patches, Niek! They've now been applied to svn trunk. Cheers, /Per On Fri, Feb 19, 2010 at 09:32, Niek Kouwenberg niek.kouwenb...@gmail.com wrote: Okay, Attached you'll find 361.patch for bug #361. I also added a patch for bug #246, which was fairly simple. On Thu, Feb 18, 2010 at 5:37 PM, Bob Ippolito b...@redivi.com wrote: You can send it here to the list On Thu, Feb 18, 2010 at 3:18 AM, niek.kouwenb...@gmail.com niek.kouwenb...@gmail.com wrote: Hi, I've just created a ticket for which I have a patch. Since editing and replying to tickets seems to be disabled since 2008, I have no way of attaching this patch. Since I've been using MochiKit quite some time now in several projects, I am keen on helping a little with development (which seems rather slow). Not being able to provide patches or comment to tickets seems to make this really hard and might kill MochiKit future. Where do I send my patch? -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Patch for ticket #329
I think the proper type check would be better written as o instanceof Array. Also, previously we've been very cautious with breaking backwards compatibility. The existing code supports JSON-serialization of array-like structures, something that wouldn't be supported by the new code. Perhaps we could just recommended native JSON.stringify() for most cases: https://developer.mozilla.org/En/Using_native_JSON So, the question is if we should switch to strict JSON in the serializeJSON() method? Or just deprecate our version now that all major browers support JSON.stringify(). Any opinions on the list? Cheers, /Per On Mon, Feb 22, 2010 at 14:00, Niek Kouwenberg niek.kouwenb...@gmail.com wrote: MochiKit.Base.serializeJSON fails for objects with a 'length' property This method used an 'is array like'-like check, instead of a strict 'is array' check. The provided patch replaces the if-statement with the isArray checks as implemented in Prototype.js and jQuery. This does not break existing functionality, but prevents the errors for objects with a lenght property. These are now correctly added to the JSON string as objects. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
Re: [mochikit] Re: Packing on the function level
Don't want to send stop-energy around, but is it really worthwhile to pack MochiKit like that? I mean, the full MochiKit.js is only 197,5 kB uncompressed. And the customizer we already have lets you pick quite freely on the module level. Have you double-checked what type of performance increases you'll see in you load times if packing a smaller JS file? Perhaps just gzipping the file will give you a similar speedup? Cheers, /Per On Wed, Feb 10, 2010 at 16:57, Eoghan eoghanomur...@gmail.com wrote: Thanks Fredrik, that's exactly what I'm looking for.. No luck compiling a packed version of MochiKit (1.5) and trying to connect a signal - I get an error MochiKit.i is undefined. The closure inspector isn't working for me (FireBug 1.5.0) so I'm afraid I can't further investigate at this time :-( On Feb 9, 5:55 pm, Fredrik fblomqv...@gmail.com wrote: This should be possible using the Google Closure compiler:http://code.google.com/closure/compiler/ (Some issues to watch out for:http://code.google.com/closure/compiler/docs/api-tutorial3.html#dangers) I hope to find time to try this myself also, please report back about your progress! Would be nice if MochiKit can be verified to be compilable using Closure. Regards // Fredrik On Feb 9, 6:25 pm, Eoghan eoghanomur...@gmail.com wrote: Has anyone made an attempt to pack up MochiKit omitting functions that are not used? e.g. include DateTime.toISODate but not DateTime.toPaddedAmericanDate if the latter doesn't happen to be called in a given file. I realise this would be non trivial to do automatically.. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en. -- You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochi...@googlegroups.com. To unsubscribe from this group, send email to mochikit+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mochikit?hl=en.
[mochikit] JSON.parse MochiKit.Base.evalJSON
I just tried to modify MochiKit.Base.evalJSON() to use the new
JSON.parse() function when available. This would give us the following
advantages:
1. Speed (but, well... eval() is probably fast enough already)
2. Security
Unfortunately we would also get a nasty regression issue due to the
stricter syntax enforcement in JSON.parse() vs. eval(). It seems that
at least the Firefox parser doesn't accept constructs like these:
{ a: 1 }
since the correct JSON syntax would be:
{ a: 1 }
Hmm... So what to do? Just skip this altogether? And add a note in the
docs that people should use JSON.parse() themselves if worried about
security or speed?
Any thoughts are welcome.
Cheers,
/Per
--
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochi...@googlegroups.com.
To unsubscribe from this group, send email to
mochikit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en.
[mochikit] Re: MochiKit.DOM.getElementsByTagAndClassName performance
Generally, I think some of these optimizations make sense. Like using === instead of == in code like this: typeof(x) === string But I think the optimizations where variables are moved outside code blocks and where array lengths are stored to variables should be used with extreme caution. These are the type of things that people used to recommend for Java code, but nowadays the virtual machines optimize these things better by themselves. And what used to be a speedup actually often leads to decreased performance. For JavaScript, the VM:s are much more immature. But they are rapidly becoming faster and more advanced. So low-level code optimizations that result in a speedup today, might not do so just a year or two down the road. I think our focus here should be on clarity of intention. If some critical-path function is extremely slow, we might want to have a look at optimizing that specific function. But in general I think we should refrain from low-level code optimizations that doesn't also improve code readabilty and reduce the frequency of bugs. Also, if speed is a problem, most serious speedups come from changes to the algorithms and data structures involved. In this case for instance, it might be faster to first find elements by class and then filter out the ones with the correct tag. Or by using an indexOf(class) on the className field before splitting it up. These kind of optimizations will probably result in higher gains with less reduction to the code readability. Just my 2 cents. Cheers, /Per On Tue, Nov 3, 2009 at 23:23, takashi mizohata bea...@gmail.com wrote: Hi All, Forgive me, if this is a recurring argument. Today I was looking at Firebug profiler and I realize that getElementsByTagAndClassName takes certain percentages of processing time. And I took a look at the code, and I did a little bit of hand optimization. It doesn't change any semantics of code, but just organizing code. It does pass the tests of course. And i got around 6% better performance. Well the down side of this tweak may be the decrease of readability. Since you need to carefully type comma between local variables. I usually check it with jslint before commit in order to find those potential mistakes. And obviously I don't much about coding convention of MochiKit and I might need to edit the style of it. Here I attached .patch file for this issue. Please try it and let me know what you think. if somebody's interested in, I can contribute some more performance tweaks in MochiKit. Thanks, -- Takashi M --~--~-~--~~~---~--~~ 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 mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Ticket #352: Adding MochiKit.DateTime.toISOTime arguments to the API
In ticket #352 the realISO parameter in the MochiKit.DateTime.toISOTime() function is discussed: http://trac.mochikit.com/ticket/352 It was introduced by Bob in r377 (some 4 years ago), but never added to the documentation or the official API: http://trac.mochikit.com/changeset/377 Is it time that we now add it? Or is it just one of those hacks that we should just hide away? Opinons? 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 mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Defered.setFinal
Slow response here, but I finally got around to committing this to
Subversion (r1533):
http://trac.mochikit.com/changeset/1533
Modified the patch a bit further to account for some additional cases.
Also added tests and documentation.
@Bob: Can you please review this change? I have the feeling that I've
still missed one or two corner cases... Also, the mochikit.com and
trac.mochikit.com site seems slow from here... High server load
recently?
@Amit: Please check that my additional controls doesn't break you use case.
Cheers,
/Per
On Wed, Feb 11, 2009 at 14:52, Amit Mendaparamendapara.a...@gmail.com wrote:
Even better...
if (this.chain.length == 0 this._finalizer) {
this._finalized = this._finalizer(res);
}
This will allow us to finalize the deferred based on some
conditions...
- Amit
On Feb 11, 12:52 am, Per Cederberg cederb...@gmail.com wrote:
You mean like this?
setFinalizer: function(cb) {
this._finalizer = cb;
}
...
if (this.chain.length == 0 this._finalizer) {
this.finalized = true;
if (res instanceof Error) {
this._finalizer(res);
}
}
Would that be acceptable to Amit as well? In that case we would add a
default error handler (called a finalizer), which would also be what
I'm planning to use this for.
Other opinions?
/Per
On Tue, Feb 10, 2009 at 5:48 PM, Bob Ippolito b...@redivi.com wrote:
Finalizing a Deferred should ensure that no further callback/errbacks
are registered and it should attach a default error handler (success
should be no-op). The most common problem I've seen with Deferreds is
that an error occurs but nobody attached an error handler that far
down the stack. In Python they work around this by having a finalizer
so that you see the error when the object gets GC'ed, but that's not
really possible in JS since you don't have finalizers or weak
references.
On Tue, Feb 10, 2009 at 8:04 AM, Per Cederberg cederb...@gmail.com wrote:
I think this is a good idea. I needed something similar too, so I
ended up writing an ugly hack that worked most of the time...
d.addBoth(function (res) {d.addBoth(finalFunc); return res; });
It adds new callback once the first deferred result drops in,
hopefully after all the other callbacks have been added...
But a more formally correct solution would probably be a good idea.
Cheers,
/Per
On Tue, Feb 10, 2009 at 2:30 PM, Amit Mendapara
mendapara.a...@gmail.com wrote:
Hi Per,
I have just started again improving the MochiKit Extensions. While
creating tests for the Ajax module, I found one problem (not bug, but
specific to the feature I'm trying to implement). I registered a
callback which should be fired at the end of all registered callbacks.
I achieved by modifying Async.js with a new method `setFinal` (not
addFinal as there should be only one finalizer) which gets fired when
`chain.length == 0`. It's simple. I would we happy if you add one such
function in MochiKit.Async.Defered...
Regards
--
Amit
--~--~-~--~~~---~--~~
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Base.js unescape reassignment and intrusion protection systems
The reassignment is for backwards compability if I understand it correctly:
if (typeof(decodeURIComponent) != undefined) {
decode = decodeURIComponent;
} else {
decode = unescape;
}
From the JavaScript 1.5 guide at Mozilla:
The escape and unescape functions do not work properly for non-ASCII
characters and have been deprecated. In JavaScript 1.5 and later, use
encodeURI, decodeURI, encodeURIComponent, and decodeURIComponent.
https://developer.mozilla.org/En/Core_JavaScript_1.5_Guide/Predefined_Functions/Escape_and_unescape_Functions
I don't see any good alternative solutions here. Perhaps the IDS
should be forced to allow a few exceptions?
Cheers,
/Per
On Fri, Jul 17, 2009 at 03:34, Michaelmstras...@gmail.com wrote:
I have found a problem with MochiKit Base.js and the intrusion
protection system at work. The IPS truncates Base.js because it
assigns the unescape() function to a variable (in parseQueryString(),
line 1225 in version 1.4.2 of Base.js). The IPS response is documented
here:
http://www.iss.net/security_center/reference/vuln/JavaScript_Unescape_Obfuscation.htm
Has anybody else seen this behaviour? Could the code be re-written to
not use that reassignment?
(I discovered this because MarkMail does not work, and it uses a
compressed version of MochiKit 1.4.)
--~--~-~--~~~---~--~~
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Error running tests with Opera 10
This is the type of stuff one would rather not add to work-arounds in the JavaScript code. Don't understand why Opera can't add stacktraces as separate properties to their exception objects instead? Or is it just that they've modified the toString() implementation? Cheers, /Per On Sat, Jul 11, 2009 at 18:57, Giulio Cesare Solaroligiulio.ces...@gmail.com wrote: Hello, I was having some issues running Clipperz test suite with Opera 10. Looking closer at the failed tests, I have find out that Opera 10 is returning a messed up name and description for Exceptions. This problem is triggered also running the default MochiKit tests; in MochiKit.Async test actually. The test expects an error with message foo (test_MochiKit-Async.html, line 300; trunk version 1525), but the actual value is foo\r\nstacktrace: n/a; see opera:config#UserPrefs|Exceptions Have Stacktrace. Opera 10 is appending some extra values to the exception message, screwing up the test; in my case, it alters the behaviour of the whole application, as some execution paths are based on the value of the returned error name. Any idea on how to fix this problem? or just report it to Opera so that they can fix it for the next release? Regards, Giulio Cesare --~--~-~--~~~---~--~~ 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 mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: bind() / memory leak?
Mostly, these issues are caused by lingering references to the removed
DOM nodes (lookup tables, etc). In this case, since you use MochiKit,
you might want to look at the MochKit.Signal.disconnectAll().
It might also be helpful for some older browsers to tear down the DOM tree.
Here's a helper function that I've used to achieve these two aims:
/**
* Destroys a widget or a DOM node. This function will remove the DOM
* node from the tree, disconnect all signals and call all widget
* destructor functions. The same procedure will also be applied
* recursively to all child nodes. Once destroyed, all references to
* the widget object should be cleared in order for the browser to
* be able to reclaim the memory used.
*
* @param {Widget/Node/Array} node the (widget) DOM node or list
*
* @static
*/
MochiKit.Widget.destroyWidget = function (node) {
if (node.nodeType != null) {
if (typeof(node.destroy) == function) {
node.destroy();
}
if (node.parentNode != null) {
MochiKit.DOM.removeElement(node);
}
MochiKit.Signal.disconnectAll(node);
while (node.firstChild != null) {
MochiKit.Widget.destroyWidget(node.firstChild);
}
} else if (MochiKit.Base.isArrayLike(node)) {
for (var i = node.length - 1; i = 0; i--) {
MochiKit.Widget.destroyWidget(node[i]);
}
}
}
Cheers,
/Per
On Fri, Jun 19, 2009 at 17:34, Kevin Kaiser kevins...@gmail.com wrote:
I've built a rather complicated web app that makes heavy use of
MochiKit.Base.bind() and partial(). There are no page refreshes in the
app and the majority of the page content between areas of the UI is
dynamically created / removed via DOM methods. A user might spend
considerable time inside the app and it leaks memory like I've never
seen.
I suspect it has a lot to do with the fact that the majority of the
data in browser memory is inside of a single, potentially-large
object / data structure, and most bind() or partial() calls pass along
this object as a parameter, which ends up set as the im_self attribute
on the resulting bound function.
A lot of my bound functions end up set as event handlers and things
like that, so when the app tears down part of the screen to display
new stuff, those functions just get popped out of the DOM but aren't
garbage collected by the browser since the page never reloads.
Is there any way to force garbage collection while a page is still
loaded in any of the browsers?
I may need to build some kind of explicit cleanup functions that
attach to an element and clean these references upon the element's
removal from the DOM, except I fear it being really slow due to the
fact that if you remove a parent element that has a huge amount of
[great-great][grand]child nodes, I'll have to walk the whole tree and
clean each individual node..
Anyhow, any ideas would be wonderful.
Thanks!
--~--~-~--~~~---~--~~
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Widgets in mochikit-patches
I think the current location is quite fine, if not in the MochiKit repo itself. Should perhaps add a link from the Wiki pages, though... If you'd like to contribute new widgets, I'd love to include them! Just fork the git repo and send me a pull request when done. Regarding other widget solutions, my personal motivations for implementing yet-another-JavaScript-widget-library are: 1. Using a mix-in approach instead of wrapper objects, the code becomes more light-weight. 2. Creating a UI from XML instead of code makes for easier maintenance. 3. With a nice default look and simple API:s, the widgets become easy to use. 4. Unlimited open source license to avoid legal and commercial hassles. All of the above can be argued back and forth, of course. I see #1 above as the main point with this effort, since both the others could equally well be patched into some other widget library. And I see no point in doing something that isn't sufficiently different from other efforts in this area. I know lots of you just want to avoid using another JS library for your widgets, but is that really such a big problem? In fact, YUI is pretty configurable in that way if I recall correctly. Which kind of resonates with my reasons for staying with MochiKit in spite of the jQuery popularity surge (and actually using it a bit at work from time to time). That it does things differently from other JS libraries. For good or bad. Anyway. These are just my ramblings on the JS widget topic. Feel free to disagree. Cheers, /Per On Sun, May 31, 2009 at 23:23, Ryan Wilcox ryanwil...@gmail.com wrote: Per, If not in the standard MochiKit package, maybe in a centralized place/ repo blessed by the MochiKit team as the Widgets 4 MochiKit project, for example?? I'd be willing to contribute a few controls (a multi-select/shuffle take-options-from-this-select-and-put-in-that-one widget, for example. Available at http://bitbucket.org/rwilcox/ mochikit_multiselecttransfer/). Usually I'll use YUI framework for the big-gun widgets, but yes a MochiKit widgets package would be _excellent_. It feels annoying, for example, when I see a widget that's just perfect for what I need, except it requires JQuery (and I don't want to pull in a second or third JS library into the mix...) So, +1 from me, _Ryan Wilcox --~--~-~--~~~---~--~~ 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 mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Widgets in mochikit-patches
Hi David, Nice to see someone using my widgets for MochiKit! The Git repository has been out of date for a while, since nobody has been asking for updates. But now that you've patched the code, I've also updated my copies to the latest version. Will try to merge in your stuff as well. It was my original intention to push for inclusion into 1.5, but the response was quite muted here on the list last time around. So I've concentrated on other stuff instead. But if GitHub works for you, we might keep it there for now? Please let me know if you have any issues or questions regarding the widgets! Cheers, /Per On Sun, May 24, 2009 at 07:41, David Barnett davidbarne...@gmail.com wrote: Hi, I've been desperately needing some standard widgets on top of mochikit, and I found the widgets under mochikit-patches just recently. I'm wondering what their current status is, if many people use them, and what most people do for widgets (e.g. using jQuery over mochikit). David --~--~-~--~~~---~--~~ 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 mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: MochiKit + Google Gadgets + IE6/7?
In order to break this down a bit, could you try the page with just
the MochiKit.Base module? Use the download customizer to create a
minimized version with the modules you wish to try.
http://svn.mochikit.com/mochikit/trunk/packed/MochiKit/customize.html
We need to know more details about which module that breaks to analyze
this. It is not a known issue.
Cheers,
/Per
On Wed, Apr 29, 2009 at 1:32 AM, MXH mhey...@fairoakslabs.com wrote:
I'm having trouble using MochiKit with a Gadget I'm writing for the
iGoogle interface. Specifically, even the inclusion of the
MochiKit.js file (via a SCRIPT tag) seems to break otherwise-
functional Gadgets in IE6 or (more seriously) IE7. (Other browsers
seem fine.)
Here's what I'm seeing:
1.) I create a Gadget that *doesn't* depend on MochiKit
2.) The Gadget works (i.e. it renders properly on load, which involves
JS building up the DOM)
3.) I add a SCRIPT tag to the Gadget to import MochiKit.js
4.) The Gadget breaks (i.e. it won't render properly on load 90% of
the time)
Some clarifications:
a.) The Gadget has an html Content Type (To clarify the
clarification: Content Type refers to the parameter in Google's
Gadget XML spec, not the HTML Header.)
b.) This happens even if I include the MochiKit={__export__:false};
line at the top of MochKit.js, which should suppess symbol export.
c.) Again, the Gadget isn't making any use of MochiKit, it's just
trying to import the JavaScript.
d.) The failure is intermittent, but I've never seen it fail w/o the
MochiKit include, and it fails ~90% of the time with the include, so I
feel pretty sure the two are related.
My question: Is this a known problem? Has anyone else had
experiences, good or bad, with IE6 or IE7 compatibility when using
MochiKit to develop Google Gadgets?
Thanks for reading. If you're interested, the XML for the Gadget I am
using for testing can be fetched here:
http://www.house-o-games.com/neknek/gadgets/neknek.xml
(The failure occurs in the canvas view.)
--~--~-~--~~~---~--~~
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: [patch] formContents returning a dict
I'd prefer a non-incompatible fix for this. One obvious improvement
would be to add a dict() function:
http://github.com/cederberg/mochikit-patches/blob/1e0dd2fcc3c80e1fe78f87d9ca7d9ba16b9eee09/MochiKit/Base.js#L71
But for forms, some values might be repeated so that wouldn't solve it
all. Actually, I don't know if the current formContents() handles that
correctly... For the proposed widget library I rewrote it as this:
http://github.com/cederberg/mochikit-patches/blob/1e0dd2fcc3c80e1fe78f87d9ca7d9ba16b9eee09/MochiKit/Widget.js#L963
None of the above is in the MochiKit repository yet due to lack of
time on my part. Been working full-time with other stuff for a while,
but I'm planning to come back to MochiKit eventually. And tend to the
issues reported in Trac and here on the list.
Anyway. I think the best solution might be to create a new
formContents (different name) to allow for an alternative API. We'd
then deprecate the old implementation and remove entirely eventually.
Improving the download packager, we might even provide a strict
version or so.
Cheers,
/Per
On Fri, Apr 17, 2009 at 9:13 PM, Eoghan Murray eoghanomur...@gmail.com wrote:
Here is a patch that converts the output of DOM.formContents to a dictionary.
This has been raised as a difficulty before [1] and has bitten me a
few times when trying to edit the return value of formContents before
converting it to a query string.
In this patch, the previous format of:
[['name1', 'name2', 'name2'], ['value1', 'value2', 'value3']]
becomes:
{'name1': ['value1'], 'name2': ['value2', 'value3'] }
i.e. values are always stored in lists even if there is only one value.
This is backwards incompatible, but I've also updated Base.queryString
so that it still works with the new format.
If it is accepted I can update docs version history.
Eoghan
[1]
http://groups.google.com/group/mochikit/browse_thread/thread/5d970041f1696b10/a5fa33325d639cf4
--~--~-~--~~~---~--~~
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Question about SimpleTest
Thanks for the updated code Guilio! I'll have a look at it later on and get back to you. I'm currently a bit absent from MochiKit-related work, but I'll be back in a month or two I hope. Like most other people lurking around here it seems that I'm working on one or two projects too many... :-) Cheers, /Per On Mon, Mar 30, 2009 at 2:39 PM, Giulio Cesare Solaroli giulio.ces...@gmail.com wrote: Hello Per, I have been able to hack the SimpleTest.TestRunner code in order to be recursive, that is I can now have a TestRunner load other TestRunners and not just SimpleTests as in the current code. I still have a strange problem with Firefox 3.08 where the number of successful tests reported is sometimes wrong, but otherwise it works fine. Attached you can find my updated version of TestRunner.js and SimpleTest.js, in case anyone is interested. Regards, Giulio Cesare On Thu, Feb 26, 2009 at 2:35 AM, Giulio Cesare Solaroli giulio.ces...@gmail.com wrote: Hello Per, On Wed, Feb 25, 2009 at 7:54 PM, Per Cederberg cederb...@gmail.com wrote: Interesting that you're using SimpleTest! It is on my not-so-secret agenda for 1.5 to merge that into MochiKit.Test and create a public API for JS testing. Interesting; but SimpleTest is quite fine for my current needs To answer your question -- I think the tests/index.html file in the MochiKit distribution does this. It might not be all that elegant though. Nope. The tests/index.html files invoke the TestRunner.runTests method on a list of regular html test files. What I need is a way to create a tests/index.html test suite, that could include a call to (for example) tests/module1/index.html; where the later file is structured just like the former. Be sure to let me know if you have any ideas regarding creating an improved testing API. At the moment our testing needs are fulfilled by SimpleTest api. The only problem we have, is that sometimes tests fail silently, and if you don't know the correct number of expected tests, you may miss some errors. :-( But this is just an implementation issue. Regards, Giulio Cesare --~--~-~--~~~---~--~~ 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 mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: create IMG in position
Try using Firebug and step though your code. From Firebug you can
inspect the DOM properties of individual elements as well as modify
the CSS properties.
Cheers,
/Per
On Tue, Feb 24, 2009 at 4:16 AM, David Ximenes davi...@yahoo.com.br wrote:
hi,
(sorry, my english children´s, i´m from Brazil)
i´m study MochiKit and try the following code.
create an image
set position
appendchild
img = IMG({'src': 'path'}, null)
setElementPosition(img, getElementPosition(domEle))
appendChildNodes(currentDocument().body, img)
i´m trying put an image in position of the a other element put this don
´t work!
please some light, some help, i stay in headache!!!
--~--~-~--~~~---~--~~
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Defered.setFinal
I think this is a good idea. I needed something similar too, so I
ended up writing an ugly hack that worked most of the time...
d.addBoth(function (res) {d.addBoth(finalFunc); return res; });
It adds new callback once the first deferred result drops in,
hopefully after all the other callbacks have been added...
But a more formally correct solution would probably be a good idea.
Cheers,
/Per
On Tue, Feb 10, 2009 at 2:30 PM, Amit Mendapara
mendapara.a...@gmail.com wrote:
Hi Per,
I have just started again improving the MochiKit Extensions. While
creating tests for the Ajax module, I found one problem (not bug, but
specific to the feature I'm trying to implement). I registered a
callback which should be fired at the end of all registered callbacks.
I achieved by modifying Async.js with a new method `setFinal` (not
addFinal as there should be only one finalizer) which gets fired when
`chain.length == 0`. It's simple. I would we happy if you add one such
function in MochiKit.Async.Defered...
Regards
--
Amit
--~--~-~--~~~---~--~~
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: event on div
Ok, this isn't really MochiKit-related, but define your CSS class as follows:
.left {
overflow-y: auto;
height: 100%; /* or some fixed pixel value */
}
Try it with a static page first.
Cheers,
/Per
2009/1/30 Boštjan Jerko ml...@japina.eu:
I am looking for a way to automatically scroll class left to selected
id:
div class=left
a html=link1 id=link1.../abr/
a html=link2 id=link2.../abr/
a html=link3 id=link3.../abr/
a html=link4 id=link4.../abr/
/div
Now I'd like to scroll for example to id=link3.
Usualy this is done with adding onLoad to body tag, but that way you
scroll the whole window. I'd like to scroll only the left part.
B.
On 29.1.2009, at 23:13, Per Cederberg wrote:
Don't understand your question I'm afraid... Are you looking for
style=overflow: auto;? Or MochiKit.Selector.$$(div.left)???
Cheers,
/Per
On Thu, Jan 29, 2009 at 10:23 PM, Boštjan Jerko ml...@japina.eu
wrote:
Hello!
I'd like to link a function (to scroll the data) to a div I have.
The page is made out of two divs:
div class=left
.
/div
div class=right
.
/div
Now I'd like to link a script to div with class=left and do
scrolling only in that div.
Scrolling is already solved using MochiKit.Visual.ScrollTo, but I
don't know how to use it only in one div.
B.
--~--~-~--~~~---~--~~
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: event on div
var elem = $$(div.left a.link3);
/Per
On Fri, Jan 30, 2009 at 1:57 PM, Boštjan Jerko ml...@japina.eu wrote:
On 30.1.2009, at 11:15, Per Cederberg wrote:
Ok, this isn't really MochiKit-related, but define your CSS class as
follows:
.left {
overflow-y: auto;
height: 100%; /* or some fixed pixel value */
}
Try it with a static page first.
Cheers,
/Per
I already have that for a manual scroll. I want to do it
automaticaly.
As stated before - the scroll works perfectly on the whole page, but
I'd like to do it only in the div part of the page.
MochiKit documentation says to use addLoadEvent, but I don't know how
to connect it with div class=left.
B.
--~--~-~--~~~---~--~~
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: event on div
Don't understand your question I'm afraid... Are you looking for style=overflow: auto;? Or MochiKit.Selector.$$(div.left)??? Cheers, /Per On Thu, Jan 29, 2009 at 10:23 PM, Boštjan Jerko ml...@japina.eu wrote: Hello! I'd like to link a function (to scroll the data) to a div I have. The page is made out of two divs: div class=left . /div div class=right . /div Now I'd like to link a script to div with class=left and do scrolling only in that div. Scrolling is already solved using MochiKit.Visual.ScrollTo, but I don't know how to use it only in one div. B. --~--~-~--~~~---~--~~ 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 mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: connectEach shortcut
On Tue, Dec 16, 2008 at 3:47 PM, Eoghan eoghanomur...@gmail.com wrote:
2. Modify the lookup by id convention to lookup by selector + map:
connect('#my-ul li', 'onclick', func);
Yes, changing these lookups would break the current API. But it
wouldn't be impossible to create a migration path with decent
backwards compatibility if we really want to.
The more important issues with this, I think, is that we would have to:
* Change every MochiKit.DOM, Style, Signal, Visual... function that
accepts the current shortcut to work properly on node lists (not just
individual nodes).
* Add the MochiKit.Selector module as a dependency for the DOM module
(actually a circular dependency).
I'm not very convinced that this is the right direction, but on the
other side I hardly ever use the current shortcut either. My own use
cases all rely on keeping object maps with direct references to my DOM
nodes.
4. Map if passed an array-like
connect($$('#my-ul li'), 'onclick', func);
This looks like the fastest way forward right now.
But instead of connecting signal handlers all over, I'd personally do
the following instead:
var func = function (evt) {
var li = evt.target();
if (li.tagName == null || li.tagName.toUpperCase() != LI) {
li = getFirstParentByTagAndClassName(evt.target(), LI);
}
... whatever you wanted to do ...
}
connect('my-ul', 'onclick', func);
Agreed that using getFirstParentByTagAndClassName() gets a bit messy,
since it doesn't check the specified node for a match (just the
parents).
5. More powerful partial:
forEach($$('#my-ul li'), partial(connect, __, 'onclick', func));
We probably need the more powerful partial or bind, but I'm not so
sure about this API.
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: setNodeAttribute Not working with Google Chrome
This is a WebKit (both Safari Chrome) issue, since it handles
attributes more strictly than other browsers. I.e. 'selected' is not
an attribute on the HTML node, just a property. We try to work around
this in most cases by setting both the attribute and the property just
to be sure:
if (typeof(elem[k]) == string elem[k] != v) {
// Also set property for weird attributes (see #302)
elem[k] = v;
}
But in WebKit typeof(elem.selected) == boolean, so this fix doesn't
run... Perhaps we should add a patch for the patch here. Don't know if
it will be safe, but it might work.
The easy work-around for you is to do the following instead:
function getAnalogueInputs(){
var node = getElement('[AN1_MEASURING_Q]');
// FIXME: the next line will always return 1... probably not intended
var type = getSignalTypeAsIndex(node[0]);
var opt = node.options[type];
opt.selected = 'selected';
}
Cheers,
/Per
On Mon, Dec 8, 2008 at 11:20 AM, n.karako...@googlemail.com
n.karako...@googlemail.com wrote:
Hi,
Thanks for the reply. There is no error shown in Google Chrome. Here
is a test file.
!DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://
www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd
html xmlns=http://www.w3.org/1999/xhtml;
head
meta http-equiv=Content-Type content=text/html; charset=utf-8 /
!--script type=text/javascript src=MochiKit-1.3.1/lib/MochiKit/
MochiKit.js/script--
script type=text/javascript src=MochiKit-1.4/lib/MochiKit/
MochiKit.js/script
title/title
/head
body
form action=
div style=margin-left:5px
h2Analogue Inputs/h2/div
!--AN1--
div class=an
h3nbsp;/h3
div class=tableDataGrey style=width:130px;
labelMeasuring Quantity
select name=an1MeasuringQ size=1 id=[AN1_MEASURING_Q]
option value=level Level/option
option value=pressure Pressure/option
/select
/label
/div
/div
/form
/body
/html
script type=text/javascript
function getAnalogueInputs(){
var node = 'pressure';
node = getElement('[AN1_MEASURING_Q]');
setNodeAttribute(node.options[getSignalTypeAsIndex(node
[0])],'selected','selected');
}
function getSignalTypeAsIndex(type){
if(type == level)
return 0;
else
return 1;
}
connect(window, 'onload',
function() {
getAnalogueInputs();
}
);
/script
On Dec 7, 11:10 pm, Per Cederberg cederb...@gmail.com wrote:
If you could provide more details on exactly what is breaking it would
be easier to help. Perhaps a minimal HTML file exposing the issue? If
you can find any error or debugging information from Chrome (if there
is any) that too would be very helpful.
Cheers,
/Per
On Sun, Dec 7, 2008 at 8:49 PM, n.karako...@googlemail.com
n.karako...@googlemail.com wrote:
Hi,
The following code doest work with Google Chrome but is OK with
firefox and IE7
node = getElement('[AN3_PRE_ALARM_ACTION]');
setNodeAttribute(node.options[getActionAsIndex(d.an3
[7])],'selected','selected');
Any thoughts?
Regards,
Nick
--~--~-~--~~~---~--~~
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Curry and uncurry
Thanks for the clarification, Bob!
Regarding the functions in questions I think other names might be in
place, to avoid misleading interpretations. What we're really doing
here is attempting to patch the poor JavaScript syntax and/or standard
library for function calls (i.e. call, apply, arguments and others).
The current MochiKit work-around for this is the excellent bind()
function (in its many incarnations). But it still has weaknesses,
since it doesn't allow us to do any of the following cool things:
1. Use the call-time 'this' object as an argument to the function (can
only be used as the object). If we had this, the currying mentioned
here would strictly be a version of bind().
2. Leaving gaps for call-time arguments in the list arguments set at
bind-time. Currently call-time arguments can only be appended to the
argument list.
3. Perform reordering of arguments. Typically inverse two arguments,
like in the startsWith discussion.
4. Perform random argument transformation. Using an array as the
argument list or vice versa. Or adding automatic flattening to
arguments.
The more I think about this, I tend to come to the conclusion that we
need something powerful enough to allow both the current bind() and
all of the above. Perhaps the syntax needn't be trivial, since we
could then add simplifying aliases for whatever common use-cases we
can identify.
One option, for example, would be a bind-version that would actually
map each function argument:
caller(func, self, { value: 123 }, { arg: 3 }, { arg: 1 }, { arg: -1 });
Another might be to create higher order argument-mapping functions:
var flip = function (func, self, args) { return args.reverse(); };
caller(func, self, flip);
These were just two ideas off the top of my head. But I think we
should discuss more options here before plunging ahead and adding yet
another variant of bind to MochiKit. Although they might all be very
useful. It will slowly get too confusing for the average user.
Thanks for reading this far! :-)
Cheers,
/Per
On Thu, Dec 18, 2008 at 5:25 PM, Arnar Birgisson arna...@gmail.com wrote:
Hi all,
On Thu, Dec 18, 2008 at 16:07, Bob Ippolito b...@redivi.com wrote:
I'm not a real big fan of currying in languages where it's not
built-in. It's easy to make a mistake by calling a function with too
few arguments and you get a harder to track down bug. It also doesn't
work well with languages that have default arguments or the equivalent
(e.g. using the arguments object) because you don't know exactly when
to stop currying.
Actually, the functions I proposed (curry and uncurry, stolen form
Haskell) do not describe this kind of currying.
curry takes a function of one argument, a tuple, and returns a
modified function that instead takes N arguments (the elements of the
tuple). The reason for the name curry is that it basically performs
the translation you (Bob) mentioned in Haskell, i.e. it transforms an
N argument function to a nesting of N one-argument functions, i.e. it
curries the function.
uncurry takes a function of N arguments and returns a modified
function that instead takes one argument, a tuple of N elements.
Obviously the naming comes from this being the reverse of curry.
The absolute main use case is mapping functions over a list of tuples
(in js list=tuple). This uses uncurry to change a function f(a,b) to
f(t) where t is a tuble of a and b. That way you can simply map (or
filter) the function over the outer list and arguments get placed in
the correct spot.
Currying is a convenience for changing a function that takes a tuple
(i.e. a list in js) and apply it with the tuple elements as arguments
-- i.e. exactly what Function.apply does in js. I'd still include it
if uncurry is included, for the sake of symmetry.
I do realize this might be a bit too eccentric -- but it is the kind
of thing that becomes very useful to grab when you do a lot of
functional-style programming in any language.
Per provided bind(apply, operator.add, null) as equivalent to
uncurry. This is true, except that the context (this) is not
maintained.. but yes, maybe it is my weird style but I'd give an alias
to this.
Dunno.. I'm happy to keep it in my personal library of helper functions :)
cheers,
Arnar
--~--~-~--~~~---~--~~
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Introducing the MochiKit.Text module
On Wed, Dec 17, 2008 at 5:11 PM, Arnar Birgisson arna...@gmail.com wrote: One comment about startsWith, endsWith, contains etc.. currently they take first the haystack and then the needle (I'm talking about parameter order). Perhaps switching this could benefit the usecase where this is used with partial? my_namesakes = filter(partial(contains, 'Arnar'), list_of_names); This is a good point. I think I'll change my ways. Watch out for the next commit... :-) The module should define constants like ascii_chars, digits etc. as per http://www.python.org/doc/2.3/lib/module-string.html -- also split, join (although they are included in js as native methods - having functions can be convenient for map friends). That might be an idea. With the same reversed parameter order as the ones above of course. For padRight and padLeft - I prefer the Python names ljust, rjust (and center). Ah, well... I didn't look too hard into Python here. Just googled various name ideas and picked the most popular one (think it was from some MS API actually)... ;-) 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 mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Introducing the MochiKit.Text module
Hi everyone, I've just finished committing one of my planned additions to MochiKit 1.5 -- a new MochiKit.Text module: http://www.mochikit.com/doc/html/MochiKit/Text.html It basically provides some of the text formatting stuff discussed here on the list previously. With some random string utility functions added on top. I chose the name Text instead of String or Format for various reasons, but in the end I guess it is just a matter of taste. Also, it avoids collisions with the MochiKit.String name already in use by Amit. My plans for MochiKit.Text are as follows: 1. Collect more ideas and feedback (hence this email). 2. Migrate camelize, strip, lstrip, rstrip, truncToFixed, roundToFixed and locale handling over to MochiKit.Text. Perhaps the remaining parts of MochiKit.Format should be deprecated? 3. Implement some additional stuff like toTitleCase, isDigit, isAlphaNumeric, etc. Please let me know what you think. 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 mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Curry and uncurry
The names curry and uncurry were a bit confusing to me, so it took
me a while to understand these two functions...
http://en.wikipedia.org/wiki/Currying
To me (and probably other non-Haskell users) the names imply the same
thing as bind or partial. It's a confusing world... :-(
In JavaScript, I think plain apply + MochiKit.Base.bind does the same thing:
var test = [ [10, 1], [20, 2], [30, 3] ];
var addArray = bind(apply, operator.add, null);
assertEqual(map(addArray, test), [11, 22, 33]);
It's no beauty, so perhaps this particular variant of bind merits an
alias? Uncurrying is just the same as the built-in apply function, so
that seems unnecessary.
Cheers,
/Per
On Wed, Dec 17, 2008 at 5:22 PM, Arnar Birgisson arna...@gmail.com wrote:
One thing I think could be useful is to port Haskell's curry and
uncurry. This is basically a convenience method for (un)wrapping an
.apply on a function object:
function curry(f) {
return function () {
// first convert arguments to a regular array
var args = Array.prototype.slice.call(arguments);
return f(args);
}
}
function uncurry(f) {
return function (args) {
return f.apply(this, args);
}
}
Example use:
test = [ [10, 1],
[20, 2],
[30, 3] ];
assertEqual(map(uncurry(operator.plus), test), [11, 22, 33]);
// assume join is a function that takes a list and returns a string
// with the elements joined with some delimiter
f = curry(partial(join, _, , ))
assert(f(Bond, James Bond) == Bond, James Bond)
Does anyone else think this could be useful? What module would it fit?
Base already has a lot of functional stuff (compose, partial, map
friends) - I'm wondering if it fits there or if all the functional
stuff should be in a seperate module MochiKit.Functional - as Python
seems to be heading.
cheers,
Arnar
--~--~-~--~~~---~--~~
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Weird bug in MochiKit.Style.getElementPosition
Naturally I meant:
getElementPosition(descendant, parent);
... and not the other way around.
/Per
On Mon, Dec 15, 2008 at 12:34 PM, Per Cederberg cederb...@gmail.com wrote:
I think that line was used to do the following:
var parent = $(one);
var descendant = $(two);
getElementPosition(parent, descendant);
I.e, we can send another node as the relativeTo value. Not just an
object with x and y properties.
Cheers,
/Per
On Mon, Dec 15, 2008 at 12:17 PM, Amit Mendapara
mendapara.a...@gmail.com wrote:
What does this line really intended for?
relativeTo = arguments.callee(relativeTo);
I have removed this line and that error was gone...
- Amit
On Dec 12, 8:08 pm, Per Cederberg cederb...@gmail.com wrote:
Hi,
I ran across a weird bug in MochiKit.Style.getElementPosition causing
FF to throw evil C++ exceptions into the console:
http://trac.mochikit.com/ticket/332
Debugging the MochiKit code I ended up looking at the following piece
of black magic:
getElementPosition: function (elem, /* optional */relativeTo) {
var self = MochiKit.Style;
var dom = MochiKit.DOM;
elem = dom.getElement(elem);
if (!elem ||
(!(elem.x elem.y)
(!elem.parentNode === null ||
self.getStyle(elem, 'display') == 'none'))) {
return undefined;
}
Question: What does the if-statement really do? And what was the real
intention?
It seems the getStyle() function is called even though I send in a {
x: 0, y: 0 } object. I guess that is not the real intention.
Especially I like the !elem.parentNode === null check. What does
that even mean??? Weird that the previous test cases haven't caught
anything here...
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Weird bug in MochiKit.Style.getElementPosition
Looked a bit deeper into this issue. Seems that the suggested change
to MochiKit.DOM.getElement() would break some tests for Signal and
DOM, since both modules contain code that assume getElement() will
just return whatever non-string object it was provided with.
I've fixed those cases I could find (r1492), but I guess this might be
an API-breaking change. So I'm holding off on the core
MochiKit.DOM.getElement() change for now.
Regarding the original issue, I think that the original code attempted
to say this (not perfect, but more understandable):
getElementPosition: function (elem, /* optional */relativeTo) {
var self = MochiKit.Style;
var dom = MochiKit.DOM;
var isCoordinates = function (o) {
return o != null
o.nodeType == null
typeof(o.x) == number
typeof(o.y) == number;
}
if (typeof(elem) == string) {
elem = dom.getElement(elem);
}
if (elem == null ||
(!isCoordinates(elem) self.getStyle(elem, 'display') ==
'none')) {
return undefined;
}
Fixed in r1494. Thanks for the feedback!
Cheers,
/Per
On Mon, Dec 15, 2008 at 1:11 PM, Per Cederberg cederb...@gmail.com wrote:
Ah, yes... You are probably right. Thanks for the analysis!
It only makes sense for getElement() to return a Node or
null/undefined. Other return values are probably just a side-effect
for the fast-path return for DOM nodes.
But perhaps fixing this will break one or two things, like the
getElementPosition() code mentioned... I'll check that out once I'm
done with some other MochiKit work I'm currently doing.
I still suspect the weird if-statement posted before for not being sane,
though.
Cheers,
/Per
On Mon, Dec 15, 2008 at 12:59 PM, Amit Mendapara
mendapara.a...@gmail.com wrote:
I think,
var elem = MochiKit.DOM.getElement({});
should return `null` or `undefined` but it returns the argument in
this case. The check
if (!elem || elem == d) {
return undefined;
}
in getStyle fails due to this...
- Amit
On Dec 15, 4:34 pm, Per Cederberg cederb...@gmail.com wrote:
Naturally I meant:
getElementPosition(descendant, parent);
... and not the other way around.
/Per
On Mon, Dec 15, 2008 at 12:34 PM, Per Cederberg cederb...@gmail.com wrote:
I think that line was used to do the following:
var parent = $(one);
var descendant = $(two);
getElementPosition(parent, descendant);
I.e, we can send another node as the relativeTo value. Not just an
object with x and y properties.
Cheers,
/Per
On Mon, Dec 15, 2008 at 12:17 PM, Amit Mendapara
mendapara.a...@gmail.com wrote:
What does this line really intended for?
relativeTo = arguments.callee(relativeTo);
I have removed this line and that error was gone...
- Amit
On Dec 12, 8:08 pm, Per Cederberg cederb...@gmail.com wrote:
Hi,
I ran across a weird bug in MochiKit.Style.getElementPosition causing
FF to throw evil C++ exceptions into the console:
http://trac.mochikit.com/ticket/332
Debugging the MochiKit code I ended up looking at the following piece
of black magic:
getElementPosition: function (elem, /* optional */relativeTo) {
var self = MochiKit.Style;
var dom = MochiKit.DOM;
elem = dom.getElement(elem);
if (!elem ||
(!(elem.x elem.y)
(!elem.parentNode === null ||
self.getStyle(elem, 'display') == 'none'))) {
return undefined;
}
Question: What does the if-statement really do? And what was the real
intention?
It seems the getStyle() function is called even though I send in a {
x: 0, y: 0 } object. I guess that is not the real intention.
Especially I like the !elem.parentNode === null check. What does
that even mean??? Weird that the previous test cases haven't caught
anything here...
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] New implementations of MochiKit.Format.truncToFixed and roundToFixed
Due to a new set of weird rounding errors in JavaScript floating-point numbers, I opted to fully replace the MochiKit.Format.truncToFixed and roundToFixed functions with new implementations. This basically affects all of the other MochiKit.Format functions as well. The new code pass all the tests in Firefox and IE, but here be dragons... :-) If you use this module in your code, please double-check that everything still works as supposed in version 1.5 (r1491 or later). Let me know if you bump into any issues. Thanks, /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 mochikit+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Weird bug in MochiKit.Style.getElementPosition
I think that line was used to do the following:
var parent = $(one);
var descendant = $(two);
getElementPosition(parent, descendant);
I.e, we can send another node as the relativeTo value. Not just an
object with x and y properties.
Cheers,
/Per
On Mon, Dec 15, 2008 at 12:17 PM, Amit Mendapara
mendapara.a...@gmail.com wrote:
What does this line really intended for?
relativeTo = arguments.callee(relativeTo);
I have removed this line and that error was gone...
- Amit
On Dec 12, 8:08 pm, Per Cederberg cederb...@gmail.com wrote:
Hi,
I ran across a weird bug in MochiKit.Style.getElementPosition causing
FF to throw evil C++ exceptions into the console:
http://trac.mochikit.com/ticket/332
Debugging the MochiKit code I ended up looking at the following piece
of black magic:
getElementPosition: function (elem, /* optional */relativeTo) {
var self = MochiKit.Style;
var dom = MochiKit.DOM;
elem = dom.getElement(elem);
if (!elem ||
(!(elem.x elem.y)
(!elem.parentNode === null ||
self.getStyle(elem, 'display') == 'none'))) {
return undefined;
}
Question: What does the if-statement really do? And what was the real
intention?
It seems the getStyle() function is called even though I send in a {
x: 0, y: 0 } object. I guess that is not the real intention.
Especially I like the !elem.parentNode === null check. What does
that even mean??? Weird that the previous test cases haven't caught
anything here...
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Weird bug in MochiKit.Style.getElementPosition
Ah, yes... You are probably right. Thanks for the analysis!
It only makes sense for getElement() to return a Node or
null/undefined. Other return values are probably just a side-effect
for the fast-path return for DOM nodes.
But perhaps fixing this will break one or two things, like the
getElementPosition() code mentioned... I'll check that out once I'm
done with some other MochiKit work I'm currently doing.
I still suspect the weird if-statement posted before for not being sane, though.
Cheers,
/Per
On Mon, Dec 15, 2008 at 12:59 PM, Amit Mendapara
mendapara.a...@gmail.com wrote:
I think,
var elem = MochiKit.DOM.getElement({});
should return `null` or `undefined` but it returns the argument in
this case. The check
if (!elem || elem == d) {
return undefined;
}
in getStyle fails due to this...
- Amit
On Dec 15, 4:34 pm, Per Cederberg cederb...@gmail.com wrote:
Naturally I meant:
getElementPosition(descendant, parent);
... and not the other way around.
/Per
On Mon, Dec 15, 2008 at 12:34 PM, Per Cederberg cederb...@gmail.com wrote:
I think that line was used to do the following:
var parent = $(one);
var descendant = $(two);
getElementPosition(parent, descendant);
I.e, we can send another node as the relativeTo value. Not just an
object with x and y properties.
Cheers,
/Per
On Mon, Dec 15, 2008 at 12:17 PM, Amit Mendapara
mendapara.a...@gmail.com wrote:
What does this line really intended for?
relativeTo = arguments.callee(relativeTo);
I have removed this line and that error was gone...
- Amit
On Dec 12, 8:08 pm, Per Cederberg cederb...@gmail.com wrote:
Hi,
I ran across a weird bug in MochiKit.Style.getElementPosition causing
FF to throw evil C++ exceptions into the console:
http://trac.mochikit.com/ticket/332
Debugging the MochiKit code I ended up looking at the following piece
of black magic:
getElementPosition: function (elem, /* optional */relativeTo) {
var self = MochiKit.Style;
var dom = MochiKit.DOM;
elem = dom.getElement(elem);
if (!elem ||
(!(elem.x elem.y)
(!elem.parentNode === null ||
self.getStyle(elem, 'display') == 'none'))) {
return undefined;
}
Question: What does the if-statement really do? And what was the real
intention?
It seems the getStyle() function is called even though I send in a {
x: 0, y: 0 } object. I guess that is not the real intention.
Especially I like the !elem.parentNode === null check. What does
that even mean??? Weird that the previous test cases haven't caught
anything here...
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: connectEach shortcut
I think it is an interesting idea to be able to bind any argument
position. Think I mentioned it earlier in the 1.5 API discussion that
we now have quite a few variants of bind-like functions -- bind,
bindLate, bindMethods, forwardCall, partial, method, methodCaller...
Too many for my taste, so I think it is time to revisit these API:s.
Perhaps something more generic than the current bind() might be a good
idea? Or perhaps it would have an API that is too complex? Don't know
really.
I'll look into the code posted by Arnar later on (no much time right
now) and comment on the specifics then.
Cheers,
/Per
On Sun, Dec 14, 2008 at 1:53 AM, Arnar Birgisson arna...@gmail.com wrote:
On Sat, Dec 13, 2008 at 23:26, Eoghan eoghanomur...@gmail.com wrote:
May I suggest MochiKit.Base.__ as the name of the placeholder
variable.
If Bob or Per want to include this, I'd like to change it to make it
compatible with the current partial (namely, any extra parameters
passed on the call itself will just be tacked on the end).
MochiKit.Base.__ sounds good to me. Just _ is more likely to step on
someone's toes.
I can't imagine needing the permuting version myself.
Actually, 95% of the cases I've wanted this I just wanted flip
(reverse the order of two parameters). At the very least I'd like to
see
function flip(f) {
return function (x,y) { return f(y,x); };
}
included. In other cases, I have definitely had use for the generic
permuting version.
cheers,
Arnar
--~--~-~--~~~---~--~~
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Weird bug in MochiKit.Style.getElementPosition
Hi,
I ran across a weird bug in MochiKit.Style.getElementPosition causing
FF to throw evil C++ exceptions into the console:
http://trac.mochikit.com/ticket/332
Debugging the MochiKit code I ended up looking at the following piece
of black magic:
getElementPosition: function (elem, /* optional */relativeTo) {
var self = MochiKit.Style;
var dom = MochiKit.DOM;
elem = dom.getElement(elem);
if (!elem ||
(!(elem.x elem.y)
(!elem.parentNode === null ||
self.getStyle(elem, 'display') == 'none'))) {
return undefined;
}
Question: What does the if-statement really do? And what was the real intention?
It seems the getStyle() function is called even though I send in a {
x: 0, y: 0 } object. I guess that is not the real intention.
Especially I like the !elem.parentNode === null check. What does
that even mean??? Weird that the previous test cases haven't caught
anything here...
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
mochikit+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: forEach scope gotcha
To me it seems both version should work equally well. Each function
scope created should be linked together, causing the my_var variable
lookup to be found in the outer function when not defined in the local
function scope. Unless I've misunderstood something about variable
scoping in JavaScript.
On the other hand, it looks like you are just filtering elements by
tag name, class and attribute value. Wouldn't it be nice to just use a
selector instead?
connect(el, 'onclick', function (e) {
var my_var = getNodeAttribute(e.src(), 'someattr');
forEach($$(div.some_class[someattr=' + my_var + ']), function(mydiv) {
// do something
}
});
Cheers,
/Per
On Wed, Dec 3, 2008 at 4:18 PM, Eoghan [EMAIL PROTECTED] wrote:
I commonly use forEach within another function, like the following
example:
connect(el, 'onclick', function(e){
var my_var = getNodeAttribute(e.src(), 'someattr');
forEach(getElementsByTagAndClassName('div', 'some_class'),
function(mydiv){
if(getNodeAttribute(mydiv, 'someattr') == my_var){
// do something
}
}
});
Unfortunately 'my_var' takes on unexpected values, because the
function that acts as the body of the forEach is a closure (I think).
Converting the above code to use a plain old 'for' loop acts as
expected:
connect(el, 'onclick', function(e){
var my_var = getNodeAttribute(e.src(), 'someattr');
var arr = getElementsByTagAndClassName('div', 'some_class');
for(var i=0; iarr.length; i++){
var mydiv = arr[i];
if(getNodeAttribute(mydiv, 'someattr') == my_var){
// do something
}
}
});
Using a partial function for the forEach body with 'my_var'
preinitialised seems clunky to me and definitely reduces readability.
What is the most elegant way to make forEach behave as expected (as
illustrated by the second example)?
Thanks!
Eoghan
--~--~-~--~~~---~--~~
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: slideDown is not working properly, after double click
Store your old effect in a global variable or similar:
var currentEffect = null;
Then finish off any old effect before starting new ones:
if (currentEffect) {
currentEffect.finish();
}
currentEffect = slideDown(...);
Cheers,
/Per
On Mon, Dec 1, 2008 at 1:49 PM, Ranjan [EMAIL PROTECTED] wrote:
Hi,
I have written as follows:
function toggleFilter(opt, e) {
var filter_options = getElement('filter_options');
var show_filter = getElement('show_filter');
var hide_filter = getElement('hide_filter');
if (opt == 'show') {
if (e != null)
e.cancel();
effect = slideDown('filter_options');
show_filter.style.display='none';
hide_filter.style.display='inline';
}
else {
if (e != null)
e.cancel();
effect = slideUp('filter_options');
hide_filter.style.display='none';
show_filter.style.display='inline';
}
}
But it is not working, when I double click. Is there any mistake,
please help
Thanks,
Ranjan
--~--~-~--~~~---~--~~
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: Selector.findChildElements patch
Thanks! It has been committed in r1489:
http://trac.mochikit.com/changeset/1489
Cheers,
/Per
On Mon, Dec 1, 2008 at 2:52 PM, Eoghan [EMAIL PROTECTED] wrote:
Below is a patch for findChildElements to make it look up the element
if it is passed by id rather than DOM reference:
Index: Selector.js
===
--- Selector.js (revision 1488)
+++ Selector.js (working copy)
@@ -341,6 +341,7 @@
/** @id MochiKit.Selector.findChildElements */
findChildElements: function (element, expressions) {
+element = MochiKit.DOM.getElement(element);
var uniq = function(arr) {
var res = [];
for (var i = 0; i arr.length; i++) {
--~--~-~--~~~---~--~~
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] MochiKit compatibility with other libraries
Just completed the removal of built-in JSAN and Dojo toolkit support (r1482), which was next in the series of minor 1.5 changes. Also made some changes to the module headers to shave of a few kb of loading time (r1483). Next up will be the function exports. A new wiki page attempts to document how to use MochiKit with other libraries. If you use both MochiKit and something else, please check it out and verify that it is reasonably correct. Otherwise, feel free to just edit the page directly. http://trac.mochikit.com/wiki/OtherLibraries 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: How to set log level of default logger?
Actually, I don't think it is possible (from reading only the documentation). The log filtering is only applied to listeners. But even they cannot affect what is being sent to the native console. I think you'd have to assign some of the log* methods to MochiKit.Base.noop in order to silence their log messages. Or replace the default logger with your own. Now, I'm planning to revamp the logging sometime to alleviate issues like this. While not breaking backwards compability I hope. But if you are interested, feel free to send patches to the list. Cheers, /Per On Thu, Nov 27, 2008 at 4:36 PM, Bjoern [EMAIL PROTECTED] wrote: Another basic question, but maybe you could also understand it as a documentation bug: I have a hard time to understand how to set the log level of the default logger? How can I access the default logger? And actually how are listeners and the LoggingPane related - is a LoggingPane a listener? I guess I don't understand the Logging framework at all, except that when I write log(something) it appears in firebug and/or the LoggingPane... --~--~-~--~~~---~--~~ 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] MochiKit 1.4.2 released
MochiKit 1.4.2 has now been released and is available on the web site: http://mochikit.com/download.html http://svn.mochikit.com/mochikit/tags/MochiKit-1.4.2/packed/MochiKit/customize.html This version contains the correction of a few issues found since the last release: * More fixes in MochiKit.Style.getElementDimensions for IE and hidden elements (#325). * Fixed issue in MochiKit.Style.getViewportDimensions when called within the document HEAD. * Fixed MochiKit.DOM.coerceToDOM() handling of arrays when MochiKit.Iter is not loaded (#328). Many thanks to everyone involved for the excellent feedback and bug reports! 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: Selector speedup by using John Resig's Sizzle
Arnar, thanks for the update! I'm in no hurry myself, having plenty of other things to focus on. :-) Hope you have a nice trip! Cheers, /Per On Thu, Nov 20, 2008 at 11:55 AM, Arnar Birgisson [EMAIL PROTECTED] wrote: Hi Per, On Tue, Nov 18, 2008 at 23:04, Per Cederberg [EMAIL PROTECTED] wrote: Perhaps the time is right now to just go ahead and merge the new selector branch into the 1.5 trunk? With the appropriate updates from the base Sizzle implementation of course. If Sizzle is considered stable, I'd say it is time to do so. I haven't been able to give any attention to this for the last few weeks as I've been travelling in the States, Italy and the Netherlands -- with various levels of connection -- and will not be able to until December at least. Also, please note that the MochiKit Customizer assumes that each module starts with a call to _deps and ends with a call to _export, so please make sure that the new Selector module also follows that pattern. Could you add a ticket for it? If no-one else takes care of it, then as I said I won't be available until December. cheers, Arnar --~--~-~--~~~---~--~~ 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: Sending a signal to a DOM element
I finally got around to fixing the MochiKit.Signal.signal() function
when used with DOM elements. As of r1476, the implementation should
work more as expected, simply passing the specified arguments on to
the slot functions.
This will also make it possible to work with fake signals on DOM
elements, such as onshow, onhide, etc. As a side-note, this is the
first 1.5-only change to MochiKit so far.
Cheers,
/Per
On Wed, Oct 29, 2008 at 3:33 PM, Per Cederberg [EMAIL PROTECTED] wrote:
Actually, I think the whole API for the signal() function needs to be
sanity-checked. It works rather poorly if you want to send non-DOM
signals to DOM objects for instance (if you've invented your own
signals for example).
Just waiting for that day when I have loads of spare time on my hands
again... :-)
Meanwhile, feel free to drop me a documentation patch. We are very
liberal with accepting those.
Cheers,
/Per
On Wed, Oct 29, 2008 at 2:16 PM, Eoghan [EMAIL PROTECTED] wrote:
Great,
What I came up with was:
signal('my-anchor-id', 'onclick', {stop: noop});
Maybe this would be a good edge case example to add to the docs under
Synopsis - Signal for DOM events:
Eoghan
On Oct 29, 12:04 pm, Per Cederberg [EMAIL PROTECTED] wrote:
The documentation isn't very good at this point. But you probably want
to mock the browser event object:
var fakeEvent = {};
signal('my-anchor-id', 'onclick', fakeEvent);
You might have to add various properties to the fake event object in
order for your code to work. See the implementation of the
MochiKit.Signal.Event class:
http://trac.mochikit.com/browser/mochikit/trunk/MochiKit/Signal.js
Cheers,
/Per
On Wed, Oct 29, 2008 at 11:41 AM, Eoghan [EMAIL PROTECTED] wrote:
I have the following:
connect('my-anchor-id', 'onclick', function(e){
// Do some stuff
e.stop();
});
I also want to click the anchor on page load, so I have this
elsewhere:
signal('my-anchor-id', 'onclick');
Unfortunately this throws the error 'this._event is undefined' when it
encounters e.stop();
The following also throws the error
connect('my-anchor-id', 'onclick', function(e){
// Do some stuff
if(e){ e.stop(); }
});
The only thing that works is the hacky:
connect('my-anchor-id', 'onclick', function(e){
// Do some stuff
if(e._event){ e.stop(); }
});
Is this a rough edge or am I doing it wrong?
Eoghan
--~--~-~--~~~---~--~~
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: IE errors in getViewportDimensions
Thanks for a great bug report and patch, David! It has been applied in r1466 and will also show up in 1.4.2 (eventually). Cheers, /Per On Tue, Nov 18, 2008 at 12:19 AM, David Barnett [EMAIL PROTECTED] wrote: Hi guys, I found a somewhat obscure bug in getViewportDimensions that appears in IE when using TurboFancyFlash. The problem is that the check whether MochiKit.DOM._document.body.parentElement.ClientWidth exists will error out if MochiKit.DOM._document.body doesn't exist. TurboFancyFlash makes that happen in IE by calling getViewportDimensions from the HEAD tag. I've attached a patch against the latest SVN of MochiKit. I've also sent the patch to the Chris Arndt (the TurboFancyFlash creator) since TFF bundles a version of MochiKit. David --~--~-~--~~~---~--~~ 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] New packed version of MochiKit
After some experimenting and tinkering, I've finally linked the MochiKit Customizer from the download web page: http://www.mochikit.com/download.html It is available in two flavors, both for 1.4.2 (upcoming) and svn trunk. And is also included in the full zipped install file (in the packed subdirectory). Thanks to Bob for the suggestion! Along with this, I've also changed the default packed version to include all modules (i.e. also DragAndDrop and Sortable) so that they are visible to the customizer. Hope nobody minds that change. 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] Removal of Dojo and JSAN support
Just wondering -- is there anyone out there using MochiKit as a JSAN or Dojo package? Bob and I recently discussed removing the support code from MochiKit, since it seems kind of out-dated. Also, the Dojo support has been pretty broken before without anybody noticing for a long time. Any protests? Otherwise I'll just go ahead and clean it up in 1.5. 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: Selector speedup by using John Resig's Sizzle
I don't follow the Sizzle development very closely, but I seem to remember having seem some check-ins dealing with similar issues. Perhaps the time is right now to just go ahead and merge the new selector branch into the 1.5 trunk? With the appropriate updates from the base Sizzle implementation of course. Also, please note that the MochiKit Customizer assumes that each module starts with a call to _deps and ends with a call to _export, so please make sure that the new Selector module also follows that pattern. Cheers, /Per On Tue, Nov 4, 2008 at 11:36 AM, Arnar Birgisson [EMAIL PROTECTED] wrote: Hello Giulio Cesare, First: wow - your name is awesome :) On Mon, Nov 3, 2008 at 11:56, Giulio Cesare Solaroli [EMAIL PROTECTED] wrote: I would like to ask if the new implementation is currentWindow aware or (like it seems form a quick look at the code) is still accessing directly the document object. I will try to make a few test case to see if I am doing something wrong with my current code or there is really a problem here. I want the new implementation to be currentWindow aware (or rather currentDocument) - and I tried to put the call in the right places. However, I'm not entirely sure that Sizzle handles this correctly. I.e. Sizzle might implicitly make the assumption that one is using window.document in some places. I pointed this out to John and he could not confirm either way, I think he means to have a look at it. In the meantime, test-cases for this would be greatly appreciated. If you find specific problems, please make a track issue and/or submit a patch if you can. cheers, Arnar --~--~-~--~~~---~--~~ 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: Custom event listeners
When you call setInterval and setTimeout you should provide functions.
In your first example you perform a function call to setTimeout and
then send the result to setTimeout. That leads to an infinite loop.
Instead, do this:
var func = function() { check(tab); };
setTimeout(func, 1000);
In your second example you construct a string which the JS interpreter
does new Function(...) with. That is inefficient. And your 'tab'
argument will also be converted into a string (with toString) which is
probably not correct. Instead, do this:
var func = function() { check(tab); };
setInterval(func, 5000);
Or if you want to do it the MochiKit way:
setInterval(bind(check, this, tab), 5000);
Cheers,
/Per
On Mon, Nov 17, 2008 at 6:30 AM, jonbutler88 [EMAIL PROTECTED] wrote:
Ok, so ive run into a brick wall with this loop. Here is what I have:
function init(tab) {
connect('editor','onload',function () {
if (document.getElementById
('editor').contentWindow.document.designMode != on)
{
document.getElementById
('editor').contentWindow.document.designMode = on;
}
document.getElementById('editor').contentWindow.focus();
setInterval(check(+tab+),5000);
});
}
function check(tab) {
var src = document.getElementById('editor').src;
if (src.substring(0,31) != my site.com)
{
alert(access violation);
removeElement(tab);
focusTab('ide_tab0', 'start.php');
}
}
But im running into problems with the loop. While it is running, the
rest of the page stops loading. Is there any way I can get the loop to
run in the background?
Thanks
On Nov 16, 2:25 pm, Jon Butler [EMAIL PROTECTED] wrote:
Yeah, that was my original thinking, but onload doesnt fire when I
change the src.
I tried using a loop before, but I thought it would be more efficient
to use a custom event. Thiinking about it, the listener would still
need to check when the src changes so it's pretty much the same
solution.
Il have another go and post back if I run into problems.
Cheers
On 16 Nov 2008, at 10:06, Yoann Aubineau [EMAIL PROTECTED]
wrote:
Yeah, turns out onchange doesnt detect the change in src
Maybe onload will do. I never use iframes so I can't say for sure it
will work on every browser. But it sounds like a logical try to me.
If the iframe's source changes on a link or button click, you can also
listen for those events, check if the iframe's source is actually
different from the previous value and then fire the custom event you
need.
Otherwise, setup a loop that check regulary iframe.src but … eark !
-- Yoann
2008/11/16 jonbutler88 [EMAIL PROTECTED]:
Yeah, turns out onchange doesnt detect the change in src Im gonna
have to write my own event by the looks of it, something that baffles
me a fair bit. Ive seen lots of tutorials using prototype, but none
that focus around mochikit Ive had a good look at the
mochikit.signal docs, but im no closer to understanding how to write
my event. Im clearer about how to attach the event and fire it, but
im
lost with how to define when it fires...
Thanks very much for your help so far :)
On Nov 14, 10:21 am, Yoann Aubineau [EMAIL PROTECTED]
wrote:
Assuming your iframe's id is foo, you would do :
connect(foo, onchange, function(e) {
logDebug($(foo).src);
});
Not sure what onchange event means on an iframe though.
Seehttp://mochikit.com/doc/html/MochiKit/Signal.html#fn-connectfor
more information about signals.
-- Yoann
2008/11/14 jonbutler88 [EMAIL PROTECTED]:
I have an iframe on a page, and im trying to write some ajax to
check
the src variable when onchange is called. However, it has to be
secure, so rather than include onchange='func()' in the HTML, I
have
to assign it with javascript. Im still pretty new to mochikit,
and im
wondering what the best way to set this up would be?
Thanks in advance, sorry if its a bit vague.
--~--~-~--~~~---~--~~
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: About action button
??? Cheers, /Per On Thu, Nov 13, 2008 at 4:08 AM, Reka Sandaruwan [EMAIL PROTECTED] wrote: how to create action button on tree node --~--~-~--~~~---~--~~ 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: DD + margin weirdness
We'd like to know: 1. Which web browser? Which OS? 2. Have you got an example to show this? Where is it? Please provide a URL. Cheers, /Per On Mon, Nov 10, 2008 at 10:43 PM, scipio [EMAIL PROTECTED] wrote: I have a div with a top margin of 35px laid out using fixed positioning, and when I drop something onto a box it misses by the size of the div's top margin. ie, so if I want the drop to work I have to offset my drop by the size of the top margin. Seems like the DD mechanism is ignoring the containing box's margins. --~--~-~--~~~---~--~~ 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: Signal All
On Fri, Nov 7, 2008 at 11:05 AM, Arnar Birgisson [EMAIL PROTECTED] wrote:
As I understood the example, the objects being modified take care of
calling signal(). E.g. a hash table that fires a signal when objects
are added, removed and even when there's a collision. Guilio Cesare
would like to be able to register for all signals. Perhaps a clearer
API would be to allow wildcards in the second parameter to connect().
I see...
This looks neat, and I have something similar implemented in many of
my apps (generally I generate the code from the Python server side -
i.e. any exposed ajax methods automatically get a corresponding JS
function). However, I invariably opt for using deferreds instead of
events.
E.g. what happens in this case:
dispatcher.getUser('john');
dispatcher.getUser('paul');
connect(dispatcher, getUser, doSomething);
Is doSomething called twice? Because maybe we want to do different
things depending if it is the response for John or for Paul -- and we
don't want to complicate doSomething with code to differentiate
between them.
I see your point. I'm not trying to remove deferreds or anything. I
like them as much as you (I think). But in my apps I frequently write
code to handle variations of the following issues:
1. I want a generic error handler for most of my AJAX calls. Adding
one to each Deferred works for me, but others will probably forget it
(and I'm writing a webapp framework).
2. Showing and hiding spinning icons, enabling and disabling fields or
buttons is kind of messy to add to a deferred, since functions added
with addCallback and addErrback must return the input value to keep
Deferred processing intact. I'd like to do these UI changes more like
signals, connecting UI widgets to oncall and onresponse signals for
certain calls.
3. Keeping references to the currently running Deferreds, so that I
can cancel them easily on certain (but not all) UI events.
Basically, I want to achieve a more declarative style of programming.
Where I can setup signals and server-calls at startup, minimizing the
amount of code required in each individual UI event handler. Ideally I
just want the applications to be routing signals between DOM elements,
helper functions, server-side functions, other applications, etc.
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: Signal All
I don't think I understand the use case where this type of thing would
come to use. Could you please provide a scenario? Is it useful in
libraries? Or widgets? Or webapps?
Otherwise, here is a quick review without much thought:
1. Using just signal.apply instead of MochiKit.Signal.signal.apply
causes problems if not exporting functions.
2. It might be unexpected by users that connecting to anySource and
anySignal, will only receive signals that are manually sent via the
signal() function. I.e. not the DOM signals.
3. The addition of these generic objects impose a penalty on all
manual signal sending, something which might not be desired. We should
probably look for minimizing the impact a bit here, I think.
4. The MochiKit.Signal.anySource and MochiKit.Signal.anySignal names
should perhaps be upper-case as they are constants. Also, for a user
it might be clearer to use something like null or undefined instead of
a constant from MochiKit.Signal.
Anyway. These were just a couple of random thoughts. I'm all for
finding ways to make it even easier to work with signals and
especially deferreds.
Cheers,
/Per
On Wed, Nov 5, 2008 at 2:15 PM, Giulio Cesare Solaroli
[EMAIL PROTECTED] wrote:
Hello,
I have just created a patch (attached) for the current MochiKit.Signal
implementation to achieve something very similar to the former
NotificationCenter.
I have also updated the relative tests.
I have not updated the documentation yet, but if you consider
including the patch into the repository, I will be pleased to update
the documentation too.
Any feedback is welcome.
Best regards,
Giulio Cesare
On Wed, Nov 21, 2007 at 11:32 AM, Giulio Cesare Solaroli
[EMAIL PROTECTED] wrote:
Here you are:
http://clipperz.googlecode.com/svn/trunk/src/js/Clipperz/NotificationCenter.js
Sorry again for the trouble.
Feel free to ask for any question.
Best regards,
Giulio Cesare
On 11/21/07, Giulio Cesare Solaroli [EMAIL PROTECTED] wrote:
Sorry My fault. :-(
I must have screwed something on the build script.
I will try to fix it as soon as possible. If you want to take a look
at the code in the meanwhile, the same code could be found buried with
the full source of our application (the code of the application is
released with a reference licence, not with the BSD licence used for
the crypto library).
You can find the link to the code and details on the licence here:
http://www.clipperz.com/learn_more/reviewing_the_code
I will post back as soon as I managed to commit the NotificationCenter
into the code.google SVN repository.
Sorry for the trouble.
Best regards,
Giulio Cesare
On 11/21/07, Per Cederberg [EMAIL PROTECTED] wrote:
Ehm... I couldn't find the NotificationCenter class anywhere in the
svn repo. Perhaps I'm looking at the wrong place? Found a reference
to the class here, but no source code:
http://clipperz.googlecode.com/svn/trunk/src/js/Clipperz/Crypto/PRNG.js
/Per
On Nov 15, 1:50 pm, Giulio Cesare Solaroli [EMAIL PROTECTED]
wrote:
Hello,
I have implemented a NotificationCenter class similar to the one
available on the MacOSX foundation library (rooted back in the NeXT
NSFoundation library).
The NotificationCenter allows loosely binding between notifying
objects and listeners, and it is included in the open source crypto
library we have released as part of our project.
There is no documentation, but the code should be quite clean, and
there are some automatic tests where you should get some ideas on how
to use it. For any other question, feel free to contact me.
You can find the library here:
-http://code.google.com/p/clipperz
If you are interested on our project, you can find all the details here:
-http://www.clipperz.com
Hope this helps.
Regards,
Giulio Cesare
On Nov 15, 2007 12:30 PM, Zsolt [EMAIL PROTECTED] wrote:
I needed the ability to have two or more objects of the same type talk
to each other and respond to each others events. For example when one
gets updated the other one should also do something. My first thought
was to use MochiKit.Signal.signal but that needs a source as a first
arg so that is not good because i do not know the name of the other
object so i modified signal and came up with
MochiKit.Base.update(MochiKit.Signal,{
'signalAll' : function(sig){
var self= MochiKit.Signal;
var observers = self._observers;
var args = MochiKit.Base.extend(null, arguments, 1);
var errors = [];
self._lock = true;
for (var i = 0; i observers.length; i++) {
var ident = observers[i];
if (ident.signal === sig ident.connected) {
try {
ident.listener.apply(ident.source, args);
} catch (e
[mochikit] Re: getElementDimensions() broken in IE7/6 in rev 1449
Ok, I'll add this to 1.4.2 then... But I'll wait a few more weeks until we have a few more issues to resolve. Did I understand you correctly that your pages include MochiKit in this way? script src=http://svn.mochikit.com/...; If that is the case, I'd urge you to download a copy of the packed file and deploy it on your own web server instead. Using svn.mochikit.com most probably leads to additional latencies, slower download and a high risk of temporary breakage. Cheers, /Per On Mon, Nov 3, 2008 at 8:47 PM, Brad Clements [EMAIL PROTECTED] wrote: It *does* work with r1465 (and I checked to be sure, it fails with r1464) thanks for the fast fix Per Cederberg wrote: Could you try again with r1465? Thanks for the excellent bug report, btw. Cheers, /Per -- Brad Clements,[EMAIL PROTECTED](315)268-1000 http://www.murkworks.com AOL-IM: BKClements --~--~-~--~~~---~--~~ 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: getElementDimensions() broken in IE7/6 in rev 1449
Could you try again with r1465?
Thanks for the excellent bug report, btw.
Cheers,
/Per
On Mon, Nov 3, 2008 at 6:05 PM, bkc [EMAIL PROTECTED] wrote:
I have a production site that is using this svn url:
http://svn.mochikit.com/mochikit/trunk/packed/MochiKit/MochiKit.js via
an external
after the last svn update blindUp($(id)) isn't working (see details
below)
I have checked out a bunch of back revs. It works in rev 1448, fails
in rev 1449 and onwards.
It fails in IE7 and IE 6.1
it does work fine w/ FF 2x
it looks to me like getElementDimensions() has changed in 2 ways:
1. tries to set the style.display to something other than
2. tries to set the style.display for tables to table which
apparently doesn't work in IE.
===
so in rev 1449 I get the error in MochiKit.js line 4197
working the callstack upwards from my code:
if(new_state == 'closed') {
blindUp($(id));
if(indicator) {
removeElementClass(indicator, 'hide');
addElementClass(indicator, 'show');
}
IE debugger command window:
id
master_headertable
typeof $(id)
object
$(id).id
master_headertable
up the callstack to blindUp()
MochiKit.Visual.blindUp=function(_6d7,_6d8){
var d=MochiKit.DOM;
_6d7=d.getElement(_6d7);
var _6da=MochiKit.Style.getElementDimensions(_6d7,true); /* line 6590
fails here)
var _6db=d.makeClipping(_6d7);
it is failing in line 6590
command window:
typeof _6d7
object
_6d7.id
master_headertable
up the callstack to getElementDimensions
getElementDimensions:function(elem,_448){
var self=MochiKit.Style;
var dom=MochiKit.DOM;
if(typeof (elem.w)==number||typeof (elem.h)==number){
return new self.Dimensions(elem.w||0,elem.h||0);
}
elem=dom.getElement(elem);
if(!elem){
return undefined;
}
var disp=self.getStyle(elem,display);
if(disp==none||disp==||typeof (disp)==undefined){
var s=elem.style;
var _44d=s.visibility;
var _44e=s.position;
var _44f=s.display;
s.visibility=hidden;
s.position=absolute;
s.display=self._getDefaultDisplay(elem); /* line 4197 fails here */
var _450=elem.offsetWidth;
var _451=elem.offsetHeight;
failing at line 4197
command window:
elem.id
master_headertable
self._getDefaultDisplay(elem)
table
typeof s
object
s.display
none
s.position
absolute
/* try setting the display mode */
s.display = 'block'
block
s.display = 'table'
Could not get the display property. Invalid argument.
--~--~-~--~~~---~--~~
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] MochiKit 1.4.1 released
MochiKit 1.4.1 has now been released and is available on the web site: http://mochikit.com/download.html This version contains the correction of a few issues found since the original 1.4 release: * Added export of deprecated MochiKit.DOM.computedStyle function (#324). * Fixed issue in MochiKit.Style.getElementDimensions when elements are hidden due to CSS class definitions (#325). * Moved makePositioned, undoPositioned, makeClipping and undoClipping from MochiKit.DOM to MochiKit.Style due to circular dependency (#327). * Fixed makeClipping and undoClipping to handle overflow-x and overflow-y styles correctly (#326). * Fixed issue with Event.relatedTarget() sometimes returning XUL elements in Mozilla-based browsers (#322). We are now back to zero known bugs in our stable release. Lets hope it lasts a bit longer than the last time around... :-) Our compability with version 1.3 should also be slightly improved due to fixing #324. Many thanks for the excellent bug reports that helped finding and fixing these issues! 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: Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
There is a new (hopefully working) version of the download page available now: http://mochikit.com/pack.html It only provides customized downloads from svn trunk at the moment. And due to the default packed version not including all modules, some modules are not available... If you have time, please try this out a bit. And report any issues here, so that I'll have them fixed to the final version. 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: 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
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
-~--~~~~--~~--~--~---
[mochikit] Re: Sending a signal to a DOM element
Actually, I think the whole API for the signal() function needs to be
sanity-checked. It works rather poorly if you want to send non-DOM
signals to DOM objects for instance (if you've invented your own
signals for example).
Just waiting for that day when I have loads of spare time on my hands
again... :-)
Meanwhile, feel free to drop me a documentation patch. We are very
liberal with accepting those.
Cheers,
/Per
On Wed, Oct 29, 2008 at 2:16 PM, Eoghan [EMAIL PROTECTED] wrote:
Great,
What I came up with was:
signal('my-anchor-id', 'onclick', {stop: noop});
Maybe this would be a good edge case example to add to the docs under
Synopsis - Signal for DOM events:
Eoghan
On Oct 29, 12:04 pm, Per Cederberg [EMAIL PROTECTED] wrote:
The documentation isn't very good at this point. But you probably want
to mock the browser event object:
var fakeEvent = {};
signal('my-anchor-id', 'onclick', fakeEvent);
You might have to add various properties to the fake event object in
order for your code to work. See the implementation of the
MochiKit.Signal.Event class:
http://trac.mochikit.com/browser/mochikit/trunk/MochiKit/Signal.js
Cheers,
/Per
On Wed, Oct 29, 2008 at 11:41 AM, Eoghan [EMAIL PROTECTED] wrote:
I have the following:
connect('my-anchor-id', 'onclick', function(e){
// Do some stuff
e.stop();
});
I also want to click the anchor on page load, so I have this
elsewhere:
signal('my-anchor-id', 'onclick');
Unfortunately this throws the error 'this._event is undefined' when it
encounters e.stop();
The following also throws the error
connect('my-anchor-id', 'onclick', function(e){
// Do some stuff
if(e){ e.stop(); }
});
The only thing that works is the hacky:
connect('my-anchor-id', 'onclick', function(e){
// Do some stuff
if(e._event){ e.stop(); }
});
Is this a rough edge or am I doing it wrong?
Eoghan
--~--~-~--~~~---~--~~
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: Google hosting of MochiKit?
It has been discussed previously here on the list, but since 1.4 wasn't released then I don't think anybody bothered to do anything. With version 1.4 finally out there, perhaps the time for action is now? Feel free to try to contact Google about this. Personally I wouldn't bother, since I've only had the /dev/null experience every time I've tried to contact them before. :-( Cheers, /Per On Tue, Oct 28, 2008 at 1:16 PM, Jesper [EMAIL PROTECTED] wrote: Have you considered trying to get MochiKit into Googles AJAX Libraries API? http://code.google.com/apis/ajaxlibs/ It would be an advantage from a MochiKit user perspective since it will speed up the download of the library (taking advantage of the fact that Google has servers located around the world and that it would be served from the server closest to the user). This is especially relevant for web sites with global ambitions (otherwise they will have to use a Content Delivery Network for this job). There will also be a few other advantages: You don't have to update your MochiKit library manually when bug fixes come out and you don't have to worry about setting cache headers. Best regards, Jesper --~--~-~--~~~---~--~~ 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: Suggested API:s for MochiKit 1.5
On Mon, Oct 27, 2008 at 11:34 AM, SanderElias [EMAIL PROTECTED] wrote: 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 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] Handling display: none in getElementDimensions
I just ran into a bug that I can't resolve. At least I'm out of ideas right now: http://trac.mochikit.com/ticket/325#comment:2 The problem is when using getElementDimensions() on elements having display: none set in the CSS class. Or in a parent element. Is there a work-around for this? Or do we have to give up and just document this? 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: Handling display: none in getElementDimensions
Thanks for the suggestion, but that sort of code is already in
getElementDimensions I think:
if (disp == 'none' || disp == '' || typeof(disp) == 'undefined') {
var s = elem.style;
var originalVisibility = s.visibility;
var originalPosition = s.position;
var originalDisplay = s.display;
s.visibility = 'hidden';
s.position = 'absolute';
s.display = '';
var originalWidth = elem.offsetWidth;
var originalHeight = elem.offsetHeight;
s.display = originalDisplay;
s.position = originalPosition;
s.visibility = originalVisibility;
} else {
originalWidth = elem.offsetWidth || 0;
originalHeight = elem.offsetHeight || 0;
}
Only the block/inline/whatever part uses . Which works nicely if
the style property is set on the element itself. But not on in the CSS
class.
So, I think we're still stuck... :-(
Cheers,
/Per
On Mon, Oct 27, 2008 at 12:44 PM, Andreas Marienborg
[EMAIL PROTECTED] wrote:
On Oct 27, 2008, at 12:30 PM, Per Cederberg wrote:
I just ran into a bug that I can't resolve. At least I'm out of ideas
right now:
http://trac.mochikit.com/ticket/325#comment:2
The problem is when using getElementDimensions() on elements having
display: none set in the CSS class. Or in a parent element. Is there
a work-around for this? Or do we have to give up and just document
this?
You might have tried this, but I think we once did some trickery with
visibility: hidden to get the size of display: none blocks.
Basicly you set position: absolute and visibility: hidden, then change from
display: none to display: block/inline/whatever
Then you get the dimensions
And set everything back
- andreas
--~--~-~--~~~---~--~~
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: Handling display: none in getElementDimensions
There are more display types than block, unfortunately. Hence the
hack with . In particular, the display types table and inline
are rather common. Perhaps we should write some utility function or
lookup table that returns the default display type for a tagName?
Ugly, but doable.
But I think we would remain broken if a parent element has display:
none. What to do about that?
Cheers,
/Per
On Mon, Oct 27, 2008 at 1:34 PM, Yoann Aubineau
[EMAIL PROTECTED] wrote:
Why not set s.diplay to 'block' instead of an empty string ? It
actually works for me (Safari 3+, Firefox 2+, IE 6+). But there may be
a trick I'm not aware of that explains this particuliar choice.
2008/10/27 Per Cederberg [EMAIL PROTECTED]:
Thanks for the suggestion, but that sort of code is already in
getElementDimensions I think:
if (disp == 'none' || disp == '' || typeof(disp) == 'undefined') {
var s = elem.style;
var originalVisibility = s.visibility;
var originalPosition = s.position;
var originalDisplay = s.display;
s.visibility = 'hidden';
s.position = 'absolute';
s.display = '';
var originalWidth = elem.offsetWidth;
var originalHeight = elem.offsetHeight;
s.display = originalDisplay;
s.position = originalPosition;
s.visibility = originalVisibility;
} else {
originalWidth = elem.offsetWidth || 0;
originalHeight = elem.offsetHeight || 0;
}
Only the block/inline/whatever part uses . Which works nicely if
the style property is set on the element itself. But not on in the CSS
class.
So, I think we're still stuck... :-(
Cheers,
/Per
On Mon, Oct 27, 2008 at 12:44 PM, Andreas Marienborg
[EMAIL PROTECTED] wrote:
On Oct 27, 2008, at 12:30 PM, Per Cederberg wrote:
I just ran into a bug that I can't resolve. At least I'm out of ideas
right now:
http://trac.mochikit.com/ticket/325#comment:2
The problem is when using getElementDimensions() on elements having
display: none set in the CSS class. Or in a parent element. Is there
a work-around for this? Or do we have to give up and just document
this?
You might have tried this, but I think we once did some trickery with
visibility: hidden to get the size of display: none blocks.
Basicly you set position: absolute and visibility: hidden, then change from
display: none to display: block/inline/whatever
Then you get the dimensions
And set everything back
- andreas
--~--~-~--~~~---~--~~
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: questioning MochiKit.Signal dependency on MochiKit.Style
This has been discussed earlier and I closed the ticket myself: http://trac.mochikit.com/ticket/299 But perhaps it would be worth changing the documented API for this? What do other people think? Cheers, /Per On Mon, Oct 27, 2008 at 6:27 PM, Giulio Cesare Solaroli [EMAIL PROTECTED] wrote: Hello, I was taking a closer look at MochiKit.Signal in order to find a way to include some added options illustrated here: http://trac.mochikit.com/ticket/155 Looking at the code, I saw the declared dependency of MochiKit.Signal from MochiKit.Style; the reason for this dependency is to include some coordinate logic in order to process some mouse events. Wouldn't it be better to avoid including all MochiKit.Style just for a tiny chunk of convenience? In the packed version of MochiKit this inclusion does not make any difference, but if you are building your own packaged version, I would find very inconvenient to require the inclusion of MochiKit.Style. Best regards, Giulio Cesare --~--~-~--~~~---~--~~ 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: Ajax request returns
Actually, I think the documentation for roundElement and roundClass
should be clearer regarding these limitations. From reading the docs,
it is not obvious that only block elements are accepted (my guess).
And what do these methods really change in the DOM tree? A simple
explanation might help people avoid this issue altogether.
Could somebody on the list suggest a clarified wording? If you have
the time or interest, of course...
Cheers,
/Per
On Sun, Oct 26, 2008 at 7:27 PM, troels knak-nielsen [EMAIL PROTECTED] wrote:
On Sun, Oct 26, 2008 at 4:20 AM, Arnar Birgisson [EMAIL PROTECTED] wrote:
Have you tried...
AjaxUpdater = function (id, page) {
var d = doSimpleXMLHttpRequest(page);
d.addCallback(function (req) {
getElement(id).innerHTML = req.responseText;
adding it here
...
If I'm not mistaken, you can't access nodes through the DOM api
immediately after assigning through innerHTML. The nodes don't exist
until the current event has ended. A simple solution is to set a
timeout of 1 millisecond and do it in there. Eg.:
AjaxUpdater = function (id, page) {
var d = doSimpleXMLHttpRequest(page);
d.addCallback(function (req) {
getElement(id).innerHTML = req.responseText;
setTimeout(
function() {
// adding it here
}, 1);
...
--
troels
--~--~-~--~~~---~--~~
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: MochiKit 1.4 released
Ok, I think it is fixed now. New version is available on the download page. I have not bumped the version number, since it is just a packaging issue. The root cause seems to be the following Zip handling bug in Python: http://bugs.python.org/issue3394 Due to this fix, I've also been forced to reluctantly inaugurate a brand new svn branch for 1.4. Please add any regression fixes to 1.4 there (and drop a mail on the list). Thanks, /Per On Fri, Oct 24, 2008 at 8:51 AM, Per Cederberg [EMAIL PROTECTED] wrote: Yes, I noted the same thing yesterday. Seems to be an issue with permissions for all generated files. I'm building this on Linux and the input files seem to have correct permissions on my machine. But after packing and unpacking something weird happens. I'll look into this. Seems to be an issue with zipfile.ZipFile and in particular the writestr function in Python. Perhaps somebody else knows what is going on there? Cheers, /Per On Fri, Oct 24, 2008 at 8:23 AM, Amit Mendapara [EMAIL PROTECTED] wrote: Hello Per, Several files in the downloadable zip package have permission issues (on Linux). Please make sure that it's packaged properly with correct access permissions. - Amit Mendapara On Oct 21, 3:32 pm, Per Cederberg [EMAIL PROTECTED] wrote: MochiKit 1.4 has now been released and is available on the web site: http://mochikit.com/download.html The full change history from version 1.3.1 is rather lengthy, but you can find it on our web site: http://mochikit.com/doc/html/MochiKit/index.html#version-history As far as I know, there should be no backwards-incompatible API changes between 1.3.1 and 1.4. If you happen to find one, please let us know through this mailing list so that we can update the docs and/or fix the issues. Finally, many thanks to everyone who contributed code, documentation, bug reports, ideas and everything else during this long development cycle. Looking forward to hear from you all during the 1.5 development. 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: MochiKit 1.4 released
Yes, I noted the same thing yesterday. Seems to be an issue with permissions for all generated files. I'm building this on Linux and the input files seem to have correct permissions on my machine. But after packing and unpacking something weird happens. I'll look into this. Seems to be an issue with zipfile.ZipFile and in particular the writestr function in Python. Perhaps somebody else knows what is going on there? Cheers, /Per On Fri, Oct 24, 2008 at 8:23 AM, Amit Mendapara [EMAIL PROTECTED] wrote: Hello Per, Several files in the downloadable zip package have permission issues (on Linux). Please make sure that it's packaged properly with correct access permissions. - Amit Mendapara On Oct 21, 3:32 pm, Per Cederberg [EMAIL PROTECTED] wrote: MochiKit 1.4 has now been released and is available on the web site: http://mochikit.com/download.html The full change history from version 1.3.1 is rather lengthy, but you can find it on our web site: http://mochikit.com/doc/html/MochiKit/index.html#version-history As far as I know, there should be no backwards-incompatible API changes between 1.3.1 and 1.4. If you happen to find one, please let us know through this mailing list so that we can update the docs and/or fix the issues. Finally, many thanks to everyone who contributed code, documentation, bug reports, ideas and everything else during this long development cycle. Looking forward to hear from you all during the 1.5 development. 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: Selector speedup by using John Resig's Sizzle
My guess would be that the speed difference stems from the Sizzle strategy of searching inside-out from the expression. I.e. using the last part of the query first, and then filtering that set using the previous parts. Perhaps other libraries search outside-in? In the case of ul .tocline2 the approach taken by Sizzle seems to fare especially poorly (compared to the others). Of course, this issue would only affect cases where we are using parent-child relations. Cheers, /Per - running IE6 inside CrossOver, so that might slow down my results a bit too On Thu, Oct 23, 2008 at 6:12 PM, John Resig [EMAIL PROTECTED] wrote: Oh, I forgot to mention that I put the test suite online here: http://ejohn.org/apps/sizzle/test/ and the performance suite is here: http://ejohn.org/apps/sizzle/speed/ Taking a quick peek at IE 6 I see a lot of areas in which small improvements could yield large results (div p, div + p, .class). As it is it's faster than all the other major libraries. DOMAssistant has some tricks which could definitely help here so I'll investigate and report back. --John On Thu, Oct 23, 2008 at 11:37 AM, John Resig [EMAIL PROTECTED] wrote: Hey All - Sizzle is now passing the test suite 100% in IE 6, Firefox 3, and Safari 3.1. There is one failing test in Firefox 3.1b1 and in Opera 9.6 (both are specific browser bugs, and relatively minor, so I'm filing those with the vendors). I've fixed all of the previously-discussed issues in this thread. With compliance in order I want to look back and tackle two things: - Library-specific hook code (it's looking likely that Sizzle might make its way in to jQuery, MochiKit, Dojo, and Prototype). - Speed (the performance in IE can still use some work so I'm looking in to that) --John On Mon, Oct 20, 2008 at 12:13 PM, Arnar Birgisson [EMAIL PROTECTED] wrote: On Mon, Oct 20, 2008 at 17:40, John Resig [EMAIL PROTECTED] wrote: I don't know what other MochiKitters say about including Sizzle.js as a seperate file. Per, Bob? So it seems like the major difference is that your selector method (findChildElements) is able to take an array of results, correct? Yes, correct. This is something we inherited from Prototype, from where the current Selector module was ported. Perhaps we should change the API, I don't know.. cheers, Arnar --~--~-~--~~~---~--~~ 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] MochiKit 1.4 released
MochiKit 1.4 has now been released and is available on the web site: http://mochikit.com/download.html The full change history from version 1.3.1 is rather lengthy, but you can find it on our web site: http://mochikit.com/doc/html/MochiKit/index.html#version-history As far as I know, there should be no backwards-incompatible API changes between 1.3.1 and 1.4. If you happen to find one, please let us know through this mailing list so that we can update the docs and/or fix the issues. Finally, many thanks to everyone who contributed code, documentation, bug reports, ideas and everything else during this long development cycle. Looking forward to hear from you all during the 1.5 development. 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: Selector speedup by using John Resig's Sizzle
Of course, FF 3.1 includes querySelectorAll:
http://ejohn.org/blog/queryselectorall-in-firefox-31/
And in fact, there is a slight bug in Sizzle here, causing it to not
use that version when not sending in an explicit 2:nd argument:
Sizzle(..., document)
The problem is here:
if ( document.querySelectorAll ) (function(){
var oldSizzle = Sizzle;
Sizzle = function(query, context, extra){
if ( context === document ) {
try {
return makeArray(context.querySelectorAll(query));
} catch(e){}
}
return oldSizzle(query, context, extra);
};
Sizzle.find = oldSizzle.find;
Sizzle.filter = oldSizzle.filter;
})();
Cheers,
/Per
On Mon, Oct 20, 2008 at 4:05 PM, Arnar Birgisson [EMAIL PROTECTED] wrote:
Hi John,
On Mon, Oct 20, 2008 at 15:52, John Resig [EMAIL PROTECTED] wrote:
That's... odd. Are there any selectors that are noticeably faster?
Yes, it seems that nested queries are to blame. By nested queries I
mean queries that uses the axis combinator, either the implicit
descendant axis (like div p) or an explicit axis combinator such
as ~, or +.
div ~ p is 2ms on MK+Sizzle vs. 13ms on Sizzle.
div p is 2ms on MK+Sizzle vs. 4ms on Sizzle.
div p is 1ms vs. 3ms
div + p is 1ms vs. 5ms
div p a is 1ms vs. 8ms
Also, a[href][lang][class] is 1ms vs. 9ms.
Maybe something is failing?
I don't think so, at least the number of elements returned by each is
the same in every test.
You can run the test benchmark yourself here:
http://www.hvergi.net/arnar/public/sizzle/speed/
cheers,
Arnar
--~--~-~--~~~---~--~~
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: MochiKit.DOM.isChildNode and isParent
Ok, since r1433 MochiKit.DOM.isParent is no more. /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: MochiKit.DOM.isChildNode and isParent
Attempting two answers in one below...
On Sat, Oct 18, 2008 at 12:23 AM, Jason Bunting
[EMAIL PROTECTED] wrote:
Who is Noone? :P
Sigh... The endless joys we bring you native English speakers... ;-)
On Sat, Oct 18, 2008 at 5:54 PM, Christoph Zwerschke [EMAIL PROTECTED] wrote:
Hm, if I read the code correctly, then there is another difference,
namely that isChildNode also returns true if the second node is not the
direct parent, but also for grandparents and any ancestors. So it should
be actually renamed to something like isDescendant or isAncestor.
Both actually do that. But isParent() does it through recursion
instead of iteration:
isParent: function (child, element) {
var self = MochiKit.DOM;
if (typeof(child) == string) {
child = self.getElement(child);
}
if (typeof(element) == string) {
element = self.getElement(element);
}
if (child == null || element == null) {
return false;
} else if (!child.parentNode || child == element) {
return false;
} else if (child.parentNode == element) {
return true;
} else {
return self.isParent(child.parentNode, element);
}
},
I totally agree on the naming. Should be named as you propose, but I
don't see us changing the API right now though... :-(
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] Last call for MochiKit 1.4
Hi everyone, This is just to say that I'm still planning to do the MochiKit 1.4 release on the 21:st of October. All outstanding bugs remain fixed and I've heard of no test breakage. Please let me know if you find any last-minute-issues. 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: MochiKit.DOM.isChildNode and isParent
Noone has opinions on this? Cheers, /Per On Wed, Oct 8, 2008 at 3:51 PM, Per Cederberg [EMAIL PROTECTED] wrote: The two functions MochiKit.DOM.isChildNode and isParent have both been added in version 1.4 of MochiKit (not yet stable). But they are virtually identical (except for a few bugs I'm in fixing right now). The only difference, according to the API docs, as far as I can tell is: isChildNode(node, node) -- true isParent(node, node) -- false Is it not pointless to keep both functions around? Since isChildNode() is more tested (and probably more used), I'd suggest removing isParent() from the API before the 1.4 release. Possibly, in order to simplify the transition, we could just alias isParent to isChildNode (and remove the API doc specification so that noone will use it from now on). Opinions? Cheers, /Per PS. I just discovered that Google Groups silently dropped all my emails that used another sender address, so I'm currently resending all my recent postings. Hence the sudden email bombing... --~--~-~--~~~---~--~~ 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: Selector speedup by using John Resig's Sizzle
On Wed, Oct 15, 2008 at 1:01 PM, Arnar Birgisson [EMAIL PROTECTED] wrote:
Done. Yup, the number of nodes is not correct (or at least as correct
as th other frameworks). Performance takes a minor hit, mainly because
it is so bad to begin with :)
Ah, you mean now correct... :-)
Disturbing that this fix actually affects performance in a noticable
way. It really shouldn't, except when more than ~100 elements are
matched. Perhaps there are some obvious improvements to be made in my
uniq() implementation:
var uniq = function(arr) {
var res = [];
for (var i = 0; i arr.length; i++) {
if (MochiKit.Base.findIdentical(res, arr[i]) 0) {
res.push(arr[i]);
}
}
return res;
};
I think the above should be O(n^2). Not optimal, but fixing the root
cause means rewriting the module altogether. :-(
Me too. The current implementation is quite bad and it is my fault for
not updating it since the early Prototype port. Sizzle is quite
simple, there are no specific tricks to make it fast, but the design
is nice.
Yes, it is much clearer. I have a few opinions about it of course, but
I think I'll fork the Sizzle project on github to fix those when/if I
have time.
Many thanks for your help, Arnar!
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: Selector speedup by using John Resig's Sizzle
I think I fixed the MochiKit.Selector issue with div ~ p in r1429 by adding a uniqueness filter on the results from MochiKit.Selector.findChildElements. Unless the number of returned results is very high it should not degrade performance much. And naturally, this should also fix the issue for div p. Arnar, could you add a new trunk MochiKit to your speed comparison page? Otherwise, I look forward to replacing the current implementation that is based on eval usage, poor query parsing and slow set handling. Not much fun to debug at all, actually... Cheers, /Per On Wed, Oct 15, 2008 at 10:21 AM, Arnar Birgisson [EMAIL PROTECTED] wrote: Hi Per, On Wed, Oct 15, 2008 at 10:15, Per Cederberg [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 9:28 PM, Arnar Birgisson [EMAIL PROTECTED] wrote: div p MK trunk returns 142 elements while others return 140 (both numbers are reported incorrect though). The *set* of elements is the same, but MK repeats some elements, which is of course not correct. This seems to happen in the situation where one has divdivp.../p/div/div. If one forgets about performance, this is trivial to fix in MK - but a reasonably performing one might be more tricky. I'll let this one pass. It is slightly incorrect, but can be worked-around by users until 1.5 comes along. I agree. div ~ p MK returns 4120 (!) elements here where others return 183 (both numbers are again considered wrong by SlickSpeed). This is clearly a bug I'll try to fix this. Filed as http://trac.mochikit.com/ticket/321 Thanks, let me know if you have problems. I'm sorry I don't have time to help more these days, I have a few deadlines and a conference coming up in the next two weeks. cheers, Arnar --~--~-~--~~~---~--~~ 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: Selector speedup by using John Resig's Sizzle
I'd appreciate bug reports for the MochiKit.Selector module in Trac or here on the list. I've got 1-2 previously here in this thread that I intend to have a look at soon. Either way, I think we are beyond removing MochiKit.Selector entirely for 1.4. I'll update the docs to point out that it is an *experimental* module that is subject to change. Also, I'll add specific notes for those selectors that won't be compatible with the new Sizzle-powered version. Cheers, /Per On Mon, Oct 13, 2008 at 2:43 PM, Amit Mendapara [EMAIL PROTECTED] wrote: I have seen many problems with MochiKit.Selector while testing MochiKit.Query module. As `Per Cederberg` is preparing for 1.4 release, I think MochiKit.Selector should not be included in 1.4, but let we get something really useful with Sizzle which is going to be integrated in MochiKit (hopefully MochiKit 1.5)... - Amit Mendapara --~--~-~--~~~---~--~~ 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: Selector speedup by using John Resig's Sizzle
On Mon, Oct 13, 2008 at 3:13 PM, Amit Mendapara [EMAIL PROTECTED] wrote: Once, I filed a bug report on the trac (related to Sortables), but I was unable to change/comment it later. That's why I never submitted again. Yes, this is very unfortunate. I used to have the same problem, so I hear you loud and clear. The problem is the amount of spam that we'd otherwise receive in bug reports. Don't know if there is some newer version of Trac that fixes this that we could install on the server. Or if there is some other solution that would work. Until that happens, emailing to this list or directly to the bug owner should work. Sorry about that. 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: Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
Seeing that this wasn't just an omission, I won't change it for the 1.4 version. For version 1.5 I think we should consider having a nice little download web page where you can customize your packed version of MochiKit. I created a little dummy UI to show what I mean: http://www.percederberg.net/mochikit/pack.html If we plunge forward and start adding more extension modules (as suggested here before), I think such a UI would be important to keep all users happy. Cheers, /Per On Wed, Oct 8, 2008 at 3:44 PM, Arnar Birgisson [EMAIL PROTECTED] wrote: Hi Per, On Wed, Oct 8, 2008 at 15:38, Per Cederberg [EMAIL PROTECTED] wrote: The packed version of MochiKit still doesn't include the modules DragAndDrop and Sortable. I found a previous discussion of that in this thread: http://groups.google.com/group/mochikit/browse_thread/thread/9d3a82cd7b165e73/70b954863b717c99 None of the two modules have been much modified lately, so perhaps they are now stable? Otherwise, I think we should make the docs clearer regarding their status and how to use them. Including them is fine with me, but for my own purposes I don't use that.. since for me MochiKit serves purely as a utility library rather than one of UI elements. I suspect there are others in a similar situation. What we really should do, and it should not be too hard, is make several packed versions. Basically for every module we'd provide a dependency-closed packed version - i.e. one that includes that module and all of its dependencies. Modifying the packed script to perform this should be doable. If people don't like the idea of so many packed versions, perhaps we could decide on two or three feature-sets and provide packed versions of these. I know MochiKit is not that big, and download time is not really the issue - but bandwidth can be an issue for the host. cheers, Arnar --~--~-~--~~~---~--~~ 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: Migrate to Google Code?
Google code seems fine by me. Especially if we get better access for normal users. The only issue I come to think of is that the mochikit.com web site automatically updates from svn trunk. Don't know if it would be easy to keep that link. Something which is pretty good to have from time to time. Especially when we are linking to examples and demos that are actually inside the project repo (not just on the web site). On the other hand, we often forget to make_docs.py or pack.py before committing to svn. So perhaps it would be good to have these steps performed automatically by some automated web publisher. So that we wouldn't need the packed version in svn... Just my random thoughts. Cheers, /Per On Mon, Oct 13, 2008 at 6:17 PM, Bob Ippolito [EMAIL PROTECTED] wrote: I've been considering this for a while but didn't want to put forth the effort at the time, but I think that with the release of 1.4 it would be a good time to migrate from the Mochi Media hosted Trac and SVN over to something else. My personal preference is Google Code because we already use that for our other open source projects and it wouldn't require transitioning from a mainstream VC solution to something more obscure (e.g. launchpad, github). Per, do you have any thoughts on this? -bob --~--~-~--~~~---~--~~ 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: Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
On Mon, Oct 13, 2008 at 2:24 PM, Arnar Birgisson [EMAIL PROTECTED] wrote: Minor usability pointer: When unselecting a module, instead of unselecting everything that depends on it - highlight the relevant part of uses XXX of those in some /error/ color. I fooled around a bit with the visual effects instead... http://www.percederberg.net/mochikit/pack.html 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: Why doesn't removeElement use the DOM Coercion rules?
On Thu, Oct 9, 2008 at 6:50 PM, Jason Bunting [EMAIL PROTECTED] wrote: Well... I think your case here is pretty uncommon. This is because the __dom__() function is really supposed to create a *new* DOM node. Otherwise people might run into issues when adding an object twice into the DOM tree. Excuse my ignorance, and permit me to ask a few questions so I can explore this further... Line item 6 in the DOM Coercion Rules, as posted in the documentation, states: 6. Objects that have a .dom(node) or .__dom__(node) method are called with the parent node and their result is coerced using these rules. So, perhaps there is some confusion because of the documentation, but I don't see how my example code violates anything. There is no specification on this, it is just kind of what you'd expect. Why would otherwise the parent node be an input parameter? If the result is constant, no parameter in the world can change that. I am confused by your statement that Otherwise people might run into issues when adding an object twice into the DOM tree - using my example, if someone were to try to add myWidgetInstance to the DOM twice, the behavior would be exactly as I would expect it - it is the same instances, and thus it would only appear once (because the call to __dom__ would return the same instance). If the developer doesn't understand that this would happen, then they have other problems. Unless they instantiate another instance, there should only be one. I wasn't thinking about widgets, but rather situations were you'd added a dom() method to various other objects. For convenience. But sure, there is an inconsistency here. My suggestion would be to just work around it instead: removeElement(myWidgetInstance.widgetDomRepresentation); IMO, that's terrible. It breaks encapsulation because now something that should be private is made explicitly public. I don't want a workaround, I want consistency in MochiKit's API. I shouldn't start an OO discussion here, but in my opinion the fields in an object are all public unless names are prefixed with an _. I appreciate your comments, and while an API for widget building may provide some useful help, it isn't what I am looking for at the moment. The way I have built widgets up to now (successfully, and for quite a while) is pretty much the way my example implies. It works beautifully and is simple enough to be understood without an entire widget framework (notwithstanding the fact that some help from using one might eventually be better than my approach). I would simply like some consistency in the API - the following functions all use the DOM Coercion Rules: appendChildNodes insertSiblingNodesBefore insertSiblingNodesAfter createDOM replaceChildNodes ... If those do, so should any of the others that expect DOM elements: removeElement swapDOM ... Ehm... The proposed MochiKit.Widget isn't an entire widget framework. I just pointed at it for example, not to force you to change your code or your ways. I don't oppose changing there MochiKit.DOM functions, I'm just of the opinion that it isn't much of a problem. And if it is, I'd suggest that we check typeof(o.dom) == object or something. So that we know for sure that what is being removed is an existing DOM node, not something that was created by our call to o.dom()... Also, doing that would increase our compability with Dojo et al. 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: Why doesn't removeElement use the DOM Coercion rules?
Well... I think your case here is pretty uncommon. This is because the
__dom__() function is really supposed to create a *new* DOM node.
Otherwise people might run into issues when adding an object twice
into the DOM tree.
But sure, there is an inconsistency here. My suggestion would be to
just work around it instead:
removeElement(myWidgetInstance.widgetDomRepresentation);
Actually, other widget libraries tend to use the magic dom property
for storing the root DOM node in the widget. Personally, I'd recommend
using a mixin approach to widgets, just as I've done in the suggested
MochiKit.Widget library:
http://github.com/cederberg/mochikit-patches/tree/master/MochiKit/Widget.js
Cheers,
/Per
On Thu, Oct 9, 2008 at 1:01 AM, Jason Bunting
[EMAIL PROTECTED] wrote:
I don't know if I am up in the night on this or if it is an oversight, but
why doesn't removeElement use the DOM Coercion rules in the same way that
something like appendChildNodes does? Here's some sample code that
illustrates my problem:
function MyWidget() {
var widgetDomRepresentation = DIV({style:border:solid 1px}, Hi!);
var that = this;
connect(widgetDomRepresentation, onclick, function() {
signal(that, removeme);
});
this.__dom__ = function() {
return widgetDomRepresentation;
};
}
var myWidgetInstance = new MyWidget();
connect(myWidgetInstance, removeme, function() {
removeElement(myWidgetInstance); // this blows up
});
appendChildNodes(currentDocument().body, myWidgetInstance);
It seems to make little sense that one can append myWidgetInstance to the
DOM using MochiKit.DOM functions, but can't remove it just as easily.
Am I missing something here?
Jason Bunting
--~--~-~--~~~---~--~~
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] Including MochiKit.DragAndDrop and MochiKit.Sortable in the packed version?
The packed version of MochiKit still doesn't include the modules DragAndDrop and Sortable. I found a previous discussion of that in this thread: http://groups.google.com/group/mochikit/browse_thread/thread/9d3a82cd7b165e73/70b954863b717c99 None of the two modules have been much modified lately, so perhaps they are now stable? Otherwise, I think we should make the docs clearer regarding their status and how to use them. Cheers, /Per PS. I just discovered that Google Groups silently dropped all my emails that used another sender address, so I'm currently resending all my recent postings. Hence the sudden email bombing... --~--~-~--~~~---~--~~ 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: Class inheritance
Perhaps the problem is that you've already used bindMethods on the Helper class before subclassing? That might break the inheritance depending on how the code looks, since it reassigns the this object pointer to another instance. Also, you must use the new keyword, or it won't work: other.prototype = new Helper(); Keeping the scope for DOM events is one of the points with MochiKit.Signal: connect(elem, onclick, obj, method); Or one could use bind when setting each callback. Using bindMethods is also ok, within some constraints. /Per On Wed, Oct 8, 2008 at 12:56 AM, Akari no ryu [EMAIL PROTECTED] wrote: other.prototype = Helper doesn't help. Since bindMethods has made sure that 'this' always refers to the class that it was invoked in, the methods loose scope when you use them. Troels, the problem with using prototypical inheritance is that you end up losing scope in, for example, AJAX request responses or DOM event handlers. --~--~-~--~~~---~--~~ 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] MochiKit.Test and SimpleTest.js
While fixing some stuff in MochiKit.Logging, I happened to notice the existance of a MochiKit.Test package... It seems pretty similar to the SimpleTest.js file used for powering the normal test suite when run inside a browser, but it seems to only be used when standalone testing is performed (e.g. from the scripts/rhinomochi.js file). But there are some subtle differences. For example, the is function uses == in SimpleTest, but is based on compare() in MochiKit.Test. So that kind of breaks some of my tests... Anyone knows why we seem to have two test engines? Or what the relevant differences are? Cheers, /Per PS. I just discovered that Google Groups silently dropped all my emails that used another sender address, so I'm currently resending all my recent postings. Hence the sudden email bombing... --~--~-~--~~~---~--~~ 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: MochiKit.Test and SimpleTest.js
Ok. I added an enhancement ticket so that I won't forget about it: http://trac.mochikit.com/ticket/320 Thanks for the info! /Per On Wed, Oct 8, 2008 at 4:20 PM, Leo Soto M. [EMAIL PROTECTED] wrote: On Wed, Oct 8, 2008 at 9:46 AM, Per Cederberg [EMAIL PROTECTED] wrote: While fixing some stuff in MochiKit.Logging, I happened to notice the existance of a MochiKit.Test package... It seems pretty similar to the SimpleTest.js file used for powering the normal test suite when run inside a browser, but it seems to only be used when standalone testing is performed (e.g. from the scripts/rhinomochi.js file). But there are some subtle differences. For example, the is function uses == in SimpleTest, but is based on compare() in MochiKit.Test. So that kind of breaks some of my tests... Anyone knows why we seem to have two test engines? Or what the relevant differences are? On http://groups.google.com/group/mochikit/browse_thread/thread/e55df230ee3ef897 is the thread about the inclusion of SimpleTest into MochiKit. Looks like the idea always was to merge it with MochiKit.Test, but nobody had the time to do it. -- Leo Soto M. http://blog.leosoto.com --~--~-~--~~~---~--~~ 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: Preparing for a MochiKit 1.4 release
On Wed, Oct 8, 2008 at 4:26 PM, troels knak-nielsen [EMAIL PROTECTED] wrote: 9.50 Alpha .. 8 failures in test_MochiKit-Style.html not ok - initial x position: got 444, expected 400 not ok - initial y position: got 111, expected 100 not ok - updated x position: got 544, expected 500 not ok - updated y position: got 211, expected 200 not ok - updated x position (using relativeTo parameter): got 444, expected 400 not ok - updated y position (using relativeTo parameter): got 111, expected 100 not ok - updated only x position: got 344, expected 300 not ok - not updated y position: got 211, expected 200 In Opera 9.50 Beta 2 they added support for getBoundingClientRect, so then the test won't break anymore (taking another code path inside MochKit.Style.getElementPosition actually). Would that be ok with you? Opera is a small player, but perhaps their mobile browsers are interesting to test MochiKit on? 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: Formatting strings, numbers and stuff
The draft version of MochiKit.Format.format() and formatter()
functions are now ready for testing. They are not documented much,
except for my previous email in this thread. And the API shouldn't be
considered stable.
So I push the bits into my temporary patch repository instead:
http://github.com/cederberg/mochikit-patches/tree/master
You can either download a full zip of the patch project there (press
the Download button). Or you can download just a packed version of
MochiKit + Extensions:
http://github.com/cederberg/mochikit-patches/tree/master/packed.js?raw=true
Or you can browse the source code extensions to MochiKit.Format:
http://github.com/cederberg/mochikit-patches/tree/master/MochiKit/Format.js
The code should work as per my previous specification, except for bugs
and a number of omissions (that I'll probably fix eventually):
b - Binary. Outputs the number in base 2.
c - Character.
o - Octal format. Outputs the number in base 8.
x - Hex format. Outputs the number in base 16, using lower-case letters.
X - Hex format. Outputs the number in base 16, using upper-case letters.
% - Percent conversion for a fixed point number (and adds a '%' char
at the end).
Cheers,
/Per
On Fri, Sep 12, 2008 at 7:38 PM, csnyder [EMAIL PROTECTED] wrote:
On Fri, Sep 12, 2008 at 1:26 PM, Bob Ippolito [EMAIL PROTECTED] wrote:
d is for integers, f is for fixed point.
1 mochifmt:f(${0:.2f}, [1.234]).
$1.23
Love it.
Though I finally RTFM'd and found twoDigitFloat(), so this particular
case already sucks less.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
