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
On Wed, Oct 8, 2008 at 12:56 AM, Akari no ryu [EMAIL PROTECTED] wrote:
Troels, the problem with using prototypical inheritance is that you
end up losing scope in, for example, AJAX request responses or DOM
event handlers.
If you want to keep scope in an event handler, you can delegate to it,
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,
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:
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
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:
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
On Wed, Oct 8, 2008 at 3:54 PM, Per Cederberg [EMAIL PROTECTED] wrote:
Opinions? What does Bob think?
Hooray.
On Wed, Oct 8, 2008 at 3:54 PM, Per Cederberg [EMAIL PROTECTED] wrote:
You can also contribute by running the test suite in your favorite
browser environments. Below is a link and
Hi Per,
On Wed, Oct 8, 2008 at 15:54, Per Cederberg [EMAIL PROTECTED] wrote:
#3. Feature freeze
I know several people want to push bits into MochiKit at the moment
(myself included). But new features invariably mean new bugs. And we
currently have a stable bug-fixed version that has not
I fully agree with this, actually I already wanted to post something
similar this week. This is something that TurboGears users have been
complaining about all the time. If I remember correctly, the main show
stopper for 1.4 was the visuals package. But this has been improved
quite a lot in the
Hi Per,
On Wed, Oct 8, 2008 at 15:49, Per Cederberg [EMAIL PROTECTED] wrote:
This is great work! But since I just took on my code-review-glasses,
here comes a bunch of random comments:
1. The test result from p[lang!=is-IS] has been modified. The
MochiKit.Selector implementation was
Hey Everyone -
Ah, ok. I just thought the test was buggy. != is not actually defined
by CSS3, so I went by the jQuery definition which is this:
Matches elements that either don't have the specified attribute or do
have the specified attribute but not with a certain value.
I.e. it
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
Hi John,
Glad to see you are following our discussion. Btw. are you on the
MochiKit mailinglist, or should I keep cc-ing you explicitly when
there are issues for you?
On Wed, Oct 8, 2008 at 16:41, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Obviously we can discuss this some more but my
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
On Wed, Oct 8, 2008 at 17:07, Per Cederberg [EMAIL PROTECTED] wrote:
Opera is a small player, but perhaps their mobile browsers are
interesting to test MochiKit on?
Right, speaking of mobile browser, all tests pass on Mobile Safari on
my iPod Touch 2G running firmware 2.1.1
cheers,
Arnar
A little status report.
On Wed, Oct 8, 2008 at 18:07, Per Cederberg [EMAIL PROTECTED] wrote:
What I was trying to say is that if querySelectorAll returns a result
that is inconsistent with the JS implementation, then we're in
trouble. If it throws an error (as it presumably does when using
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
18 matches
Mail list logo
