[mochikit] Re: Signal changes prior to MochiKit 1.3 release
On Apr 25, 2006, at 12:37 AM, Thomas Hervé wrote: Beau and I are here making some last minute changes to Signal. We've hacked it apart and put it back together in the interest of ease of use, performance, and plugging up leaks. Great work, the svn has burned :). PLEASE let us know if you have existing MochiKit.Signal code that doesn't work against the trunk given this hack. I'll try to test scriptaculous port against it ASAP, but I don't see any problem for now. Just as a side note, I launch the tests against a few browsers (Firefox/Opera/IE/Konqueror). I only spotted a little problem in the new printfire function on Konqueror, which doesn't known dispatchEvent. Try updating, should be fixed in 752 -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 -~--~~~~--~~--~--~---
[mochikit] Re: AJAX question
On Apr 22, 2006, at 8:04 AM, SamFeltus wrote: Original question. I get Flash, but not AJAX, just trying to wrap my head around what AJAX can and can't do. Another question. I love the Making JavaScript Suck Less motto. I wish ActionScript sucked less. Is there any technical reason why MochiKit.base and MochiKit.iter could not be ported to Flash if someone did the work? It could certainly be ported to ActionScript 2, but I don't like AS2 and I don't do a ton of Flash. Some of MochiKit.Async was ported from code that I had originally written in AS2. If someone were to undertake this task, it would have to be a separate project, because I'm not going to be responsible for maintaining a Flash port. You might want to look at AFLAX, which lets you effectively script Flash in JavaScript, which would let you leverage MochiKit (AFLAX itself, at least the examples, use MochiKit). I really wish Macrodobe wouldn't have been so stupid about diverging from ECMA. I also wish someone would write a JavaScript-SWF compiler (like MTASC, but without having to use that Java-like syntax). -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 -~--~~~~--~~--~--~---
[mochikit] Re: AJAX question
On Apr 21, 2006, at 1:26 PM, Sam Sutch wrote: You can play/stop sounds if you add/remove (respectivly) an embed object with the wav or mp3 set to with the auto play attribute set to true. Sure, but that's stupid because Flash is available just about everywhere that is, if not more available... and if you're using Flash, you might as well do the whole thing in Flash. At least you only have one buggy platform to code against, rather than the gigantic set of all relevant browsers, versions of browsers, sound- playing-plugins, and platforms. It would not be so hard if there was an IDE like flash, but then you get into all the browser incompatabilites and you'd probably want to rip your pubic hair out or something by the time you got done. I'm not a fan of the Flash IDE for doing anything sufficiently complicated.. MTASC is pretty nice though. You can get a pretty good develop/test/run cycle if you set up a web server to fork out MTASC when your actionscript changes. The Flash IDE and player's debugging capabilities blow chunks, but they're no worse than those available for JavaScript implementations. Plus since you have LocalConnection you can do out- of-process debugging with something like XTrace. Granted you could probably do something like that with sync XMLHttpRequest with some kind of specialized server, but I haven't seen that. There probably aren't too many genre of games that make sense in the context of AJAX. However, I'm a huge fan of both ironsudoku.com and playbabble.com -- they're very well done, have excellent usability and browser compatibility, and I can't imagine them being any better given a different choice of technology. -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 -~--~~~~--~~--~--~---
[mochikit] Re: gatherResults and maybeDeferred
On Apr 14, 2006, at 2:53 AM, Thomas Hervé wrote: Bob, could you http://trac.mochikit.com/ticket/87 ? Just a simple implementation of gatherResults and maybeDeferred, with tests. It would be great to have those in 1.3. Looks good, in r662. Note: the 'cc' keyword doesn't seem to send mails. Did you activate the smtp functionnality of Trac ? I'll try and remember to check on that tomorrow. -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 -~--~~~~--~~--~--~---
[mochikit] Re: Make deferred only catch a specific type of exception and rethrow others
On Apr 13, 2006, at 4:24 PM, Doug Crawford wrote: Currently a deferred will catch any excpetion and pass it to the next errback. But if there is no errback left in the chain nothing happens and that error is ignored. This forces me to add the same errback to the end of every deferred chain just to catch some unexpected exception like a TypeError. Could we have deferred only catch a specific Mochikit defined exception and simply rethrow all others? If a callback function really wanted an errback to be called it would have to throw this special MochiKit excpetion instead of just throwing Error(). That's definitely not going to happen. It's also not possible to know when a Deferred is done (since there are no weakrefs or __del__ equivalent for JS), so there can't be some kind of error handler implicitly added to the end of the chain. If you want to create robust async applications you're going to have to put error handlers at the end of any Deferred chain that you don't expect to see any errors from. -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 -~--~~~~--~~--~--~---
[mochikit] Re: Scriptaculous on the trunk?
On Apr 10, 2006, at 5:14 PM, Jeremy wrote: Actually its not a MIT liscence its a MIT-style license which is different and vague enough for our company lawyer to not allow us to use it. Your company's lawyer is lazy or just bad at what he does. Tell him to do his job and read the license! It's word for word identical to any other MIT license aside from the year and copyright holders. Will the new code be released under the same liscence as the rest of the Mochikit stuff? Yes, but some of it is still going to be a derivative work of scriptaculous (though I can't imagine much actual code is left over after reworking it). -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 -~--~~~~--~~--~--~---
[mochikit] Re: Missing feature in signal/handler
On Apr 2, 2006, at 8:44 PM, worik wrote:
I need the currentTarget of the event.
Currently I do...
connect(tepu, onclick, _new_record_tepu_click);
var _new_record_tepu_click = function(e){
var _e = e.event();
var _ct = _e.currentTarget;
// Whatever...
}
The reason it doesn't expose currentTarget is that IE does not
support it.
http://trac.mochikit.com/ticket/72
See also the most recent discussion on this topic:
http://groups.google.com/group/mochikit/browse_thread/thread/
abb13e7c466b58d5
-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
-~--~~~~--~~--~--~---
[mochikit] Re: Create a class
On Apr 1, 2006, at 1:58 PM, faser wrote: Hi, I'm doing some experiments with mochikit and everything seems to work well. It is a great library. I have a question probably more related to javascript than mochikit. I'm not sure what is the best method to create a class in javascript. I have seen we can use 3 methods: -- I was used to use the first one and with the prototype for defining the class methods, but currently it seems to me that the third is more used. Why? You can create class-like objects however you want. It's a style/ coding convention issue, there are slight pros and cons to each of the styles, but nothing important enough to mention. None of MochiKit's features are in any way influenced by how you organize your code. -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 -~--~~~~--~~--~--~---
[mochikit] Re: Combining two getXMLHttpRequests
On Mar 30, 2006, at 1:25 PM, Thomas Hervé wrote: That's a good use-case for DeferredList. I've made a primary implementation here: http://trac.mochikit.com/changeset/548. To use it, simply get the 2 deferred from sendXMLHttpRequest, create a DeferredList with these 2 deferreds, and add your function as callback to the DeferredList. Could you merge this to trunk, or do you want me to? -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 -~--~~~~--~~--~--~---
[mochikit] Re: New to MochiKit - syntax
On Mar 29, 2006, at 2:27 PM, laurin1 wrote:
Ok, i'm REALLY new.
I'm just trying to use getElement like this:
function showrs(){
var $a = document.getElement[id('iRecordSet')].innerHTML
alert($a)
}
Is my syntax off, or am i just OFF?
The syntax is way off. It might help you to give the screencast a
watch, or look at some of the code in the examples and
documentation. Playing with the interpreter demo is a good way to
get a feel for how things work, because you can see the result of a
function immediately.
For reference, that code should just be:
function showrs() {
var a = getElement(iRecordSet);
alert(a);
}
screencast:
http://mochikit.com/screencasts/MochiKit_Intro-1.html
examples:
http://mochikit.com/demos.html
documentation:
http://mochikit.com/doc/html/MochiKit/index.html
-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
-~--~~~~--~~--~--~---
[mochikit] Re: Signal Example
On Mar 27, 2006, at 12:05 PM, Beau Hartshorne wrote: I just added an example that shows how you could implement a simple drag handler with Signal: http://trac.mochikit.com/browser/mochikit/trunk/examples/draggable Any comments? How can it be better? Looks great! The only comment I have is that normally I will use the exported names in the examples rather than the fully-qualified names. In the majority of use cases (well, mine anyway) the developer has enough control to assume that these symbols aren't randomly overwritten by something else, and the code feels a lot simpler without fully qualified names. Now that an example is in place, what are your thoughts on the general stability/completeness of Signal? Can we wrap this up for release this weekend perhaps? -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 -~--~~~~--~~--~--~---
[mochikit] Re: elementPosition Tests
On Mar 27, 2006, at 2:27 PM, Beau Hartshorne wrote: I'd like to write some tests for elementPosition, setElementPosition, and setOpacity. How should I do this? Should I just create a few absolutely positioned elements on the DOM tests page, move them around, and then inspect? That sounds fine to me. For DOM related tests I really don't have much of a quality fixation -- whatever works. The browsers are totally busted anyway, it's not worth the effort to find an elegant solution just for testing. -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 -~--~~~~--~~--~--~---
[mochikit] Re: MochiKit.Signal.registerSignals
On Mar 27, 2006, at 10:14 AM, Jonathan Gardner wrote: On Saturday 25 March 2006 21:26, Beau Hartshorne wrote: Jonathan, I think I asked you about this before, but I can't find the thread. Why does Signal require us to registerSignals before we use them? Can't we do this out in connect()? Dojo's implementation seems cleaner: http://dojotoolkit.org/docs/dojo_event_system.html To prevent typos and to encourage implentors to document their signals in the object that provides them. I'm going to have to disagree here. Unless there's some technical reason why an explicit registerSignals is necessary, we should just let implicit registration happen. Writing less code and more importantly requiring less explanation is a good thing. I don't believe that the time and effort saved by detecting typos or compelling people to write documentation is going to be significant compared to the time and effort saved by not having to do all that extra typing. Hell, more typing is more typos anyway... probably a wash or a net loss in typo-saving. -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 -~--~~~~--~~--~--~---
[mochikit] Re: missing svn tag
On Mar 24, 2006, at 12:25 PM, mrenoch wrote: Could someone please tag the 1.2 mochikit release? We use svn:externals to pull in the mochikit dependencies, and it looks like the 1.2 tag is missing http://svn.red-bean.com/mochikit/tags/ It's not missing, the repository moved months ago. When that happened, I announced it here on the list and changed the links on the site. http://svn.mochikit.com/mochikit/tags/MochiKit-1.2/ -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 -~--~~~~--~~--~--~---
[mochikit] Re: Deferred chains?
On Mar 21, 2006, at 2:45 PM, Doug Crawford wrote:Does anyone have an example of how to setup or use Deferred Chainswhere a callback returns another Deferred instance. I am havingtrouble understanding what is supposed to happen with any return valuefrom a Deferred callback function. Is this return value used as thefirst calling argument for subsequent callback functions?There's nothing magic about them. Just play with them in the interpreter and read the docs... The code isn't very complicated either. d = new Deferred();Deferred(1, unfired) e = new Deferred();Deferred(2, unfired) d.addCallback(function () { return e; })Deferred(1, unfired) d.addCallback(writeln)Deferred(1, unfired) d.callback(1) e.callback("write this")write this dDeferred(1, success) eDeferred(2, success)
--~--~-~--~~~---~--~~
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 -~--~~~~--~~--~--~---
[mochikit] Re: Deferred chains?
On Mar 21, 2006, at 4:36 PM, Doug Crawford wrote:Thanks, I am starting to understand this stuff but not completely. Inyour example you never explicitly call e.addCallback() so when you calle.callback("write this") how does the e object choose the rightcallback function?When a Deferred ends up in the callback chain, the addCallback is implicit. Deferreds are never passed to callback functions, only the value passed to callback or errback is.With multiple callbacks are attached to the same Deferred object thefirst callback will be called with the argument(s) supplied toDeferred.callback(). Then subsequent callbacks will be called with theresult of the previous callback. So according to your example thesecond callback on d (which is writeln) will be called with the resultfrom the previous callback (which is the e object). Is this correct?The result from the previous callback is not the e object, because e is a Deferred. Callbacks can receive anything but Error and Deferred; Errbacks can only receive Error instances. If a Deferred is the result of a callback or errback function, then it's chained. It simply wouldn't work otherwise, because you have to return something, and the callbacks/errbacks don't even have a reference to the Deferred instance that they are attached to.Basically everything a Deferred does happens in one method: Deferred.prototype._fire. It's about a page of code. If you're really trying to understand Deferred, then the implementation would probably help it "click".Effectively here's what happens (I've replaced the reprs with a description of what happened): d = new Deferred();Created a Deferred e = new Deferred();Created a second Deferred d.addCallback(function () { return e; })Populated the callback chain of d with a Deferred-returning function d.addCallback(writeln)Added another callback to the callback chain of d.d's callback chain looks like this now:[return a Deferred, write something] d.callback(1)Start processing d with a callback value of 1.d is now considered fired, and the first callback in its callback chain starts.The first callback ignores the value and returns a Deferred (e).e is not fired yet, so it has no result to pass through d's callback chain.d is now paused, and a callback/errback pair is added to e that will unpause and continue d. e.callback("write this")Start processing e with a callback value of "write this".e is now considered fired, and the first callback in its callback chain starts.The first and only callback in this chain was the implicit continue of d.This callback is called, which continues d's processing chain with a value of "write this"The writeln callback is called with the value "write this" and d's callback chain is now empty.I thought I could restructure the example slightly and still get thesame end result but the following example does not print "write this".I am sure it is obvious why this similar example does not work, but Idon't see it. d=new Deferred Deferred(1, unfired) e=new Deferred Deferred(2, unfired) d.addCallback(writeln) Deferred(1, unfired) e.callback("write this")d.callback(e) Deferred(2, success)It's an error to pass a Deferred object to callback directly. Deferreds can only be used in the result of a callback function. I'll either have to document this restriction or change the code so that it works. I'll probably document the restriction because it's highly unlikely to be a useful feature (code that does this is almost always incorrect).The reason for this is that the creator of the Deferred is responsible for the callback. If the callback is dependent on some other Deferred, usually the correct code would be to simply return that Deferred directly instead of creating a new one. Additionally, it is an error to add callbacks to a Deferred after it has been chained (the callback value isn't preserved anyway, so if you tried it bad things would happen).I guess the best solution would be to add some checking to Deferreds so that these situations cause errors to be thrown instead of the current silent treatment.-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 -~--~~~~--~~--~--~---
[mochikit] Re: Deferred chains?
On Mar 21, 2006, at 5:24 PM, Bob Ippolito wrote: On Mar 21, 2006, at 4:36 PM, Doug Crawford wrote: I thought I could restructure the example slightly and still get the same end result but the following example does not print write this. I am sure it is obvious why this similar example does not work, but I don't see it. d=new Deferred Deferred(1, unfired) e=new Deferred Deferred(2, unfired) d.addCallback(writeln) Deferred(1, unfired) e.callback(write this) d.callback(e) Deferred(2, success) It's an error to pass a Deferred object to callback directly. Deferreds can only be used in the result of a callback function. I'll either have to document this restriction or change the code so that it works. I'll probably document the restriction because it's highly unlikely to be a useful feature (code that does this is almost always incorrect). The reason for this is that the creator of the Deferred is responsible for the callback. If the callback is dependent on some other Deferred, usually the correct code would be to simply return that Deferred directly instead of creating a new one. Additionally, it is an error to add callbacks to a Deferred after it has been chained (the callback value isn't preserved anyway, so if you tried it bad things would happen). I guess the best solution would be to add some checking to Deferreds so that these situations cause errors to be thrown instead of the current silent treatment. Ok, I've revised the implementation of Deferred to do this sanity checking, and have added notes to the documentation for callback/ errback/addCallback/etc. that point out those edge cases. -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 -~--~~~~--~~--~--~---
[mochikit] Re: Catch Error exceptions thrown by a Mochikit.Signal DOM event handler?
On Mar 20, 2006, at 10:21 AM, Doug Crawford wrote:
I have a top level exception handler that looks like:
window.onerror = function(msg, file, line) {
var text = msg + + file + ( + line + );
alert(text);
};
When I throw an Error exception from a DOM signal handler that was
attached using Mochikit.Signal.connect my top level exception handler
never gets called. There was a thread not to long ago discussing how
Mochikit.Signal should deal with exceptions and it sounds it like now
the code is just passing along the excpetion if only one handler
raised
an exception. I am using the latest version 639 which has this
change,
but I still don't see why my top level exception handler is not
getting
called. Is there a better or more standard way to set up a top level
exception handler?
If I throw an excpetion in my signal handler using the following line,
then my top level excpetion handler does get called.
setTimeout(function () { throw exception; }, 0);
Does this have somehting to do with the context in which the signal
function is called? Could this only be an issue for signals
associated
with DOM events?
MochiKit.Signal uses addEventListener. Errors that occur in
listeners don't propagate to window.onerror.
You should be using FireBug instead: http://joehewitt.com/software/
firebug/
-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
-~--~~~~--~~--~--~---
[mochikit] Re: Catch Error exceptions thrown by a Mochikit.Signal DOM event handler?
On Mar 20, 2006, at 12:42 PM, Doug Crawford wrote:
Thanks, is there any way to send Mochikit Logging messages to the
firebug console?
Sure. Take the printfire function from the FireBug FAQ:
printfire = function () {
if (window.console window.console.log) {
// This is Safari JS Console support, not in the FAQ version
window.console.log(arguments[0]);
} else if (document.createEvent) {
printfire.args = arguments;
var ev = document.createEvent(Events);
ev.initEvent(printfire, false, true);
dispatchEvent(ev);
}
};
And then set up a logging listener as per the Logging docs:
http://mochikit.com/doc/html/MochiKit/Logging.html
Something like this would suffice:
printfire_listener = function (msg) {
printfire(msg.level + : + msg.info.join());
};
MochiKit.Logging.logger.addListener(printfire, null,
printfire_listener);
-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
-~--~~~~--~~--~--~---
[mochikit] Re: Perf suggestions with large numbers of connect()s and addLoadEvents?
On Mar 20, 2006, at 3:53 PM, Karl Guertin wrote:
On 3/20/06, LukeStark [EMAIL PROTECTED] wrote:
Perhaps I'm not being clear. Is the following, in fact, the correct
way to create a link that calls a function (fiddlyBits) on
otherObject?
Thomas is saying that doing connect on a ton of elements is
inefficient. He suggests you do :
pageInit = function(){
connect
(document.documentElement,onclick,otherObject,fiddlyBitsDispatch);
}
And then having fiddlyBitsDispatch do some tests to figure out where
the event should go. The dispatch will get all the clicks on the
entire page.
To be honest, I generally use onclick for this scenario. People have a
tendency to click before the page finishes loading and I don't like my
interaction breaking arbitrarily.
Practicality can definitely beat purity in cases like this where
browsers just aren't up to snuff. That said, you can certainly
register a global onclick handler on the document before much of
anything is in the DOM yet, which would serve the same scenario
(click before load completion).
-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
-~--~~~~--~~--~--~---
[mochikit] Re: Request: MochiKit.Signals event().currentTarget()
On Mar 20, 2006, at 5:02 PM, SteveF (adenzo software) wrote: Currently, I have the need to get the currentTarget from the DOM 2 event. (This is the node currently processing the even from capturing or bubling event propogation). Unfortunately, it seems that IE doesn't have a currentTarget, but with MochiKit.Signals it would be easy to add a cross platform currentTarget - I think (!?) When a Signal is connected to an element: connect(src, signal, dest[, func]): then any event dispatch from that connection would simply have the currentTarget attribute of the event to the original 'src' passed in. See any flaws in that logic? Would be nice and clean and avoid hassling with partial functions on the part of the user of the Signals.connect() function. Isn't this need already served by the target() method of the custom event object? See here: http://mochikit.com/doc/html/MochiKit/Signal.html#description The methods of the custom event object are enumerated in item 8. -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 -~--~~~~--~~--~--~---
[mochikit] Re: Adding an image to an existing page
On Mar 16, 2006, at 11:18 AM, Jorge Godoy wrote:
Hi!
Through AJAX I'm generating some results and also an image file
that I want to
show on the web page. The results are appearing but nothing about the
image...
I can see that the browser fetched it and it was returned
correctly, but it
doesn't show on the page.
This is the code I'm using (one of the several attempts I've made):
==
==
var atualizar_curva_calibracao = function(dados) {
var payload = evalJSONRequest(dados);
getElement(calibracao_a).innerHTML = payload.curva.a;
getElement(calibracao_b).innerHTML = payload.curva.b;
getElement(calibracao_r2).innerHTML = payload.curva.r2;
var imagem = IMG({src:payload.grafico}, null);
t = appendChildNode(grafico, imagem);
swapDom(grafico, t);
getElement(mensagem).innerHTML=;
}
==
==
On my HTML code I have the following:
==
==
td width=50%a id=grafico name=graficonbsp;/a/td
==
==
Here's one example from the logs:
==
==
127.0.0.1 - - [16/Mar/2006:16:15:02] GET /static/images/
2006-03-16-16.15.02.395169-godoy.png HTTP/1.1 200 2494
==
==
Any hints on what I'm doing wrong or how to make the images appear?
There is no appendChildNode function in MochiKit. There is an
appendChildNodes function. appendChildNode is a DOM node method
(which is probably defined on the global window object, which is why
you didn't get an exception).
-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
-~--~~~~--~~--~--~---
[mochikit] Re: Adding an image to an existing page
On Mar 16, 2006, at 11:36 AM, Jorge Godoy wrote: Bob Ippolito [EMAIL PROTECTED] writes: There is no appendChildNode function in MochiKit. There is an appendChildNodes function. appendChildNode is a DOM node method (which is probably defined on the global window object, which is why you didn't get an exception). Oops! I missed the s, indeed... I didn't noticed that because the image was fetched. That happens as soon as you create an IMG node (or Image instance), not when it is inserted into the document. Back in the DHTML days we used that to preload rollovers and other nonsense like that :) Sometimes people also use that feature as a one way cross-domain communication channel over query string. -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 -~--~~~~--~~--~--~---
[mochikit] Re: encodedString.replace not a function in Base.js
On Mar 16, 2006, at 1:01 PM, EuGeNe wrote: Hi All, Playing with var args=MochiKit.Base.parseQueryString(linkelement); where linkelement='http://wiki/pmwiki.php?n=Main.WikiSandbox? log_month=200602' I get an error telling me that in Base line 1165 encodedString.replace is not a function. If I call parseQueryString on linkelement.toString() it works but args is ... not defined. Not sure what I am doing wrong here. Anyone can help? I don't get an error here, but that is not a query string, that is a URL. The query string is after the ?. Your query string is malformed though, because there can't be more than one ?. Here's what would happen if you were using it with correct input: MochiKit v1.3 [AppleWebKit/417.9 (KHTML, like Gecko) Safari/417.9.2] items(parseQueryString(n=Main.WikiSandboxlog_month=200602)) [[n, Main.WikiSandbox], [log_month, 200602]] MochiKit v1.3 [Gecko/20060111 Firefox/1.5.0.1] items(parseQueryString(n=Main.WikiSandboxlog_month=200602)) [[n, Main.WikiSandbox], [log_month, 200602]] -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 -~--~~~~--~~--~--~---
[mochikit] Re: How to make Mochikit and Dojo work together (*newbie asking)
On Mar 15, 2006, at 1:08 AM, b3d70 wrote: Dear Masters, Please give a light to my code. I try to make MochiKit and Dojo work together, and these are the way I did. Please help me to make it better. script type=text/javascript src=http://localhost/js/dojo022/dojo.js;/script script type=text/javascript src=http://localhost/js/dojo022/src/widget/TabPane.js;/script script src=http://localhost/js/mochikit/MochiKit.js; type=text/javascript/script script src=http://localhost/js/inventories.js; type=text/javascript/script -- The things that I dont like from my code is I always have to mention the MochiKit.DOM.xxx or MochiKit.DateTime. So please, does somebody overthere can help me to make my code more better ? If you want to use the short names, then load MochiKit before dojo. -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 -~--~~~~--~~--~--~---
[mochikit] Re: svn commit mailinglist ?
On Mar 15, 2006, at 10:38 AM, troelskn wrote: Is there a mailinglist where you announce commits to the repository ? No, but you can subscribe to an RSS feed in trac's timeline: https://trac.mochibot.com/timeline -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 -~--~~~~--~~--~--~---
[mochikit] Re: Signal Errors
On Mar 15, 2006, at 9:54 AM, Beau Hartshorne wrote: In MochiKit.Signal.signal, I don't think it makes sense to run through the slots and swallow errors if they occur and then just throw a generic error when something breaks. It makes debugging suck, and in production code, if something breaks, why not just let it break? Can we remove the try/catch from this function, and let errors be thrown when they happen? That sounds like the right thing to do. Let's go ahead and remove it. -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 -~--~~~~--~~--~--~---
[mochikit] Re: PEP 8 and _ or __?
On Mar 15, 2006, at 9:04 AM, Beau Hartshorne wrote: The PEP 8 naming conventions suggest a single underscore indicates weak internal use. Since JavaScript doesn't do name mangling, should internal variables always use single instead of double underscores? (Except special names like __repr__.) Single underscore. -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 -~--~~~~--~~--~--~---
[mochikit] Re: Signal Errors
On Mar 15, 2006, at 2:15 PM, Jonathan Gardner wrote: On Wednesday 15 March 2006 14:05, Bob Ippolito wrote: If this was a server-side framework in a language with better facilities to report errors, then I might agree that the error should be logged and the next handler should continue. However, this is a language with absolutely horrible error handling and it's client-side code. It really doesn't change the game whether or not the error is caught and later reported or just let go. The error doesn't (or at least shouldn't) lose any information. As long as the original exception objects are kept as-is and something that contains them all gets thrown, I think most runtimes will be OK with that. In the case where exactly one handler threw an exception, it would make sense to raise that without wrapping it to save the developer some time debugging it. -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 -~--~~~~--~~--~--~---
[mochikit] Re: Color.fromRGB bug
On Mar 14, 2006, at 1:24 PM, Thomas Hervé wrote: Good catch, a hard-to-find bug! I saw the problem in your values because there were always a '010' in it (it's just a problem in toHexString). See http://trac.mochikit.com/ticket/68 for correction. Thanks! This patch has been applied and the ticket closed. -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 -~--~~~~--~~--~--~---
[mochikit] Re: doubt about javascript datastructure
On Mar 9, 2006, at 10:55 AM, [EMAIL PROTECTED] wrote:
Hi all
I just started with mochikit and I'm making some mess between python
and javascript data structures. I don't know much about javascript but
I believe that the only high level data structure is the array.
Well,
when reading the mochikit.Base doc there seems to be a lot of magic
going around.
I will slowly read all the docs properly but by now I have the
following situation:
function retrieveCmd(values) // values are the values from
a form
{
var e = doSimpleXMLHttpRequest('runCmd2', values);
e.addCallback(cb_retrieveCmd);
return false;
}
function cb_retrieveCmd(results)
// here is the problem. results is a dictionary. how do I
deal with it?
// the solution below doesn't work
{
for (var hostname in results) {
var term = document.getElementById('term_' +
hostname);
term.innerHTML = results[hostname];
}
}
In this case, results is an XMLHttpRequest instance.. definitely not
a dictionary. How are you sending the data back? JSON? If so, use
loadJSONDoc instead. That should work.
You should also ensure that term exists before trying to set an
attribute of it.. if some script you're using pollutes
Object.prototype then results will have extra keys that you aren't
expecting.
-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
-~--~~~~--~~--~--~---
[mochikit] Re: naming conventions
On Mar 6, 2006, at 5:42 AM, troelskn wrote: Hi. The wiki refers to PEP8 for naming-conventions, but I'm a bit confused. It seems that global functions are named lowercase_underscore, whereas memberfunctions (methods) as studlyCaps. This is rather confusing since all global functions are also static members of the namespace which they belong to. The result is that we have both MochiKit.DOM.swapDOM and MochiKit.Signal.register_signals. While I personally like the lowercase_underscores style for global functions, I think it's ambigous, so to avoid confusion, it would probably be better to stick with studlyCaps. It's PEP8 inspired, but it clearly doesn't follow it to the letter. MochiKit uses studlyCaps because that's what the rest of JavaScript uses. MochiKit.Signal should be changed to follow the rest of MochiKit before it's actually released and we end up stuck with it. There are no static members in JS, btw. -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 -~--~~~~--~~--~--~---
[mochikit] Re: Iterator interface
On Mar 6, 2006, at 8:40 AM, vmpn wrote:
The current iterator usage patern in documented as:
var it = iter(iterable);
try {
while (var o = it.next()) {
// use o
}
} catch (e) {
if (e != StopIteration) {
throw e;
}
// pass
}
That's how it is and that's how it's going to stay.
What about making the Iterable objects implemented hasNext() method.
making the usage:
var it = iter(iterable);
while (it.hasNext())
{
var o = it.next();
}
Are there any perfomance issues doing it this way?
Well yes, because such iterators would have to be adapted to the
former in order to interoperate with MochiKit :)
-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
-~--~~~~--~~--~--~---
[mochikit] Re: Iterator interface
On Mar 6, 2006, at 11:35 AM, vmpn wrote: For my education, if you do not mind, any advantages of the first form over the second (when one is *not* implemented as the wrapper for the other)? Just trying to see if I can learn a new javascript trick. :) The former is how Python does it, is stateless, and minimizes function calls. There's no real trick to it... there are several decent ways to come up with an iterator protocol, and I picked this one. Normally you shouldn't see it, because it's used implicitly in forEach, map, etc. -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 -~--~~~~--~~--~--~---
[mochikit] Re: getViewportDimensions doc bug
Not quite, there are a two spots that I can see that you missed:
if (window.innerWidth) {
..
} else if (self._document.body document.body.clientWidth) {
I'd write it more compactly using a couple more locals instead of
repeating self.foo.bar.baz ad nauseam.
-bob
On Mar 3, 2006, at 11:15 AM, Beau Hartshorne wrote:
That'd be me. Is this correct:
getViewportDimensions: function() {
var d = new MochiKit.DOM.Dimensions();
var self = MochiKit.DOM;
if (window.innerWidth) {
d.w = self._window.innerWidth;
d.h = self._window.innerHeight;
} else if (self._document.body.parentElement.clientWidth) {
d.w = self._document.body.parentElement.clientWidth;
d.h = self._document.body.parentElement.clientHeight;
} else if (self._document.body document.body.clientWidth) {
d.w = self._document.body.clientWidth;
d.h = self._document.body.clientHeight;
}
return d;
},
Should I run through everything to see that I've used
M.DOM._document instead of document? (elementPosition comes to mind..)
On 3-Mar-06, at 11:04 AM, Bob Ippolito wrote:
Not in this case because whoever wrote it used a direct reference to
the window object.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[mochikit] Re: HowtoSimpleAjax issue
On Feb 27, 2006, at 8:26 AM, Lee McFadden wrote:
I've been writing some fairly complex JS for inline editing of text
using http://trac.mochikit.com/wiki/HowtoSimpleAjax as a basis for
making my links ajax enabled rather than using the
href=javascript:someFunction() nastyness.
It all seems to work beautifully on FF, however IE is a different
matter altogether.
Here is the shortest of the functions that I'm using, but it is
typical of the functions i've created:
var clickNameEdit = function () {
return function (evt) {
//prevent the normal 'click' action for a link
evt.stopPropagation();
evt.preventDefault();
,.. this is broken on IE because IE does events in an entirely
different way than Firefox does. The ajax tables and sortable tables
examples in the MochiKit distribution have examples of correct cross-
browser onclick handling. Wiki content isn't really reputable until
proven otherwise -- in this case, that page is not (unless you only
care about FF, of course).
In MochiKit 1.3, there's the signal module that makes it easier to
write correct cross-browser event code, but it doesn't seem to be
quite finished yet in SVN trunk (still fails plenty of tests).
-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
-~--~~~~--~~--~--~---
[mochikit] Re: methodgetter
On Feb 27, 2006, at 10:33 PM, Doug Crawford wrote:
I am trying to make a function called methodgetter. This is
similar to
itemgetter but calls an object method rather than returning an object
property. For the most part, the following code works:
function methodgetter(name) {
return function(object){ return object[name].call(object); }
}
But I also want to use map with multiple arguments like so:
map(methodgetter('aMethod'), objectArray, methodArgumentArray);
I had to modify the closure to look like:
function methodgetter(name) {
return function(object, a){ return object[name].call(object, a); }
}
I thought it would be possibly to extend this to many arguments by
using:
function methodgetter(name) {
return function(object){ return object[name].apply(object,
arguments); }
}
However, this does not work. Am I missing something with the use of
the javascript arguments variable?
First off, your proposed implementation has the wrong semantics. If
it worked, your methodcaller(func)(obj, a, b, c) would translate to
obj.func(obj, a, b, c) instead of obj.func(a, b, c).
If JavaScript were slightly less brain damaged, this would work
across implementations with the proposed semantics:
methodgetter = function (name) {
return function (object/*, ... */) {
return object[name].call.apply(arguments);
};
};
But of course, in most implementations, call is bastardized and isn't
really a function (in the sense of Function.prototype) like it should
be. What you need is something like this:
methodgetter = function (name) {
return function (object/*, ...*/) {
return object[name].apply(object, extend(null, arguments, 1));
};
};
Which works like this:
methodgetter(func)
function (object) { return object[name].apply(object, extend(null,
arguments, 1)); }
f = {toString: function () {return f}, func: function ()
{ return concat([this], arguments); }};
f
methodgetter(func)(f)
[f]
methodgetter(func)(f, 1, 2, 3)
[f, 1, 2, 3]
Since you specifically probably want something pure, here's what that
translates to sans MochiKit:
methodgetter = function (name) {
return function (object/*, ... */) {
var args = [];
for (var i = 1; i arguments.length; i++) {
args.push(arguments[i]);
}
return object[name].apply(object, args);
};
};
-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
-~--~~~~--~~--~--~---
[mochikit] Re: bug in MochiKit.DOM.appendChildNodes?
On Feb 25, 2006, at 7:46 AM, Eric Faurot wrote: I think I spotted a bug (this time :) in MochiKit.DOM.appendChildNodes. The problem is that when an iterable is found in the node stack, its content is flattened at the end of the stack rather than in-place. I see no reason why the current code would ever want to do this. Here are an example that exposes the bug and a patch for it. Yes, that was a bug in MochiKit up to 1.2... but you're a few weeks late. It was found and fixed a few weeks ago. http://trac.mochikit.com/ticket/52 http://trac.mochikit.com/changeset/612 * MochiKit.DOM.appendChildNodes and associated functions now append iterables in the correct order. -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 -~--~~~~--~~--~--~---
[mochikit] Re: DeferredLock
On Feb 24, 2006, at 4:46 PM, [EMAIL PROTECTED] wrote: Undocumented was not the thing to say, perhaps undiscussed would have been better. Since I did find DeferredLock in the docs. So it turns out that DeferredLock is completely not what I need, this was made clear to me from testing some more code (thanks for the example) and your previous post here http://groups.google.com/group/mochikit/browse_frm/thread/ 50ad8188b8838d3b/bde8edfecd890914?q=waitrnum=3#bde8edfecd890914 Apparently I need to figure out how to do a synchronous request for a json doc. You really shouldn't under any circumstance unless you're talking to 127.0.0.1. MochiKit doesn't support synchronous network events because they're almost universally a bad idea given the browser environment. -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 -~--~~~~--~~--~--~---
[mochikit] Re: object from (and only from) json callback gives error
On Feb 18, 2006, at 11:01 PM, mario ruggier wrote:
On Feb 17, 2006, at 9:40 PM, Bob Ippolito wrote:
On Feb 17, 2006, at 12:32 PM, mario ruggier wrote:
strange problem, I have a simple object, e.g.:
var fs = {
'name': 'abc',
'value': 'xxx',
'ok': true,
'message': 'some text'
};
I am creating such objects on the client, and passing them around,
e.g.
thru a function like:
function dSucceeded(data) {
for (var k in data) { alert(k+':'+data[k]); }
}
And all is ok... However, on some cases I need to callback to get a
similar object, but passing that object thru the same function
above
(FireFox 1.5.0.1 on OS X 10.3.9) gives :
Error: [Exception... 'Permission denied to set property
XULElement.selectedIndex' when calling method:
[nsIAutoCompletePopup::selectedIndex] nsresult: 0x8057001e
(NS_ERROR_XPC_JS_THREW_STRING) location: ...
and the ... contains info pointing to precisely the single-line
body
of the callback function above. The exception is thrown after
that the
for-key-in-obj-alert loop has completed (alerting correctly for all
object attrs). (Safari breaks down in exactly the same place, but
gives
less feedback than FireFox.)
Please post a fully reproducible example so that others may
investigate the issue.
I have not been able to extricate a reproducible, and post-able
example, of the the chain of events that was leading to the
exception above. I have discovered tho that the real source of the
problem is the unboundedness of the deferred's callback functions.
The problem surfaced when I was refactoring free floating callback
functions and putting them onto an object, e.g. I wanted something
like:
MyObject.callback function (elem) {
var name = elem.name;
var value = this.get_widget(name).get_value();
var url = name+'.json?'+name+'='+value;
var d = loadJSONDoc(url);
d.addCallbacks(this.dSucceeded, this.dFailed);
return true;
}
MyObject.dSucceeded function (data) {
var widget = this.get_widget(data.name);
// unbound when fired... this fails.
// ...
}
This does not work, as the success function stays unbound when it
is fired. Still, *sometimes*, the problem was surfacing later with
the exception above.
Anyhow, if I rebind the callback funcs when setting them, i.e. do :
d.addCallbacks(bind(this. dSucceeded, this), bind(this.dFailed,
this));
Then the callbacks are properly bound when fired. Is having to
rebind the callback functions js-thing that one just has to live with?
JS does not have bound functions, so you do have to live with it.
this can only be set by a particular syntax,
Function.prototype.call, or Function.prototype.apply.
http://tinyurl.com/ak5xs
-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
-~--~~~~--~~--~--~---
[mochikit] Re: object from (and only from) json callback gives error
On Feb 17, 2006, at 12:32 PM, mario ruggier wrote:
strange problem, I have a simple object, e.g.:
var fs = {
'name': 'abc',
'value': 'xxx',
'ok': true,
'message': 'some text'
};
I am creating such objects on the client, and passing them around,
e.g.
thru a function like:
function dSucceeded(data) {
for (var k in data) { alert(k+':'+data[k]); }
}
And all is ok... However, on some cases I need to callback to get a
similar object, but passing that object thru the same function above
(FireFox 1.5.0.1 on OS X 10.3.9) gives :
Error: [Exception... 'Permission denied to set property
XULElement.selectedIndex' when calling method:
[nsIAutoCompletePopup::selectedIndex] nsresult: 0x8057001e
(NS_ERROR_XPC_JS_THREW_STRING) location: ...
and the ... contains info pointing to precisely the single-line body
of the callback function above. The exception is thrown after that the
for-key-in-obj-alert loop has completed (alerting correctly for all
object attrs). (Safari breaks down in exactly the same place, but
gives
less feedback than FireFox.)
Please post a fully reproducible example so that others may
investigate the issue.
-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
-~--~~~~--~~--~--~---
[mochikit] Re: Async and Deferred question
On Feb 16, 2006, at 8:01 AM, Ryan Hagan wrote: We've been using Mochikit for a while now and it has really become invaluable for us. One of the things we're doing is we're showing an HTML dashboard framework (which has pods that can be added or removed) and after the framework for all the pods is rendered server side, we're using the Asynch code to load the content of each pod on the dashboard. There can be 10 to 15 pods, but each user generally only has 4 or 5, so this saves us from having to load all the pod contents on the server. The problem I'm seeing is that the pods seem to load one at a time. I can watch the AJAX requests all fire off pretty much at once and I can see the server respond almost immediately, but the pods on the dashboard all load one at a time, one after another. I would expect them all to pretty much pop onto the screen at the same time. My question is, is there something in Mochikit that is causing the responses to queue up? Why wouldn't the pods all load as soon as each pod gets its data, instead of one after another? JavaScript only has a single execution context per page, so only one thing can happen at a time. The serial nature of what you're seeing is probably due to the time it takes for the DOM to redraw. There's two ways to make that happen. The ideal solution is to have the server send everything in one request, but you could also do it by collecting requests on the client side and doing the DOM updates in batch (can be tricky). -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 -~--~~~~--~~--~--~---
[mochikit] Re: Mochikit performance with big Documents
On Feb 13, 2006, at 7:27 AM, gbirke wrote: I use MochiKit for an online store. When I show big tables (6 columns, 3500 rows) the page becomes very slow and Firefox asks me if it should kill an unresponsive script. I'm only including the Base, Iter, Async and DOM files on that page, functions only get called, when someone clicks on a link. Is there any explanation for this? Any solution (except not showing so many entries)? You'll need to show the code if you want any useful answer, preferably in the context of a working example. Generically the answer is DOM is slow if you do it wrong. and sometimes DOM is slow period, maybe you'll need to drop back to building HTML and using innerHTML, but unless it's profiled there's no way to know what can be improved upon. -bob
[mochikit] Re: Cookies
On Feb 12, 2006, at 4:17 PM, Beau Hartshorne wrote: On 12-Feb-06, at 4:11 PM, Bob Ippolito wrote: It'd be pretty easy to find if it did.. everything public is documented. No, it doesn't currently do anything with cookies. Sorry, I should have started with I think MochiKit should make cookies not suck. I'm working with my first JS cookie today, and it's horrible. Would they belong in .Base (with the JSON stuff)? No, cookies would belong in their own module. Base consists of non- browser-specific technology. There shouldn't be any references to window, document, etc. in Base. It's also worth considering using Flash to serialize data using its SharedObject. SharedObjects are like cookies, but they can store more data and don't round-trip every request. Really depends on your use case I guess. Dojo has done a bunch of work in this area and have documented workarounds for the bugs. -bob
[mochikit] Re: IE bug with object tags?
On Feb 12, 2006, at 10:12 PM, Tim Stebbing wrote:
This code does not work in IE, it works in FF, I cannot tell why?
var id = 123;
var OBJECT = createDOMFunc('object');
var PARAM = createDOMFunc('param');
var EMBED = createDOMFunc('embed');
I don't really have time to screw around on a PC right now, but my
first approach would be to remove the embed tag there because it
doesn't really apply to IE, and then I'd take a look at the innerHTML
of what it generated. If it wasn't obvious what the workaround
should be at that point, I'd give up and just use innerHTML to create
the object tag on IE. I definitely know that setting the OBJECT tag
works just fine with innerHTML because I've seen it done a bunch of
times.
Doing things the standard way is sometimes counter-productive when
working with IE due to its bugs. Since MochiKit.DOM is really just
an alternate syntax for DOM (with a few IE hacks), there's only so
much it can do to make things just work everywhere. Some of the
bugs are related to semantics, e.g. you must include THEAD and TFOOT
in a TABLE in order for it to display the TBODY sections. This could
be something dumb like that.
-bob
[mochikit] Re: Timeout example? (for badly behaving servers...)
On Feb 8, 2006, at 6:41 PM, Matt Harrison wrote:On 2/9/06, Bob Ippolito [EMAIL PROTECTED] wrote: On Feb 8, 2006, at 5:01 PM, [EMAIL PROTECTED] wrote: Does anyone have an example of timing out an XMLHttpreques using Mochikit? I've got a server that just listens, but never responds and after like 5 seconds or so, I'd like my app to give up trying to get something back from it.something like this should work:var cancelWithTimeout = function (deferred, timeout) {var canceller = callLater(timeout, function () { // cancel the deferred after timeout secondsdeferred.cancel();});return deferred.addCallback(function (res) {// if the deferred fires successfully, cancel the timeoutcanceller.cancel();return res;});};Used like this:var d = cancelWithTimeout(10.0, loadJSONDoc(...)); Bob- Thanks that worked (had to switch 10.0 to the 2nd parameter...).Right -- that's what I get for writing code in Mail without testing it. I've got another question for you regarding simplejson. Have you (or anyone you know of) done serialization of python objects using JSON?That's more or less what simplejson does by definition... It won't serialize arbitrary objects out of the box, but it's easily subclassable in a way that would make it easy to do so (implementing a "default" method). I'm thinking about how difficult it would be to do remote objects over httpYou mean like JSON-RPC?-bob
[mochikit] Re: Javascript on demand
On Feb 7, 2006, at 3:33 AM, Eoghan wrote: Have a look at Mochikit.js in source tree (not the packed version), this dynamically loads all the submodules of Mochikit using document.write. This is cool for html, however doesn't work for xhtml (the dom standard document.createElement doesn't work in Safari either), so I don't know of a future proof cross browser way of doing js on demand exists. XHTML loses. Strict XHTML compliance when using the source tree is not useful enough to care about. You really shouldn't be using the unpacked version in production anyway. The packed version is what you want to be using in almost all situations unless you are hacking on MochiKit itself. It's possible to implement on-demand synchronous loading using XHR and eval, but that makes it even harder to debug so that is NOT an option. The source version must be debuggable. -bob
[mochikit] Re: Css Syntax
On Feb 7, 2006, at 3:21 AM, Eoghan wrote:
I was playing around with computedStyle and updateNodeAttributes
when I
got bitten (again) by the asymmetry of syntax between e.g.
computedStyle(e, font-size) updateNodeAttributes(e, {'style':
{'fontSize': newVal}}). Of course, this is to do with the
inability of
JavaScript to parse e.style.font-size, so in the spirit of making js
suck less, I propose the following enhancement for
Mochikit.Dom.updateNodeAttributes:
This is worth doing. If you write some tests for the functionality
then I'll take it.
-bob
[mochikit] Re: SimpleTest: a Test.Simple replacement
On Feb 7, 2006, at 5:03 AM, Leonardo Soto M wrote: Bob Ippolito wrote: [...] Test.Simple is gone! I made some changes to SimpleTest so that it works in Safari and Firefox. I have not tested elsewhere. It worked for me on FF 1.5, Opera 8.5, IE 6 and IE 5.5 (Well, not pure 5.5, I'm using the hack that allows you to have IE 5, 5.5 and 6 on the same Windows installation). What stopped SimpleTest from working on Safari?. I've no access to the Mac world. display:none stopped SimpleTest from working. It seems that doing that unloads (or never loads, depending on when you do it) the iframe. The setTimeout might not be necessary and the change from setAttribute to attribute setting is definitely not relevant, but it's less code and more clear. http://www.google.com/search?q=iframe+safari+display+none http://developer.apple.com/internet/webcontent/iframe.html -bob
[mochikit] Re: SimpleTest: a Test.Simple replacement
On Feb 6, 2006, at 6:52 PM, Leonardo Soto wrote: Hi all!, I'm working a Test.Simple replacement, that basically inherits the simplicity of Test.Simple but: * Works on IE5.5 * Don't require you to count the tests * Tests that requires elements visible in the browser works in the TestRunner (Harness). * Display the test results nicer (IMO). Great! Did you see that some of this was already done in MochiKit/ Test.js? That's why the non-DOM tests were factored out into separate .js files, so I could run them with the standalone SpiderMonkey. I didn't do the browser stuff though, so I'm just going to take this as-is and we can look into merging the two soon. -bob
[mochikit] Re: New user orientation ...
On Feb 4, 2006, at 8:20 PM, [EMAIL PROTECTED] wrote: Hi, I'm yet another newbie - sorry if these questions are out of place... Nope, the mailing list is the perfect place to ask any question related to MochiKit. Plain old JavaScript discussions are fine too. Q1) What's the relationship between the wiki and this list? i.e. should discussions be posted here but code examples on the wiki? This list seems busier than the wiki - hence this is where I posted. However, IMO, the wiki (or perhaps a bulletin board) is a better vehicle for long running topics (such as requests for screencasts - see below). They're complementary. The wiki is where you put things that you want to be persistent, and the list is where you have more ephemeral discussions. Normally if you put something on the wiki you should probably post a note to the list so that people know to look... not everyone is subscribed to the RSS feed of the wiki. Putting screencast suggestions on the wiki is a great idea, it's a lot harder to lose track of suggestions if they're in one place :) Q2) I'd like to suggest a screencast that takes the viewer through developing a reasonably useful widget from an examination of the widgets goals, through good design decisions to the implementation and then leave the viewer with a few ideas of how the design could be extended. Perhaps the ajax_tables example built from the ground up. OTOH, this might be too ambitious, but OTOH, it would serve a number of purposes: a) demonstrate the capabilities b) teach newbies the essence of Mochi style, patterns, norms c) encourage us newbies to submit possible widgets to the project At this time, MochiKit doesn't have any widgets, so it's not really seeking out widget contributions. The only things that ship with MochiKit remotely related to widgets are the examples. Once the script.aculo.us branch is merged, it might make sense to start tossing widgets in, though. Probably in a separate package, so that users who don't need all the fluff don't get it. As far as style and patterns go, there's some style guide notes in the wiki: http://trac.mochikit.com/wiki/StyleGuide Other than that, it's just mostly just pythonic. PEP-20 is probably the best way to begin to understand what that means: http://www.python.org/peps/pep-0020.html Q3) I'm currently attempting to create a feature rich data grid (multi-column sort, filtering, in-place editing to name but a few) using the AJAX model with JSON and JSON-RPC. Aside from making the darn thing work I'd like to get the code critiqued - is the best way to simply post it to the wiki and sit back and wait? Or can I more proactively encourage a critique? (BTW, I've nothing to post yet - all I've done so far is hack at the sortable_table example before progressing to grokking the ajax_table example. Post it to the wiki, and let us know on the list. If it's a relatively small snippet then you might want to just post it to the list. Q4) Is there any interest in creating a community section on the wiki? Don't worry I'm not looking for a friendship service ;-) however, I'd like to know and share relevant discussions involving MochiKit and the blog seems to belong to Bob (so it doesn't seem appropriate to post there). The wiki *is* the community section. The wiki content is almost entirely generated by other people. My outlets are primarily the documentation and the blog (since it's currently just a tag on my personal blog). I'd certainly consider creating a blog where several people have access to post, or changing the blog link to a MochiKit Planet, but as of yet I don't think there's enough people who consistently write MochiKit-related blog entries to justify the effort. Please feel free to prove me wrong, though :) Lastly MochiKit looks really excellent - I'm excited about programming again. Fwiw, I became a p.h.b. at work 3 years ago and have since only dabbled in programming - however now I'm attempting to start up some personal development projects. 3 years feels like a lifetime - I used to be a reasonably proficient C++ programmer. Welcome to the world of agile programming languages. If you were proficient in C++, you'll be getting a lot more done in less code with a language like JavaScript (once you get used to its language design quirks and implementation missteps). Hopefully MochiKit will help flatten your learning curve by providing functionality that makes sense and behaves consistently across the browser platforms! -bob
[mochikit] Re: Conditional Comments
I don't know. I ran the example as-is, so whatever mode the example normally runs in. -bob On Feb 2, 2006, at 9:30 AM, Beau Hartshorne wrote: Quick question: was IE in quirks mode when you did this? On 31-Jan-06, at 1:17 PM, Bob Ippolito wrote: MochiKit v1.3 [IE 7.0] Type your expression in the input box below and press return, or see the notes below for more information. MochiKit.DOM.attributeArray.compliant false
[mochikit] Re: Conditional Comments
Yes, but with different syntax. See the references here:
http://trac.dojotoolkit.org/ticket/395
-bob
On Feb 1, 2006, at 9:32 AM, Beau Hartshorne wrote:
Do conditional comments work in .js files? I couldn't find any
reference to it, and tried:
/*[if IE]
alert('hello');
[endif]*/
That didn't work, and it doesn't seem to work with CSS either. In
any case, I don't think Dojo's compressor is the problem here.
On 31-Jan-06, at 11:42 AM, Bob Ippolito wrote:
I think it would be best to wait until Dojo's compressor supports
preservation of conditional comments, so that the IE hacks stay
inline. This is just an optimization, not a feature or a bug fix...
[mochikit] Re: Proposed DOM Functions
On Jan 24, 2006, at 1:05 PM, Beau Hartshorne wrote:
I'd like to ask for feedback on some possible new DOM functions to
help with element positioning:
MochiKit.DOM.Box, a new object: {t: 0, l: 0, b: 0, r: 0}
getContentBox(someElement), returns a Box
getBorderBox(someElement), returns a Box
getPaddingBox(someElement), returns a Box
getMarginBox(someElement), returns a Box
These will accept a partial box, like {r: 0} if you only want to
change one property:
setContentBox(someElement, aBox)
setBorderBox(someElement, aBox)
setPaddingBox(someElement, aBox)
setMarginBox(someElement, aBox)
getViewportDimensions(), returns a Dimensions object
moveTo(someElement, Coordinates/* optional */, aBoundingBox)
moveBy(someElement, Coordinates, Coordinates)
getStyleBox(someElement), returns a Box
setStyleBox(someElement, aBox)
setOpacity() // will accept 'none' to clear it
getOpacity()
All of these look good to me. Personally I would prefer an x,y,w,h
box model, but t,l,b,r is CSS convention so I guess that's more
appropriate.
isVisible(), returns true/false
toggleVisible(), uses hideElement and showElement
This is troublesome (as cited elsewhere in the thread). I'd rather
leave these out.
-bob
[mochikit] Re: Conditional Comments
On Jan 31, 2006, at 11:15 AM, Beau Hartshorne wrote: I see, Signal could be improved by defining a special IE-style Event prototype for IE at load time instead of all the branching at call time. I don't mean to leave IE unsupported. I'm suggesting splitting all of the IE hacks into their own file, and using IE's conditional comments[0] to redefine a few functions for IE. This would be a decent solution if Dojo's compressor supported preservation of conditional comments. Right now it doesn't. In some places you check for something like (self.attributeArray.compliant). My concern (bet) is that IE7 may assert that it is compliant, but still screw it up. compliant is the result of analyzing a DOM element for attributes that shouldn't be there. IE has always defined default values for every possible attribute, and I don't think they're going to change that behavior. It's not technically broken, and they have lots of real bugs to worry about :) -bob
[mochikit] Re: Conditional Comments
That's a possibility, but it would be backwards incompatible. I think it would be best to wait until Dojo's compressor supports preservation of conditional comments, so that the IE hacks stay inline. This is just an optimization, not a feature or a bug fix... -bob On Jan 31, 2006, at 11:33 AM, Beau Hartshorne wrote: What about asking users to do it in the head, like: script src=MochiKit/MochiKit.js type=text/javascript/script !--[if IE]script src=MochiKit/IE.js type=text/javascript/ script![endif]-- On 31-Jan-06, at 11:24 AM, Bob Ippolito wrote: This would be a decent solution if Dojo's compressor supported preservation of conditional comments. Right now it doesn't.
[mochikit] Re: Proposed DOM Functions
I've never personally seen any code that works in anything but px.
Let's leave out in/em/% support until there's a use case for it..
seems like a lot of work for little practical use. It might be worth
checking for px and raising an exception if it's in some other unit,
though.
-bob
On Jan 31, 2006, at 11:51 AM, Beau Hartshorne wrote:
x,y,w,h is awkward for padding, margin, and border. DOM.Coordinates
and DOM.Dimensions define {x,y} and {w,h}, I don't think an
{x,y,w,h} Box is really needed. And to really follow the CSS
convention, the properties should be top, left, bottom, and right.
Do you see any problem defining functions like this that assume
'px' is the working unit? They're creeping in, and I'm not sure if
this is the best thing to do.
On 31-Jan-06, at 11:03 AM, Bob Ippolito wrote:
All of these look good to me. Personally I would prefer an
x,y,w,h box model, but t,l,b,r is CSS convention so I guess that's
more appropriate.
[mochikit] Re: Conditional Comments
On Jan 31, 2006, at 11:24 AM, Bob Ippolito wrote: On Jan 31, 2006, at 11:15 AM, Beau Hartshorne wrote: In some places you check for something like (self.attributeArray.compliant). My concern (bet) is that IE7 may assert that it is compliant, but still screw it up. compliant is the result of analyzing a DOM element for attributes that shouldn't be there. IE has always defined default values for every possible attribute, and I don't think they're going to change that behavior. It's not technically broken, and they have lots of real bugs to worry about :) Speaking of which... I just installed IE 7 beta 2 on one of the crappy PC laptops lying around the office: MochiKit v1.3 [IE 7.0] Type your expression in the input box below and press return, or see the notes below for more information. MochiKit.DOM.attributeArray.compliant false The standard tests all pass, the signal tests have failures (not sure if they also fail in IE6): 7, 16, 17, 22, 23, 24, 25, 26, 27 Signal also has failures in Safari.. 25 fails, and 28 raises an exception: # name: TypeError # message: Value undefined (result of expression evt.initMouseEvent) is not object. # line: 237 # sourceURL: http://mochikit.com/tests/test_Signal.js -bob
[mochikit] Re: Document.write and xhtml pitfall
On Jan 27, 2006, at 5:59 AM, Eoghan wrote: I've got a patch for this, mozilla wasn't going down the createelementns path because the value of the namespaceURI is http://www.w3.org/1999/xhtml; for true xhtml documents (those not served as text/html)... appending the child script tag the dom way is of course cool and works fine in xhtml! I've just posted the modified portion of (the end of) Mochikit.js below... just 3 lines changed, should I create a trac item for this? I went with a slightly different approach, which uses createElement (script) even on Safari. The problem is that Safari's setAttribute doesn't work correctly for script tags, so I just went with setting the properties directly. I had meant to fix that a while ago. -bob
[mochikit] Re: More screencasts
On Jan 28, 2006, at 5:34 PM, dgd wrote: What I'd really like to see is a start-to-finish video of the development of a web interface that supports drag and drop through AJAX. You're going to have to be more specific. Drag and drop through AJAX doesn't mean anything. -bob
[mochikit] Re: IE6 / Win2000 test failures
On Jan 26, 2006, at 4:16 PM, sayrer wrote: The tests at http://mochikit.com/tests/index.html fail some DOM tests for me at the moment. Version: 6.0.2800.1106 Update Versions:; SP1; Q903235; You sure that you don't have some old JS cached? Looks like you have the new version of the tests but the old version of formContents. I'm especially skeptical because the tests you cite as failing use mock DOM objects ... I just can't see how that code could fail. -bob
[mochikit] Re: MochiKit 1.2 bugs?
On Jan 24, 2006, at 2:48 AM, dmk wrote:
Hi Bob,
Quick questions:
1. Do you plan to fix it?
It's already fixed
2. in all cases current implementation does not work. it returns {w:
'undefined', h: 'undefined'} for visible elements.
Write a test case. What's there definitely works for someone, I need
to know why it doesn't work for you in order to fix it.
-bob
[mochikit] Re: formContents
On Jan 23, 2006, at 10:12 AM, Thomas Hervé wrote:
var res = MochiKit.Async.doSimpleXMLHttpRequest
(this.link,formContents('loginform'));
If it's your code, it's normal it doesn't work, or I don't know what's
this.link : formContents is a function of MochiKit.DOM, not a slot of
nodes.
If it's not your code, please post your real code.
More importantly, post the HTML for loginform.
-bob
[mochikit] Re: formContents
XMLHttpRequest does not work cross-domain.
-bob
On Jan 23, 2006, at 11:48 AM, Ricardo de Oliveira Saldanha wrote:
I made a workaround (function convert), but the function
MochiKit.DOM.formContents isn´t working for me.
Another thing I have noticed is that if I call this page from
firefox on a
remote machine I got 'undefined' as a response.. Anyone have a clue ?
function dosubmit()
{
var req = MochiKit.Async.getXMLHttpRequest();
req.open(POST,'/home/dologin.ashx',this.async);
req.setRequestHeader(Content-Type,application/x-www-form-
urlencoded;
charset=UTF-8);
alert(MochiKit.DOM.formContents($('dologin')));
// a workaround ;)
var data = queryString(convert($('dologin').elements));
//
var res = MochiKit.Async.sendXMLHttpRequest(req, data);
res.addCallbacks(onSucess,onError));
log('done');
return false;
}
function onSucess(req)
{
var divdest = $('center');
if (divdest)
{
divdest.innerHTML = req.responseText;
}
}
function onError(req)
{
var divdest = $('center');
if (divdest)
{
divdest.innerHTML =req.responseText;
}
log(onError:+keys(req));
log(onError:+req.message);
log(onError:+req.description);
}
html page
--
div id='center' style=margin-top:20%;margin-left:10%;width:200px;
form id=dologin name=dologin
table
tr
tdEmail/td
/tr
tr
tdinput style=width:150px; type=text
name=email id=email/input/td
/tr
tr
td$!{Error_Email}/td
/tr
tr
tdSenha/td
/tr
tr
tdinput style=width:150px; type=password
name=senha id=senha/input/td
/tr
tr
td$!{Error_Senha}/td
/tr
tr
td align=rightinput id=dologinbt
type=button onclick=dosubimit(); value=Entrar /input/td
/tr
/table
/form
/div
-Original Message-
From: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED]
On Behalf
Of Bob Ippolito
Sent: segunda-feira, 23 de janeiro de 2006 16:54
To: Thomas Hervé
Cc: MochiKit
Subject: [mochikit] Re: formContents
On Jan 23, 2006, at 10:12 AM, Thomas Hervé wrote:
var res = MochiKit.Async.doSimpleXMLHttpRequest
(this.link,formContents('loginform'));
If it's your code, it's normal it doesn't work, or I don't know
what's
this.link : formContents is a function of MochiKit.DOM, not a slot of
nodes.
If it's not your code, please post your real code.
More importantly, post the HTML for loginform.
-bob
[mochikit] Re: formContents
On Jan 23, 2006, at 7:52 AM, Saldanha wrote: I think that formContents may be not working ... Don't use a name attribute for your form tag. If you drop the name, then it works. Right now it thinks that elements that have a name attribute are part of the form. -bob
[mochikit] Re: Signal bug
On Jan 23, 2006, at 3:54 PM, Eoghan wrote:
I agree that modifying the event object is undesirable, however, I
think there is a strong case to add standard w3c event methods if
missing (IE, Safari 2) such as event.preventDefault.
so that you could use
...connect(myElement, onclick, function(e){e.preventDefault()});
without thinking twice about some browsers not implementing the
standard?
MochiKit doesn't modify built-in things, period. If you read one of
Beau's recent messages in this thread, you'll see that a proxy object
is used instead of mangling the event object. This lets us fix
browser bugs, but still provides access to the raw unscathed event
object if you actually want it. Everybody wins, even IE users.
Safari 2 isn't supported.. so I'm not too worried about that. I'm
sure some of MochiKit works there, but I only test on the latest
version of Mac OS X -- which means Safari 2.0.3 right now.
If someone wants to maintain Safari 1.x support (or any other
currently untested platform)... start by testing and filing bugs
(with patches), and I'll be more than happy to give commit access to
anyone who proves that they are interested and capable in fixing
platform-specific bugs without breaking the other platforms.
-bob
[mochikit] Re: DOM.js, IE 6, Unexpected call to method or property access line 357
On Jan 18, 2006, at 11:24 AM, Stephen F. Steiner wrote:
On Jan 18, 2006, at 1:56 PM, Bob Ippolito wrote:
On Jan 18, 2006, at 6:08 AM, ssteiner wrote:
TABLE( ...
TD( IMG( {'src':'someimage.jpg', 'alt':'Product Image'},null ));
That choked when used inside a table declaration.
Was that exactly it? Because the first argument is the
attributes, but you gave an IMG tag as the first argument to the
TD. There is also no reason to pass null as a second argument to
IMG, but that doesn't do anything one way or the other.
Sorry, the TD was being handled by a partial function and in
factoring out, I neglected to put in the null placeholder.
TD( null, IMG(
i.e. the correct way, was how it was being constructed.
I made it into:
image = IMG( {'src':'someimage.jpg', 'alt':'Product Image'},null );
TABLE( ...
TD(null, image);
And the problem went away. IOW, trying to manipulate the attributes
when the IMG was already in the TD didn't work, pre-building it
allowed
me to use the pre-built IMG in the table just fine.
Those two statements are equivalent in every way except for the
mistake that I pointed out above... even the evaluation order is
the same.
Are you saying that the IMG() node construction doesn't take place
untl it is used in the TD creation? The references I saw to bugs
in I.E. related specifically to manipulating the attributes of IMG
nodes that were already contained within tables.
Both of the above code snippets translate to exactly this:
Make IMG tag
Make TD tag
Put IMG tag in TD
Make TABLE tag
Put TD tag in TABLE
It doesn't matter whether you make the IMG in separate variable or
it's just used as an expression.. the same thing happens. Completely
identical code.
This is why I ask for reproducible examples of issues, because it's
so easy to miss what's actually happening that explanations are just
no good most of the time.
-bob
[mochikit] Re: DOM.js, IE 6, Unexpected call to method or property access line 357
On Jan 16, 2006, at 5:11 PM, ssteiner wrote:
Two things were causing the errors in IE.
1 I was creating an IMG node within the table body and setting the
'src' attribute was throwing an error. I moved the creation outside
the TBODY-TR-TD heirarchy, then just used TD( fully_formed_img_node)
and the problem went away.
2 I was creating an INPUT node with INPUT( {blah, blah, blah},
something_that_shouldn't_be_there) IE choked when trying to append
something_that_shouldn't_be_there to the INPUT node.
Can you give specific examples? I'm not sure I understand your
explanations. Code speaks louder than words :)
-bob
[mochikit] Re: Automated Python - Javascript Conversion using MochiKit helpers
On Jan 15, 2006, at 11:46 AM, Dethe Elza wrote: Anyway, since the goal of MochiKit is to make javascript more pythonic and less broken, why not why not just write the code in python to begin with and have it translated? I've been aware of that for a while, but it's not something I'm interested in doing. It sounds particularly fragile. Python and JavaScript are very different languages, and in many cases there's no direct translation. For example, it's not possible to represent many of Python's data types in JavaScript with anywhere near the same performance characteristics -- especially dict. Too many leaky abstractions. On the other hand, if you were to restrict the python you were using to a well-defined subset, and build a conversion tool *on top of MochiKit* then you might be able to leverage your work pretty well. It would have to be a pretty small subset, though, because there are so many things you can do in Python which are simply not possible in Javascript. At that point all you're really talking about is JavaScript with indentation instead of spaces. While I much prefer Python's style, I am proficient in a lot of languages, JS included. Having a good spec helps here. I've often wished that docutils[1] had a EBNF description for it's parser, to make it easier to reimplement a restructured text processor in Javascript (or even C), but as far as I know that's never happened, and I certainly don't have the time to do it. It's one place that simpler markups win: you can implement them client-side in Javascript. I agree completely with that. If what you're trying to translate is primarily data structures, and JSON doesn't cut it for you, then you might try out YAML[2], a superset of JSON (but still text), which can be processed in both Javascript and Python. XML is another way to go here. Translating functionality still has to be done the MochiKit way: figure out the nearest working equivalent, write the tests, write the code. If Javascript were one thing, it might be possible to automate this further, but in fact is is a twisting series of contradictory sets of bugs to be worked around, incomplete implementations, and proprietary extensions (which are necessary to use to get performance at times). I don't think anyone was talking about data structures, and I don't see any situation where YAML would do better than JSON or XML. All of them represent strictly trees, and you'd need to use extensions to any of those formats to represent specialized data types. -bob
[mochikit] Re: JS Events
On Jan 15, 2006, at 12:31 PM, Beau Hartshorne wrote: So events are driving me nuts. Normalization is difficult because some browsers get their backs up when you mess with something like event.button, or event.timeStamp. The Level 2 DOM spec is incomplete and in some cases wrong-headed (event.button, for instance). Mozilla still has some NN4 artifacts, and there are some things in IE that make sense and are useful. Anyway, all of this makes it impossible to get any UI programming done. For MochiKit, I suggest we don't bother normalizing the original event object, but instead return a MochiKit.Event object with a consistent set of properties no matter which browser it was executed on. A key event might look like this: It doesn't matter to me much either way, as long as there's a way to get at the original object if you actually need a reference to it. -bob
[mochikit] Re: DOM.js, IE 6, Unexpected call to method or property access line 357
On Jan 15, 2006, at 1:00 PM, ssteiner wrote: I'm building a table, have successfully run through my THEAD() section, and am building out the TBODY(). This code works perfectly on all the other browsers I've tried (Firefox Mac, Safari, Firefox Win). I have Microsoft's pathetic script debugger installed on the machine. Can anyone tell me what I can do with it to help get this problem fixed? I have no idea what type of introspective information would be helpful in figuring out why this is crapping out. First thing you have to do is post some code, IE tracebacks are worthless. You need TFOOT also, according to spec. In this order: THEAD, TFOOT, TBODY. -bob
[mochikit] MochiKit SVN moving to svn.mochikit.com
I'm going to move the MochiKit SVN from http://svn.red-bean.com/ mochikit to http://svn.mochikit.com so that it's easier for me to manage. http://svn.mochikit.com has been a mirror of the red-bean repository for many months now, and has had consistently better uptime (with the bonus that the trac timeline updates instantly, etc.). In order to switch repositories, simply checkout again or use the following command from your checkout directory:: svn switch --relocate http://svn.red-bean.com/mochikit http:// svn.mochikit.com -bob
[mochikit] Re: input disabled attr
On Jan 10, 2006, at 11:24 AM, mario ruggier wrote: On Jan 10, 2006, at 6:34 PM, Bob Ippolito wrote: The only thing it does it call into updateNodeAttributes, which will rewrite a few of the names for IE compatibility (e.g. class - className) and let you use an object to set a bunch of nested properties (e.g. with the style object). Technically it uses setNodeAttribute(input, attrname, value) rather than input [attrname] = value, so the names it's using should match XHTML, not JavaScript, conventions. Thanks a lot for the explanation. Sounds like you've probably found a bug in Firefox. I don't see anything in the code that should cause that behavior. Strange, because checking with Safari 1.3.1, the same problem occurs. Also, I realize I did not have the latest FireFox, so I have now tried it with a newly installed 1.5, that however gives the same problem. This is on OS X 10.3.9. So, to repeat, following call does not enable a previously disabled input element: setNodeAttribute(input, 'disabled', false); Can the problem be coming from beyond the browser? Please post a full example that demonstrates what it does do and what it should do and I'll look into it myself. -bob
[mochikit] Re:
On Jan 10, 2006, at 4:33 PM, Jonathan Gardner wrote: Here's the latest. Beau Hartshorne has done a lot of work bringing it up to standard. Here are some of the changes: 1. Fixed bug in IE. 2. Handles errors differently. It will aggregate them then raise a single error with the original errors intact rather than log them. 3. Should conform to MochiKit standards a lot better. 4. Turns off bubbling of events. They can be uncancelled if you really want to. I am thinking of either modifying IE's event object OR creating a proxy object that behaves according to DOM standard. That way, when you get an event, you don't have to guess which interface to use. Thoughts? Let's just go ahead and modify the event object in-place. Dojo does this, it works for them. IE is a compliance wasteland anyway. It would be nice to detect non-compliance by means other than checking the User-Agent though, because maybe someday hell will freeze over and IE's event objects will work like everyone else's does. -bob
[mochikit] Re: Porting Rico effects into Mochikit
On Jan 10, 2006, at 5:48 PM, Yehuda Katz wrote: I would love to see the accordion effect, and the animate position and size effects from Rico ported over to Mochikit. Who wouldn't? What we need is for someone to actually do the work. I think some of this work has already been done by someone, but I haven't seen any hit the wiki or this list yet though. If it's out there, please make sure it hits http://trac.mochikit.com/ so that I can bring it in. -bob
[mochikit] Re: input disabled attr
On Jan 9, 2006, at 12:40 PM, mario ruggier wrote: confused... using setNodeAttribute() to set the disabled attribute of an input html element seems to do nothing, but setting it directly works fine. I.e. setNodeAttribute(input, 'disabled', true); setNodeAttribute(input, 'disabled', false); seems to not do anything, but the following does what I expect: input.disabled = true; input.disabled = false; What am I missing? Try it with svn trunk, I think 1.1 had a problem with that function. -bob
[mochikit] Re: Wrapping an element (Mochikit.DOM)
On Jan 6, 2006, at 7:03 AM, Yehuda Katz wrote:
To be specific, here's what I'm doing:
body
divp id=myPHello/p/div
script type=text/javascript
var myP = $('myP');
myWrappedHello = DIV({style : 'border: black 1px solid; padding:
5px;'}, myP);
/script
/body
For some reason, the browser just eliminates the original P. Is that
because it's being inserted in a brand new DIV? If so, how can I get
the new Div back where the old P was?
Maybe something like this:
var myP = $('myP');
var myWrappedHello = DIV({style : 'border: black 1px solid; padding:
5px;'});
swapDOM(myP, myWrappedHello);
myWrappedHello.appendChildNode(myP);
-bob
[mochikit] Re: can we optionally get formContents to include empty form elements?
On Jan 6, 2006, at 7:28 AM, Zachery Bir wrote: The Zope 3 formlib chokes when all the attributes specified by a Schema interface aren't present (that haven't explicitly been omitted from the view). But MochiKit eliminates empty form elements from the result of a formContents. Any chance we can optionally get it to include those as empty strings, or the like? If you write a patch I'll take it. It doesn't have to be optional, leaving them in all the time shouldn't break anything. -bob
[mochikit] Re: question about bind
On Jan 6, 2006, at 9:21 AM, Doug Crawford wrote:
What is the simplest way to repeatedly call an object function for an
array of objects. Here is one way:
forEach(collection, function(element) { element.someMethod(); } );
Is there a simpiler way using bind that does not require defining an
anonymous function?
No, there is not. bind doesn't do that.
What you want is something similar to itemgetter, which does return
obj[name].apply(obj, arguments) instead of return obj[name].
-bob
[mochikit] Re: Mochikit conflicts with TinyMCE
On Jan 6, 2006, at 2:04 PM, Yehuda Katz wrote:
Depending on whether I place the TinyMCE code first or the Mochikit
code, only the functions from the first work.
I would like to be able to use Mochikit with TinyMCE. Any idea on what
the conflict is?
Not without more specifics so that a testing environment could be set
up. We need to know what browser this fails with (including
version), which versions of TinyMCE and MochiKit, and which
distribution of MochiKit is being used (packed, unpacked, or
individual script tags for each component). The packed version or
individual script tags are definitely the most compatible as
there's no magic, but both still export symbols unless dojo or JSAN
is around. It also would be nice to know what MochiKit-based code
fails if TinyMCE is loaded first and. MochiKit is very modular and
mostly loosely coupled, so it's not really possible to just break
it in general.
You could hack around it and put MochiKit into namespace
compatibility mode by executing this JavaScript sometime before
loading MochiKit (I'll add a more sane flag for before the next
release):
JSAN = {use:function(){}};
If that is used, then you'll have to use fully qualified references
to everything.. e.g. MochiKit.Base.extend(...) instead of extend
(...), but it will almost definitely stay out of the way.
-bob
[mochikit] Re: Is MochiKit Production?
On Jan 6, 2006, at 4:22 PM, Mike wrote: Sure, I read that it is production. It says IE 6.0 + is supported, while test_MochiKit-DOM gives me the following error: not ok 59 - didn't throw span style=color: red; font-weight: boldvv# Failed test /spanok 60 - mock formContents names That's mostly harmless. It's the result of a really nasty bug in JScript itself (Microsoft's pathetic ECMAScript implementation) where it doesn't throw exceptions under some circumstances. There's a way to fix it, but I haven't had a need to. All that means is that an error isn't going to propagate properly when using that particular feature (withWindow() or withDocument()) until a workaround is introduced. You are very unlikely to need either of those features, and even less likely to need that error propagation to work correctly. On firefox it gets stuck at: test_MochiKit-Async.html..ok test_MochiKit-Base.html...ok test_MochiKit-DateTime.html...ok test_MochiKit-DOM.htmlok test_MochiKit-Format.html.ok test_MochiKit-Iter.html...ok test_MochiKit-Logging.htmlok test_MochiKit-MochiKit.html...ok test_MochiKit-Color.html.. This is a bug in the unit test suite used, each test file individually runs fine. I'll be replacing Test.Simple with something more reliable at some point. And also the first tutorial I found from web http://argv0.net/static/mochitut/1/ doesn't work on my Internet Explorer! You can write code that doesn't work in IE with any JavaScript library. All of MochiKit itself is IE compatible. I am new in AJAX, and want to use it, but would you use MochiKit for a large scale web app? It depends on what versions of IE you need to support, and how much work you're willing to put into it. MochiKit supports a baseline of IE 6, but if you wanted IE 5.5 compatibility it's certainly possible (and probably not even hard) but you'd have to maintain that yourself. The reason MochiKit doesn't currently support IE 5.5 is that the testing framework, Test.Simple, didn't work correctly on that platform, so I have no reasonable way of knowing what needs tweaking. Since Test.Simple is going to go away relatively soon, that should be less of an issue. If MochiKit doesn't suit your needs, you should take a look at Dojo. That's the only general purpose library I'd consider using, because the others have serious issues. If Dojo was in its current state 9 months ago, MochiKit probably wouldn't exist. That said, MochiKit most definitely isn't going to disappear or become unmaintained :) -bob
[mochikit] Re: adress div in a different frame
On Jan 4, 2006, at 11:51 PM, Matthias Teege wrote:
because of a bug in IE I rebuild my current app. How do I address a
placeholder in another frame?
replaceChildNodes(preview , image); and
replaceChildNodes(framemain.preview , image);
This should work, in svn:
withWindow(frameMain, function () {
replaceChildNodes(preview, image);
});
-bob
[mochikit] Re: elementDimensions
On Dec 24, 2005, at 12:03 PM, Ryan Nichols wrote:
Is there a chance we can add this to MochiKit.DOM?
function elementDimensions(e) {
e=$(e);
return {w: parseInt(computedStyle(e, 'width').replace('px',
'')), h: parseInt(computedStyle(e, 'height').replace('px', ''))};
}
This is in r484 (but isn't tested yet).
http://mochikit.com/doc/html/MochiKit/DOM.html#fn-elementdimensions
-bob
[mochikit] Re: sortable_tables demo
On Dec 29, 2005, at 3:55 PM, Dan wrote:
The demo uses a function to scrape the text and create objects using a
switch:
switch (this.columns[j].format) {
case 'isodate':
obj = isoDate(obj);
break;
case 'str':
break;
case 'istr':
obj = obj.toLowerCase();
break;
// cases for numbers, etc. could be here
default:
break;
What would the case look like for a numeric column?
This exact question was asked and answered last month:
http://tinyurl.com/74gzm
-bob
[mochikit] Re: MochiKit Dojo - compatibility with TableBarChartDemo.js ??
On Dec 27, 2005, at 3:36 AM, Miguel A. Ruz wrote: I´m working with Mochi Dojo and don´t work. In my web page, I have: script dojo.hostenv.setModulePrefix(MochiKit, ../../../../libs/js/MochiKit); dojo.require(MochiKit.*); /script But working with CanvasGraph.js and TableBarChartDemo.js, i have this error: self.push is not a function addLoadEvent is not defined TableBarChartDemo.js This is an issue with CanvasGraph, not MochiKit. MochiKit doesn't import any symbols to the global namespace when used with Dojo, and apparently CanvasGraph doesn't account for this. If you load MochiKit with a script: tag *before* dojo, then it should work normally. Thanks Bob, now I load Mochikit before dojo, but I have a new error: Error: arg has no properties Source File: /libs/js/MochiKit/Base.js Line: 279 If I don´t use dojo, the web page work normally. I can't explain that, and I don't really have time to put together everything needed to diagnose the issue. If you provide a full runnable example (including CanvasGraph, dojo, and the version of MochiKit you're using) and file it as a ticket on http:// trac.mochikit.com/ then I might be able to look into it soon. Either way, it's almost certainly an issue with CanvasGraph and you should contact the author. -bob
[mochikit] Re: MochiKit Dojo - compatibility with TableBarChartDemo.js ??
That's reassuring. I'm not surprised in that case. Libraries like openrico, scriptaculous, prototype, etc. are all written in such a way that compatibility issues are effectively guaranteed. MochiKit makes an effort to be aware of these kinds of issues, but I don't care about it enough to test it myself so there are certainly going to be some failures. If you come up with a patch that fixes this issue, submit it as a ticket in trac and I'll commit it as long as it doesn't break anything else. In other words, modifying Object.prototype is dumb, but people do it anyway. On purpose. I don't know what's wrong with them. Modifying other built-in objects is also asking for trouble, but Object.prototype is very dangerous. MochiKit and Dojo definitely did not make this unfortunately common mistake to any degree. -bob On Dec 27, 2005, at 3:46 AM, Miguel A. Ruz wrote: Well, the problem is with openrico: script src=/libs/js/ajax/rico.js type=text/javascript/script Thanks. -Mensaje original- De: mochikit@googlegroups.com [mailto:[EMAIL PROTECTED] En nombre de Miguel A. Ruz Enviado el: martes, 27 de diciembre de 2005 9:36 Para: 'Bob Ippolito' CC: 'MochiKit' Asunto: [mochikit] Re: MochiKit Dojo - compatibility with TableBarChartDemo.js ?? I´m working with Mochi Dojo and don´t work. In my web page, I have: script dojo.hostenv.setModulePrefix(MochiKit, ../../../../libs/js/MochiKit); dojo.require(MochiKit.*); /script But working with CanvasGraph.js and TableBarChartDemo.js, i have this error: self.push is not a function addLoadEvent is not defined TableBarChartDemo.js This is an issue with CanvasGraph, not MochiKit. MochiKit doesn't import any symbols to the global namespace when used with Dojo, and apparently CanvasGraph doesn't account for this. If you load MochiKit with a script: tag *before* dojo, then it should work normally. Thanks Bob, now I load Mochikit before dojo, but I have a new error: Error: arg has no properties Source File: /libs/js/MochiKit/Base.js Line: 279 If I don´t use dojo, the web page work normally. html head script src=/libs/js/MochiKit/MochiKit.js type=text/javascript/script script src=/libs/js/MochiKit/Base.js type=text/ javascript/script script src=/libs/js/MochiKit/Logging.js type=text/javascript/script script src=/libs/js/MochiKit/Async.js type=text/javascript/script script src=/libs/js/MochiKit/Color.js type=text/javascript/script script src=/libs/js/MochiKit/Format.js type=text/javascript/script script src=./CanvasGraph.js type=text/javascript/script script src=./TableBarChartDemo.js type=text/javascript/ script /head body div class=center table id=datatable class=data style=display: none; thead trthPepito/ththx2/ththx!/ththsqrt(x)/ th/tr /thead tbody trtd0/tdtd0/tdtd0/tdtd0/td/tr trtd1/tdtd1/tdtd1/tdtd1/td/tr trtd2/tdtd4/tdtd2/tdtd1.414/td/tr trtd3/tdtd9/tdtd6/tdtd1/td/tr trtd4/tdtd16/tdtd24/tdtd2/td/tr trtd5/tdtd25/tdtd120/tdtd2.23/td/tr /tbody /table /div div class=centercanvas width=500 height=200 id=fromtable/canvas/div /body /html
[mochikit] Re: Escaped HTML
On Dec 27, 2005, at 2:17 PM, [EMAIL PROTECTED] wrote: My JSON returns an actual string of HTML back to MochiKit however, this HTML is displayed escaped! It doesn't seem as though MochiKit is explicity doing this, and I was wondering if any JS experts out there had any opinion?! If you want to replace the contents of an element with HTML, you must use innerHTML to do it. MochiKit.DOM works with the DOM exclusively, which does not interpret strings as HTML. -bob
[mochikit] Re: MochiKit Dojo - compatibility with TableBarChartDemo.js ??
On Dec 26, 2005, at 12:20 PM, [EMAIL PROTECTED] wrote: I´m working with Mochi Dojo and don´t work. In my web page, I have: script dojo.hostenv.setModulePrefix(MochiKit, ../../../../libs/js/MochiKit); dojo.require(MochiKit.*); /script But working with CanvasGraph.js and TableBarChartDemo.js, i have this error: self.push is not a function addLoadEvent is not defined TableBarChartDemo.js This is an issue with CanvasGraph, not MochiKit. MochiKit doesn't import any symbols to the global namespace when used with Dojo, and apparently CanvasGraph doesn't account for this. If you load MochiKit with a script: tag *before* dojo, then it should work normally. -bob
[mochikit] Re: postSimpleXMLHttpRequest (Was: GET vs POST in MochiKit.Async)
On Dec 26, 2005, at 11:32 AM, Ian Bicking wrote: On 12/26/05, Robin Munn [EMAIL PROTECTED] wrote: Could we get a postSimpleXMLHttpRequest() function, like the one Ian wrote above, into MochiKit? Well, almost like the one Ian wrote above -- it does URL-encoding of the POST body, and I'd like to see JSON encoding, if possible. The reason I'd like to see this is because of the very cool AjaxDataController that Jeff Watkins just checked into TurboGears. It expects a POST with JSON format for its create and update methods, and I'd like a dirt-simple way to call its POST methods as well as its GET methods. I find the use of JSON there rather weird. URL-encoded requests can be generated with or without Javascript; if the data can be represented that way (i.e., a flat dictionary) than that should be preferred. It's just all-around simpler. While it would be fine to create another method (there's a simpleJSONRequest function, isn't there?) the default really seems like it should be url-encoded. I pretty much agree here. There is a loadSONDoc. The thing about non-GET is that there's so many things to specify: - URL - Pass parameters on the query string - Set headers - Payload encoding: URL encoding, XML, JSON, raw data - Method (PROPLIST, etc.) What would an API like this look like and what should it be called? It pretty much has to take an URL then an object argument, because most of the time you're going to want to default to URL encoding, no headers, POST, no qs args and there's no obvious pecking order for the things you might want to specify (other than URL). -bob
[mochikit] Re: only json?
I have just read the article of http://argv0.net/static/mochitut/1/; and downloaded the sample files. The Sample works well, but what I need is to create the json data dynamicly.So I change the extension of posts.json to posts.py and the url in LoadJSONDoc to posts.py, but I got the error of SyntaxError : syntax error. That tutorial is entirely static and has nothing dynamic whatsoever about it. It's up to you to figure out how to write server-side code. I'm not sure what you're doing with which framework/server, but clearly it's not serving up the right thing. Look at the output with curl or something, I'm sure you won't see a valid JSON document as a result. Can the data of JSON be created dynamicly? Yes, of course. Another question: May I keep the connection to server alive and get the data from server continually? Not portably. I believe there is some code in Nevow's trunk that does something like that via MochiKit though, but it's definitely a hack. A better solution is to use Flash's XMLSocket if you want a persistent connection. If you can depend on Flash 8, it's not even that bad to communicate from JS to Flash. -bob
[mochikit] Re: Trouble with replaceChildNodes
I am brand new to MochiKit and am real rusty on js, but... The problem
I am haveing is that the js I am using keeps throwing an error in
Firefox saying Error: replaceChildNodes is not defined
One of three things is happening:
1. You forgot the script src=MochiKit/MochiKit.js/script for MochiKit
2. You are using JSAN but not JSAN.use('MochiKit', ':common')
3. You are using Dojo Toolkit
When using JSAN (without ':common') or Dojo, MochiKit doesn't export
symbols. You'd have to use MochiKit.DOM.replaceChildNodes,
MochiKit.Async.loadJSONDoc, etc.
Here is the js I am using cut and pasted from the html:
SCRIPT TYPE=text/javascript
function requestPageList() {
/* d = loadJSONDoc(/buTest?turbogearsfmt=json);
d.addCallback(showPageList); */
var quote= new Array(1);
quote[0] = PIt worked!!/P;
showPageList(quote);
}
function showPageList(result) {
replaceChildNodes(null, null);
}
/SCRIPT
Clearly you shouldn't be calling replaceChildNodes with null as the first
parameter... that needs to be the id of an element as a string, or a
reference to an element. However, there's three things about your
implementation of requestPageList that are off:
- Calling new Array() is silly, arrays have syntax.
- You should ALWAYS declare your local variables, default scope is global.
If you don't, you can't safely call a function from another function
because they might clobber each other's variables!
- MochiKit.DOM accepts DOM elements, not raw markup. If you want to set
the innerHTML on something, you should just do it that way.
function requestPageList() {
if (false) {
var d = loadJSONDoc(...);
} else {
var d = succeed([P(null, It worked!!)]);
}
d.addCallback(showPageList);
}
-bob
[mochikit] Re: [patch] DOM.formContents select mutliple
Last night, I noticed that formContents did not support select ... multiple=multiple elements. Actually, I don't think it was working for select at all on IE but I cannot check that right now. The attached patch adds support for multi select form elements and is working for single select elements too. AFAICT, other behaviour is unchanged. I've tested on IE 5.5, IE 6. Firefox 1.07 and Safari 1.3.1 and, AFAICT, is working fine. Note: formContents has a slight difference in behaviour across browsers. Some send the submit button(s) in the query string; some don't. Is that an issue? The patch looks good, but it might be a few days before I have time to apply it. The patch's chance at making it in would be significantly improved if it ended up in a ticket at http://trac.mochikit.com/ -- my laptop is in the shop and I have thousands of messages piling up in my inbox since my mail filters are client side... In other words, the patch will probably get lost if you don't. Please also submit a ticket for the formContents difference. It'd save me a lot of time if you posted specifics about which browsers have which behavior, preferably with some example HTML that can express the difference. -bob
[mochikit] Re: Issue with MochiKit.DOM on Safari and OmniWeb
On 12/19/05, Bob Ippolito [EMAIL PROTECTED] wrote: while implementing a nifty TabPanel using MochiKit, I had a problem running my script with Safari and OmniWeb, while the same script works fine with FireFox (both 1.07 and 1.5). Attached a simple page that shows the different behaviour if loaded with different browsers. Am I using the library the wrong way, or is there a real problem somewhere? I don't think what you're trying to do is going to work. In my experience, moving DOM elements around in the hierarchy like that is just plain buggy in most of the implementations. Doesn't have much to do with MochiKit. I'd try a different approach. Thanks Bob for you answer; the only different approach I can think of, is making a deep copy of the childNodes of the first node; are there other viable options? If a deep copy is the way to go, is it better to traverse the DOM sub-tree and copy each element on its own, or is better/simpler to use the toHTML to read and document.write to write the whole subtree altogether? elem.cloneNode(true) is a deep copy... I still don't understand why you need to do all that reparenting though. -bob
[mochikit] Re: Signals/AOO/Event handlers
On Friday 16 December 2005 18:45, Bob Ippolito wrote: I don't know if the docs are formatted correctly. My experience with ReST began today. I couldn't build the docs because I couldn't get a good version of docutils. You need to check it out from svn. Assuming that you have setuptools and subversion installed, this should work:: easy_install svn://svn.berlios.de/docutils/trunk#egg=docutils Actually it looks like this would be quicker, since it shouldn't grab the sandbox and web stuff:: easy_install svn://svn.berlios.de/docutils/trunk/docutils#egg=docutils
[mochikit] Re: Mochikit.Visual
David Ascher wrote: I'm trying to play around w/ the rounded corners from MochiKit in a test page. Now, my current test page is not looking great in either FF or Safari: http://da.textdriven.com/dadojo/tests/mochi.html Is that a bug, or am I misusing the code? Looks okay to me, except rounded corners don't work in Safari (this is a known issue). I dunno what looks wrong in Firefox though; what are you expecting to see? Uh, no. Rounded corners work in Safari. Safari 2.0.2 anyway, I don't test on older versions. If they don't work, I would like to see a bug filed at http://trac.mochikit.com/ that includes full information to reproduce (html, OS and browser version). -bob
[mochikit] Re: Logging Pane: 'doc.body' reference
On Dec 13, 2005, at 1:22 PM, [EMAIL PROTECTED] wrote:
Something I noticed in revision 474:
Tried to use the createLoggingPane function from javascript
included in
the XUL document i'm working on, but it didn't work because of line
246
in LoggingPane.js:
doc.body.appendChild(debugPane);
This won't work with most XUL pages. I got around it with:
doc.getElementById('taskdesigner').appendChild(debugPane);
Try updating to 475 and adding div id=_MochiKit_LoggingPane / to
the end of your document. In that case, it shouldn't use
doc.body.appendChild.
-bob
[mochikit] Re: Order of extra arguments when using Deferred.addCallback()
On Dec 12, 2005, at 11:38 AM, Tommi Virtanen wrote: Bob Ippolito wrote: I just noticed that d.addCallback(foo, bar) results in foo being invoked with bar as the *first* argument, rather than the second. Could this be changed? It's highly confusing, especially when taken together with JavaScript's overall poor error reporting that leads to mistakes in this area being silently lost forever. No, it's that way on purpose. The difference is well documented, and I'm pretty sure it's less confusing for people who haven't already been conditioned by Twisted. Please please *please* reconsider. Using nevow.athena will be horribly confusing if we need to constantly mix two styles. Write a patch and I'll consider it -bob
[mochikit] Re: MochiKit.Compat and IE 5.5 status
On Dec 9, 2005, at 7:09 PM, Antti Vähäkotamäki wrote: MochiKit.Compat doesn't seem to be in the repository anymore and I couldn't find any information on the issue. Is it merged into the other modules or is it completely abandoned? What is the current status of IE 5.5 compatibility and what are the future plans for it? MochiKit.Compat was a waste of space so I tossed it. It never did anything useful. I don't care about IE 5.5. If someone else goes through the trouble of making it work, I'll take the patch. However, don't bother unless you're going to have to maintain it because I'm not going to test on IE 5.5. If someone is seriously interested in taking that on, I'd be happy to dole out commit bit after I see a working patch. -bob
[mochikit] Re: copy interpreter
On Dec 8, 2005, at 6:57 AM, Matthias Teege wrote: I've try to copy examples/interpreter/ to a local machine with wget -m --convert-links http://www.mochikit.com/examples/interpreter/ I can open the index.html after that but can't execute some command. Is there something special in the setup on mochikit.com There's nothing at all special about it, but why not just download MochiKit? All the examples come in the zip, and they're all in the subversion repository as well. -bob
[mochikit] Re: Using iterables for complex calculation
On Dec 8, 2005, at 2:59 PM, Brendan Crosser-McGay wrote: This is just a little request, I was wondering if anyone has some simple examples of all the iteration functions being used. I feel like I'm missing out on some really slick functions. Since they aren't all readily obvious how they work just from their name. Plus I'm more of a work by example kinda guy :) What don't you understand in the documentation? Almost all of the definitions are by abstract example. http://mochikit.com/doc/html/MochiKit/Iter.html -bob
