[mochikit] Re: problem with getElementPosition
Felipe, getElementPosition works for most simple cases. In general, the more complicated the CSS is, the less reliable it is. We'd need to see a very simple test to see what the problem is, and even then, I'm not sure if we could work around it. Beau On 1-Dec-07, at 7:11 PM, Felipe Alcacibar B wrote: I'm creating a dinamic menu Object with MochiKit all works fine, but in getElementPostition i got some troubles with the position that it gives to me. i'm using the follow html structure to cerate the menu. ul li style=float: left !-- to use a horizontal menu -- menu 1 div style=position:absolute ul li menu 1-1/li /div /li /ul But getElementPosition gives me a position like the childs divs is not hided, and like a vertical list (without the float: left option). it is a bug or a bad use of the function? i got some example in http://devel.tryer.cl/fullplanet/ab/ menutest.php i explain it. the a alerts, it is to stop a compiler to see how is the position of the li curernt element. the red divs, are appedned to the body with de x and y coordinates gived from geElementPosition. acknowledged greetings. Felipe Alcacibar. Development of systems and solutions. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: setOpacity, MSIE and tr
Felipe,
Thanks for this -- would you mind creating a ticket in trac with your
code?
Beau
On 8-Nov-07, at 7:39 AM, Felipe Alcacibar B wrote:
Hi, i am a happy user of MochiKit, well, i need to apply opacity
filter to a tr element, (table row) but it works in firefox and do not
work on MSIE, i cannot understand why, then when i read the msfn, i
got it, the problem is the opacity filter does not work on tr
elements, and then i made some modifications to a setOpacity function,
i post it, maybe can be useful.
setOpacity: function (elem, o) {
elem = MochiKit.DOM.getElement(elem);
var self = MochiKit.Style;
if(/MSIE/.test(navigator.userAgent)
elem.nodeName.toLowerCase()
== tr) {
var cellTags = ['TD', 'td', 'th', 'TH'];
while( cellTag = cellTags.shift()) {
if(cellsList =
elem.getElementsByTagName(cellTag)) {
for(i=0;icellsList.length;i++)
self.setOpacity(cellsList[i],
o);
}
}
} else {
if (o == 1) {
var toSet = /Gecko/.test(navigator.userAgent)
!(/Konqueror|
AppleWebKit|KHTML/.test(navigator.userAgent));
elem.style[opacity] = toSet ? 0.99 : 1.0;
if (/MSIE/.test(navigator.userAgent)) {
elem.style['filter'] =
self.getStyle(elem,
'filter').replace(/alpha\([^\)]*\)/gi, '');
}
} else {
if (o 0.1) {
o = 0;
}
elem.style[opacity] = o;
if (/MSIE/.test(navigator.userAgent)) {
elem.style['filter'] =
self.getStyle(elem,
'filter').replace(/alpha\([^\)]*\)/gi, '') +
'alpha(opacity=' + o * 100 + ')';
}
}
}
},
cheers
Felipe.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Mochikit preventDefault() example don't work
That sounds like a browser problem. Some keyboard event's can't be overridden. Beau On 5-Nov-07, at 10:27 AM, Rodrigo Avila wrote: Hi all, I'm trying to use the Mochikit example (http://www.mochikit.com/doc/ html/MochiKit/Signal.html) in 4 browsers: Safari, Opera, Firefox e IE (all in Windows Vista). But the Check this box to test preventDefault() in your browser checkbox don't work for F1 key in IE and Safari (when I hit F1 with the checkbox checked, the help screen appears). Someone can talk me how I can make this work? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: window onclick doesn't work in IE
On 19-Oct-07, at 2:30 AM, Olli Wang wrote:
Hi, I just tried:
connect(window, 'onclick', function () {alert('test')})
When I click on the window I should get an alert message. But it works
fine on Fx, Safari and Opera, but not in IE 6 and IE 7. What's wrong
about this function for IE? Any help would be appreciated.
Olli, try connecting to the document object. That might do what you
want. So:
connect(document, 'onclick', function () {alert('test')})
Beau
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: event.target missing
On 26-Sep-07, at 10:59 PM, hzlabs wrote: But what i did expect was, that when i send a signal to the target via the signal function - myImg in your example - the event object e should contain both e.target() (myImg) and e.src() (myP). The later as the DOM element the function is connected to the event, target as the element the signal was sent to.. Helmut, This looks useful. I'd encourage you to try to modify Signal to make it work the way you'd like, and submit a code patch to http:// trac.mochikit.com/. If it looks OK, I'll commit the change to MochiKit. Thank you! Beau --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Where to start with google-map like thing
I'm really new to javascript and Mochikit, but with python experience. I have been playing a bit with Mochikit, but I haven't quite gotten the knack of it yet. I would like to display a relatively large image in pieces with user interaction (simple scrolling of the image). I can leave the AJAX stuff out for now. I just want to load the image and be able to grab is and move it up and down in a window. Any suggestions about what pieces I should look at to accomplish the task? Sean, Have a look at MochiKit.Signal and MochiKit.Style. When you're ready for the AJAX, look at MochiKit.Async. The doc index is here: http://www.mochikit.com/doc/html/MochiKit/index.html Beau --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Activity
On 18-Aug-07, at 8:44 AM, Lee Connell wrote: Mochikit hasn't seen any activity in the revision history at least since 06, is mochikit fading? We're pretty busy with our own projects, and haven't had much time to tag a release. /trunk is very stable, and is updated with features and bugfixes regularly: http://trac.mochikit.com/browser/mochikit/trunk --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: signals, onload, maybe too late?
On 14-Aug-07, at 8:34 AM, csnyder wrote:
The standard way to solve this problem seems to be implementing your
own ondomload event. Perhaps this is something to be included in
future versions of MochiKit (I'm using 1.3) as it would certainly make
JavaScript suck less.
Here's my hack implementation as a basic example. It requires a p
class=bottom/p at the end of the document, right before
/body/html...
// signal ondomload when body element has loaded
// loosely based on http://brothercake.com/site/resources/scripts/
domready/
ondomloadTries = 0;
ondomloadDelay = 500;
ondomloadInterval = setInterval( function() {
ondomloadTries++;
if ( ondomloadTries = 12) {
log(Too many ondomload tries, something went wrong.);
clearInterval( ondomloadInterval );
}
bodies = getElementsByTagAndClassName('p', 'bottom');
log(Looking for body,ondomloadTries,bodies);
if ( bodies.length 0 ) {
log(signal ondomload!);
try {
signal(window,'ondomload');
}
catch ( e ) {
log(EXCEPTION,e.message,e.errors);
}
clearInterval( ondomloadInterval );
}
}, ondomloadDelay );
I haven't looked into this recently, but I was never happy with the
way the ondomload stuff was implemented. In my code, I tend to do
just add a script tag just before /body. So in this case, you'd
do something like:
script type=text/javascript charset=utf-8
signal(window,'ondomload');
/script
/body
/html
Beau
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Intercept Form Submit
On 27-Jul-07, at 9:45 AM, Karl Guertin wrote:
What is the most efficient way to intercept a form submit event?
onsubmit in the form tag? onclick on the submit button? Make
use
of the connect function? Something else? Additionally, I would
prefer that this method fail in a way that allowed for a normal
submit
to occur if JavaScript were disabled.
connect(formElement,'onsubmit',function(e){
console.log(e); //see what's in the Signal event if you don't know
return false; //prevent form submission
});
return false; doesn't do anything here, this should look like:
connect(formElement,'onsubmit',function(e){
console.log(e); // see what's in the Signal event if you don't know
e.stop(); // prevent form submission
});
Beau
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: MochiKit Development
On 18-Jul-07, at 1:42 PM, machineghost wrote: But Mochikit is a WONDERFUL library. It's better than any other JS library I've worked with, and I've tried a few. So I (and I imagine, many others in the Mochikit community) would like to be able to user the library with confidence that doing so will not screw me in the end. This is why I believe active development is important for Mochikit (as it is for any non-for-profit software library). I think you can rely on us to fix MochiKit problems we experience with our commercial software. There's not much overhead for you to isolate and fix problems in JavaScript. I don't think it's unreasonable to ask that you just submit a patch if you find something broken or lacking. If the patch is good, it's likely we'll apply it to MochiKit pretty quickly. Beau --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: __disconnect__ (analog to __connect__)
Hi Lalo,
Could you submit this as a trac ticket with the patch?
Thanks,
Beau
On 20-May-07, at 1:11 PM, Lalo Martins wrote:
Hi.
Straight to the point: I'd like to make a case for a __disconnect__
interface, like __connect__.
My use case is: I have a small library that wraps Google, Yahoo, etc
maps. I'm very happy that I don't need to listen for events I don't
need; I can call GEvent.bind() or its analogue on the __connect__
method. But I never unlisten, since there is no __disconnect__.
(Actually, I did an ugly hack on the event handler to check if the
event
is disconnected, but that's not quite ideal.)
Patch follows:
===
--- MochiKit/Signal.js (revision 1292)
+++ MochiKit/Signal.js (working copy)
@@ -695,11 +695,14 @@
return;
}
ident.connected = false;
+var src = ident.source;
// check isDOM
if (!ident.isDOM) {
+if(typeof(src.__disconnect__) == 'function') {
+src.__disconnect__(ident);
+}
return;
}
-var src = ident.source;
var sig = ident.signal;
var listener = ident.listener;
===
best,
Lalo Martins
--
So many of our dreams at first seem impossible,
then they seem improbable, and then, when we
summon the will, they soon become inevitable.
-
personal:http://lalo.hystericalraisins.net/
technical:http://www.hystericalraisins.net/
GNU: never give up freedom http://www.gnu.org/
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Disabling the tab Key
On 9-May-07, at 12:13 PM, MikeC wrote: I'm starting to think Opera has a bug that prevents you from disabling the default action of the tab key. I found the following excerpt in an Opera-related forum called Dev Opera which seems to agree with my experience. This makes sense. Thank you for looking into this. If this is a critical feature and Opera is a critical browser, I'd suggest you look at another way to address your use case. Good luck! Beau --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Disabling the tab Key
On 8-May-07, at 11:47 AM, MikeC wrote:
The following script disables the tab key (and all other keys for that
matter) in Firefox, but doesn't disable the tab key in Opera 9.2 nor
in IE 6.0. Can someone explain to me how to write javascript that
would disable the tab key in all three browsers? Thanks in advance.
html
body
script type='text/javascript' src='MochiKit.js'
/script
form name=TheForm
input type='text' name='text1'/
input type='text' name='text2'/
/form
/body
script type='text/javascript'
function MisterKeyPress(e)
{
e.stop();
}
connect(self.document.TheForm.text1, 'onkeypress',
MisterKeyPress);
connect(self.document.TheForm.text2, 'onkeypress',
MisterKeyPress);
/script
/html
Have you tried 'onkeydown' instead of 'onkeypress'?
Beau
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Disabling the tab Key
On 8-May-07, at 3:15 PM, MikeC wrote: Your suggestion produced the following results. - Firefox and IE 6.0 - all key presses seem to be DISabled -Opera 9.2 - all key presses seem to be ENabled So you seem to have discovered the secret for handling two of my three browsers. But how do I disable the tab key in Opera 9.2? This is interesting because my boss who is also our system architect suggested to use Mochikit because a major design point is that you don't really have to struggle very much with differences among the many available browsers. But I can see that although this is a goal in Mochikit, I can also see that it must be a constant uphill battle to achieve this. In general, use 'onkeypress' handlers for keys that generate visible characters, and 'onkeydown' handlers for invisible characters. I don't know why Opera won't let you disable the tab key. It'll take some trial and error to figure it out. (Have you tried listening on window or document instead of on the form field? Have you tried doing something like input type=text onkeydown=return false; /?) Please let us know what you discover. Thanks, Beau --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Captuing Key Events
On 15-Apr-07, at 6:20 PM, briandichiara wrote:
var actions = Mochikit.connect($('directory'), 'onkeydown',
This should be:
connect('directory', 'onkeydown',
or:
MochiKit.Signal.connect('directory', 'onkeydown',
Signal does the $('directory') for you. You don't need to return
false from the function. To stop the default behavior, use
e.preventDefault() instead. If you're just learning MochiKit, it
might make sense to try something a b
Beau
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Captuing Key Events
(Resent with the rest of the email...)
On 15-Apr-07, at 6:20 PM, briandichiara wrote:
var actions = Mochikit.connect($('directory'), 'onkeydown',
This should be:
connect('directory', 'onkeydown',
or:
MochiKit.Signal.connect('directory', 'onkeydown',
Signal does the $('directory') for you. You don't need to return
false from the function. To stop the default behavior, use
e.preventDefault() instead. If you're just learning MochiKit, it
might make sense to try something a bit simpler. Try playing with the
Signal key examples:
http://mochikit.com/examples/key_events/index.html
Beau
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Captuing Key Events
Use e.preventDefault(), like I described in an earlier reply: http://groups.google.com/group/mochikit/msg/2d3ac0bdc2cce009 Docs: http://mochikit.com/doc/html/MochiKit/Signal.html#fn-preventdefault Beau On 15-Apr-07, at 8:27 PM, briandichiara wrote: Ok, this is now working (sort of), and I think I kinda get it. How do I tell this connect to return true of false for the onkeydown event? I want to disable some keys in a field. Is this possible? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: MochiKit.Signal and YUI
The Signal, native, and YUI APIs should be independent, though I've never made time to testing this. Problems might bubble around onunload because of MK and YUI's efforts to plug IE memory leaks. Let us know what problems you run into. Thanks! Beau On 12-Mar-07, at 8:16 AM, mills wrote: I have been using MochiKit for short time now, but I'm considering using YUI for some of its widgets. Searching this group suggest this should not be a problem. However, in the documentation for MochiKit.Signal it states: When using MochiKit.Signal, do not use the browser's native event API. - Why is this constraint there? - Given this constraint, is it safe to use both YUI's event handling system and MochiKit's? Any other comments about successfully using Mochikit and YUI together are appreciated. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: What is the mochikit way ?
On 18-Feb-07, at 9:08 PM, Pearl wrote:
I am calling a python function in regular intervals repeatedly. For
this purpose I am using the javascript function
= setInterval(function, interval)
To stop this I used
= clearInterval(function)
What is the mochikit way of doing the same?
I think this is closest to what you're describing:
var d = null;
someFunction() {
if (condition) {
d = callLater(seconds, someFunction[, args]);
}
}
d = callLater(seconds, someFunction[, args]);
Beau
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Signal Error
This should be fixed now. Please try the latest version in trunk.
On 14-Feb-07, at 4:34 AM, Pearl wrote:
Why is observers not defined runtime error coming? The following is
the error. How this can be avoided ?
A runtime error has occurred.
Line: 4206
Error: 'length' is null or not an object
MochiKit.Base.update(MochiKit.Signal,{__repr__:function(){
return [+this.NAME+ +this.VERSION+];
},toString:function(){
return this.__repr__();
},_unloadCache:function(){
var self=MochiKit.Signal;
var _548=self._observers;
for(var i=0;i_548.length;i++){= error is in this line
self._disconnect(_548[i]);
}
delete self._observers;
try{
window.onload=undefined;
}
catch(e){
Thanks and Regards
Pearl
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Combining Dimensions and Coordinates?
On 3-Feb-07, at 7:20 AM, Arnar Birgisson wrote: Yes, I was thinking of something along those lines yesterday. I called it Box. I'm attaching a concept patch - that just adds the Box class and a few utility functions. Am I on the right track here? We could then add convenience stuff for aligning and/or centering boxes within other boxes, getting the viewport box etc. I like Bob's suggestion to make Box a container for Point and Coordinates objects. And Rect might be a better name, Box should probably be tied to the DOM. Thanks, Beau --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Combining Dimensions and Coordinates?
On 4-Feb-07, at 1:38 PM, Arnar Birgisson wrote: Ok, I'm fine with Rect. I did put in getDimensions and getCoordinates f - do you think that the Rect should have those two as attributes directly instead of t, l, h and w? Yes. The centering and other prototypes are what makes this useful. Beau --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Combining Dimensions and Coordinates?
On 26-Jan-07, at 5:04 PM, Arnar Birgisson wrote: Why two different classes? Why not just use a point to represent size? That way, point could have useful prototype methods for some calculations. I don't know any definitions of the word point that imply a dimension. Box might be the right word, but do you have any other ideas? Anyway, if you create a ticket and submit a patch, this will make it into MochiKit. Thank you, Beau --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: Combining Dimensions and Coordinates?
On 26-Jan-07, at 12:24 AM, Arnar Birgisson wrote:
Ok, sounds good. Is there any way in js to enforce things like
b-t=h and r-l=w
I.e. if the user changes any of these attributes, the others would
need to be updated to.
I was actually thinking more in the line of a generic two-dimensional
vector prototype with attrs {x, y}.
I think the Box idea is good though, but maybe Box should be {t,r,b,l}
and have methods like getWidth, getHeight and getSize (which would
return an instance of the vector thing)?
We can do the b-t = h calculations in the getSize method. So a
{t,r,b,l} Box with a couple useful prototypes.
Do Coordinates and Dimensions and Box belong in Base? Or is Style OK?
And why don't we update the names, so Coordinates = Point, and
Dimensions = Size?
Thanks,
Beau
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Combining Dimensions and Coordinates?
I'm open to this. We could call it Box. Check here for some
thoughts on this:
http://trac.mochikit.com/ticket/84
So a Box will define {t, r, b, l, w, h}. Thoughts?
Beau
On 25-Jan-07, at 5:18 PM, Arnar Birgisson wrote:
Hi all,
I don't know if this has been discussed before, but here goes anyways.
I was looking to implement some vector operations on the Coordinates
prototype, such as add/subtract, multiply by factor. If these were to
be used more in, say, code that generates SVG graphics and canvas
stuff - I would think adding rotate and a generat matrix
transformation would be appropriate.
The thing is that much of this would apply to Dimension objects as
well. Take the example of centering something. The object's and
container's size would be dimensions, but we need a Coordinates object
calculated like this: (containerSize - objSize)/2
Shouldn't these two really be just a single prototype? Currently
theire just holders for x,y and w,h properties - but adding some
methods would certainly in most cases apply to both classes. However,
since js doesn't have a __getattr__ I can't see a way to do this while
being backwards compatible.
Or maybe I'm the only one who sees a need to add any operations on
those classes?
Arnar
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Safari 1.3 - 2.0.3 link events
Doing a return false; shouldn't hurt anything. Not everyone wants
to stop onclick events on a tags, so it doesn't make sense to add
that to Signal. I've added a note about this bug to the docs:
http://trac.mochikit.com/changeset/1230
Thanks,
Beau
On 5-Dec-06, at 5:37 AM, Juergen Schreck wrote:
Ok, I've done some more testing with the simplified script:
a id=one href=#oneone/a
a id=two href=#twotwo/a
script type=text/javascript charset=utf-8
$('one').onclick=function(){ return false; };
connect('one', 'onclick', function(e) {
e.stop();
alert('one');
});
connect('two', 'onclick', function(e) {
e.stop();
alert('two');
});
/script
Basically, rather than adding the onlick attribute in the markup, I
added it in code. And it works properly with Safari 1.3+ and still
works with others. The question now becomes if this is some MochiKit
could/should handle transparently? There's a lot of pre-2.0.4
Safari's out there...
I guess it would be an exception in connect for Safari if the source-
element is an a and the event is 'onclick'.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Safari 1.3 - 2.0.3 link events
On 4-Dec-06, at 9:55 PM, Juergen Schreck wrote:
Found some more info here.
http://www.codingforums.com/archive/index.php?t-30983.html
Given the date of those posts, and the fact that one of my clients
was running 2.0.3 (the latest official version being 2.0.4) it
probably was only recently fixed.
I don't know if this is some MochiKit can/should work around.
Here's a reduced test you can try:
a id=one href=#one onclick=return false;one/a
a id=two href=#twotwo/a
script type=text/javascript charset=utf-8
connect('one', 'onclick', function(e) {
e.stop();
alert('one');
});
connect('two', 'onclick', function(e) {
e.stop();
alert('two');
});
/script
You don't need to return false from the event handlers you call with
connect, that doesn't do anything. Adding onclick=return false; to
the a tags shouldn't cause any problems.
Beau
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
MochiKit group.
To post to this group, send email to mochikit@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/mochikit?hl=en
-~--~~~~--~~--~--~---
[mochikit] Re: Mochikit.connect memory leak
On 29-Nov-06, at 8:50 PM, DJK wrote: According to this thread: href=http://groups.google.com/group/mochikit/browse_thread/thread/ 7b9e83aaaba4ec2/80ad93582b0a22b0?lnk=gstq=memory +leakrnum=3#80ad93582b0a22b0 The memory leak in the connect function was fixed in the trunk. Was 1.3.1 supposed to include this fix. I just wrote a simple connect test and the memory leak still occurs? Should connect work in 1.3.1? Is there a patch available? This is news to me. Can you post a trac ticket with a full example so we can reproduce the problem? Thanks, Beau --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit?hl=en -~--~~~~--~~--~--~---
[mochikit] Re: EventMap for Signal?
On 11-Oct-06, at 3:20 AM, Pablo Montilla wrote: Well, its not beautiful but it works. It would be better if the selection of elements to be connected were done using a function as parameter (so its decoupled, and extensible): I like the interface. Could you please submit a ticket, and attach your code so far? Thanks! Beau --~--~-~--~~~---~--~~ 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: Safari key signals
On 18-Sep-06, at 8:39 AM, koorb wrote: It seems that Safari is signalling some onkeydown/up events twice. As far as I can tell it's arrow keys, function keys and home/end, numlock, delete but not keypad numbers. I hope this is a bug that can be resolved quickly too. I have tried to connect to currentWindow(), currentDocument(), document and window and they are all behaving the same. I don't think it's my code as it only happens with certain keys as I said and only in Safari. Can you please post a minimal example that demonstrates the problem? Thanks, Beau --~--~-~--~~~---~--~~ 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: Safari and preventDefault on a tag with href
On 17-Sep-06, at 7:52 AM, Godefroid Chapelle wrote: I want to setup a click event on an a tag where href has a value. With Safari, when the click event is added as a listener, even if preventDefault is called, the link is followed : this is a documented bug. Now there is a workaround for this bug. I'd like to submit the patch we have. Before proposing the patch, I'd like to know what the practice is in Mochikit code to setup this type of workaround that needs to detect which browser is running the code. We try to avoid browser detection if at all possible, but it's been easing its way in lately. We don't have a standard set for this yet. What's the workaround for this problem? Thanks, Beau --~--~-~--~~~---~--~~ 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: Edit in Place with Mochikit
On 6-Sep-06, at 6:23 AM, andrei wrote: Is there a possibility to achieve the same edit in place functionality as in http://tool-man.org/examples/edit-in-place.html with Mochikit? Yes, though we don't have any examples that demonstrate something like this. Beau --~--~-~--~~~---~--~~ 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: add JSONP to Async
Hey, thanks for sending this in! Could you please attach your code to
the ticket for this feature request:
http://trac.mochikit.com/ticket/143
Even more helpful would be a SVN diff against the trunk. Bob and
Thomas know Async much better than I do, and I think it's best to
keep everyone's comments together in the ticket.
Thanks,
Beau
On 5-Sep-06, at 10:50 PM, [EMAIL PROTECTED] wrote:
I wrote code for JSONP to Async.
http://rails2u.com/misc/MochiKitAsyncJSONP/AsyncJSONP.js
http://rails2u.com/misc/MochiKitAsyncJSONP/ (DEMO)
DEMO is able to get JSON from del.icio.us by JSONP.
DEMO's Implementation example code is like this.
//
var d = sendJSONPRequest('http://del.icio.us/feeds/json/' +
$('uid').value, 'callback');
d.addCallback(function(json) {
replaceChildNodes($('result'), UL(null, map(function(data) {
return UL(null, A({href: data.u}, data.d));
}, json)));
});
// --
sendJSONPrequest is MochiKit.Async's function.
- sendJSONPRequest(url, callback_query, timeout/* = 30 */, _options/*
optional */)
sendJSONPRequest's first arguments is JSON url.
example: http://del.icio.us/feeds/json/gorou
second arguments is query callback params name.
If del.icio.us's API callback name is 'callback'.
third arguments is request timeout second.
If over timeout second. call errback. But don't work opera...
Opera's element.appendChild(script) don't ASYNC.
forth arguments is script element attributes.
example:
sendJSONPRequest(url, callback_query, timeout, {
charset: 'utf-8'
});
If you like AsynJSON.js, please Fetch in AsyncJSON.js's code to
MochiKit.
--~--~-~--~~~---~--~~
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: API extension for setElementPosition and setElementDimensions
On 5-Sep-06, at 4:31 AM, Marc Boeren wrote:
If I just want to change the x-position or the height of an element, I
can't use the setElementPosition/Dimensions function. How about an API
extension where you can pass null for an argument and that argument
will not be updated? (another option would be to add setElementHeight
and setElementWidth).
Simple usage example in an onresize handler:
setElementDimensions(fixedwidthelement,
{w:null, h: getViewportDimensions().h});
Implementation (based on current setElementPosition):
setElementPosition = function (elem, newPos/* optional */, units) {
elem = MochiKit.DOM.getElement(elem);
if (typeof(units) == 'undefined') {
units = 'px';
}
var style = {};
if (newPos.x!==null) style.left = newPos.x + units;
if (newPos.y!==null) style.top = newPos.y + units;
MochiKit.DOM.updateNodeAttributes(elem, {'style': style});
};
Same for setElementDimension.
I can supply a patch if anyone is interested.
What about sending objects with just one or the other dimension, like
this:
setElementDimensions(elem, {h: 123});
instead of:
setElementDimensions(elem, {w: null, h: 123});
Beau
--~--~-~--~~~---~--~~
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: API extension for setElementPosition and setElementDimensions
On 6-Sep-06, at 1:55 AM, Arnar Birgisson wrote:
I'd also like to see relative versions of those functions, would help
with custom dragging and resizing. I.e. adjustElementPosition(el, {x:
0, y: -10}) would move the element 10pxls up.
Not to be pushy, but I'd also like to see add and subtract member
functions on the dimension and coordinates objects.
Now, this:
var delta = new MochiKit.DOM.Coordinates(e.mouse().page.x - lastpos.x,
e.mouse().page.y -
lastpos.y);
lastpos = e.mouse().page;
currelpos = elementPosition(pi.firstChild);
var newpos = new MochiKit.DOM.Coordinates(currelpos.x + delta.x,
currelpos.y + delta.y);
setElementPosition(pi.firstChild, newpos);
would be reduced to this:
var delta = e.mouse().page.subtract(lastpos);
lastpos = e.mouse().page;
adjustElementPosition(pi.firstChild, delta);
I'd be happy to provide patches for this if anyone else has use for
it.
Sounds reasonable, if you have a patch please do it against trunk and
attach it to a trac ticket:
http://trac.mochikit.com/newticket
Thanks!
Beau
--~--~-~--~~~---~--~~
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: Instant Modifiers?
On 6-Sep-06, at 1:43 PM, Juergen Schreck wrote: Is there a [crossbrowser (FF,IE,Safari) ] way to capture modifiers instantly, rather than via onkeypress? In my application I'd like to capture when alt was pressed during a mousedrag. This works of course as soon as the mouse is moved 'after' the key was pressed. But assume the mouse was not moving and the alt key was pressed. Is there a way to capture that? Could you set up a separate onkeydown handler that looks for the alt key? Beau --~--~-~--~~~---~--~~ 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: Instant Modifiers?
On 6-Sep-06, at 4:28 PM, Juergen Schreck wrote: I could, if it made a difference. 'onkeydown' doesn't fire if only a modfier key is pressed. This is exactly my problem. I understand how what you're looking for would be useful, but I don't know how to coerce a browser to do this, and MochiKit does not try to solve this problem. Please let us know what you find! Thanks, Beau --~--~-~--~~~---~--~~ 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 ???
On 30-Aug-06, at 6:10 AM, Zachery Bir wrote:
Maybe, *shrug*, every Javascript reference I've seen points out that
css style attributes need to be camel cased. Just because they're in
quotes here doesn't strike me as obviating that. It's still in
Javascript source. :^)
computedStyle('background-color', 'red') is valid in MochiKit 1.4.
computedStyle('backgroundColor', 'red') works too, but I like the
first form. It makes sense for us to note the discrepancy or adjust
other MochiKit functions to accept either. backgroundColor is an
artifact of the native DOM API, not JavaScript.
Beau
--~--~-~--~~~---~--~~
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: disconnecting all signals to an object
On 29-Aug-06, at 4:25 PM, Jaime Cham wrote:
It seems that it's a useful usage to disconnect all signals going
TO an
object. For example, when the an object that connects itself to
several
signals or events is destroyed, in order to ensure correct recovery of
the memory it would want to disconnect itself.
I use the following extra code for MochiKit.Async:
MochiKit.Base.update(MochiKit.Async, {
disconnectAllTo: function (objOrFunc, funcOrStr /* optional */) {
if (typeof(objOrFunc) != 'object') {
throw new Error(need to specify a receving object);
}
var self = MochiKit.Signal;
var observers = self._observers;
var i = 0;
while (i observers.length) {
var ident = observers[i];
if (ident[4] == objOrFunc
(typeof(funcOrStr) == 'undefined'
|| ident[5] == funcOrStr)
) {
self._disconnect(ident);
observers.splice(i, 1);
}
else
i++;
}
},
});
disconnectAllTo = MochiKit.Async.disconnectAllTo;
Is there already a different way of doing this? or am I violating some
signal/slot design principle?
I can see how this would be useful. It probably belongs to Signal,
not Async. Could you please submit a ticket asking to include this,
and attach your code as a .js file?
Thanks!
Beau
--~--~-~--~~~---~--~~
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: .Cookie or .Storage?
On 28-Aug-06, at 11:49 AM, Bob Ippolito wrote:
Sounds like a good idea. Generalized storage would be fine by me, but
only if the representation is JSON. It would be nice if the cookie
storage could tell you (by exception or true/false return value) if
said data didn't fit in a cookie for whatever reason.
How does this API look:
MochiKit.Storage.retrieve(key)
MochiKit.Storage.store(
key, value
or {key: value, key1: value1, ...}
or [[key, value], [key1, value1]]
) - throws when full or unavailable
MochiKit.Storage.destroy(key) - delete()s the key.
MochiKit.Storage.expires(date) - defaults to discard when browser
session is over. Makes sense for Cookies, but what about FormStorage
or some other technique?
MochiKit.Storage.setProvider(string) - defaults to Cookie.
MochiKit.Storage.storageUsed()
MochiKit.Storage.storageFree()
Beau
--~--~-~--~~~---~--~~
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 ???
On 29-Aug-06, at 2:07 PM, Zachery Bir wrote:
I just figured it out. One must use the camel case notation for the
CSS
attribute lists. It would perhaps help to mention that in the
doco. :p
You're in Javascript, not CSS. Put it in a .css file, or use
Javascript notation for style declarations.
I don't think it's necessarily clear that you should use camelCase
there. mirage, what should the docs say? Could you open a ticket with
your suggested clarification? Just an example using {'style':
{'backgroundColor': 'red'}} might be enough.
Thanks!
Beau
--~--~-~--~~~---~--~~
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: Queue, AsyncQueue, and Stack
On 29-Aug-06, at 3:42 PM, paul wrote:
Sure- ticket #170.
Browsers are all over the place, I don't know if it's worth re-
implementing this. The numbers don't seem to be as good on Mac and
Windows (ran several times each, took the median time):
Safari:
q = new Queue(); t1 = new Date(); for (i = 0; i 1; i++)
{ q.put(i); q.get(); }; t2 = new Date(); t2 - t1
1027
a = new Array(); t1 = new Date(); for (i = 0; i 1; i++)
{ a.push(i); a.shift(); }; t2 = new Date(); t2 - t1
30
FF Mac:
q = new Queue(); t1 = new Date(); for (i = 0; i 1; i++)
{ q.put(i); q.get(); }; t2 = new Date(); t2 - t1
226
a = new Array(); t1 = new Date(); for (i = 0; i 1; i++)
{ a.push(i); a.shift(); }; t2 = new Date(); t2 - t1
172
IE 6:
q = new Queue(); t1 = new Date(); for (i = 0; i 1; i++)
{ q.put(i); q.get(); }; t2 = new Date(); t2 - t1
90
a = new Array(); t1 = new Date(); for (i = 0; i 1; i++)
{ a.push(i); a.shift(); }; t2 = new Date(); t2 - t1
50
FF Win:
q = new Queue(); t1 = new Date(); for (i = 0; i 1; i++)
{ q.put(i); q.get(); }; t2 = new Date(); t2 - t1
170
a = new Array(); t1 = new Date(); for (i = 0; i 1; i++)
{ a.push(i); a.shift(); }; t2 = new Date(); t2 - t1
151
Beau
--~--~-~--~~~---~--~~
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] .Cookie or .Storage?
I'd like to add a nice Cookie interface to MochiKit. Working with them manually sucks, but they're important for Ajax applications. Should we make it a submodule of some kind of Storage component that may or may not grow other persistence options? Thanks, Beau --~--~-~--~~~---~--~~ 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: playing with canvas and mochikit
On 15-Aug-06, at 2:15 AM, Lawrence Oluyede wrote: What do you mean by... then it works! ? You get the actual drawing at the exact point you start the onmousedown event and to the exact point you stop with onmouseup event? Which Firefox version are you using? I tried with Firefox 1.5 on Ubuntu and MacOSX, with Opera9 on Ubuntu and with Camino on MacOSX. Only Safari seems to handle it correctly. I think the problem isn't the JavaScript code, it's the HTML that includes the JavaScript. Instead of: script type=text/javascript src=MochiKit.js / Try: script type=text/javascript src=MochiKit.js/script Beau --~--~-~--~~~---~--~~ 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 connecting to multiple elements
On 2-Aug-06, at 1:38 PM, Eoghan Murray wrote: Yes, you are right, this is the most elegant and efficient way of doing it. There's some cases where it can't be used though, such as focus and blur events which don't bubble. I suppose this doesn't constitute a big enough use case to implement it. I wonder if the general pattern would be a good one for MochiKit though (of mapping/expanding lists when single elements are expected). I suspect the answer is a swift 'no'! I think most functions do something smart with lists, and connect/ disconnect would probably benefit from this. If you think they should support this, please submit a feature request in trac: http://trac.mochikit.com/newticket Anyone else need this functionality? Thanks, Beau --~--~-~--~~~---~--~~ 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 and Notification Center API
On 24-Jul-06, at 3:09 PM, Giulio Cesare Solaroli wrote:
I have start using the MochiKit.Signal module and I have really
liked it.
With Signal it is very easy to decouple the caller code from the
called code.
But I really miss an option available under (MacOSX's) Foundation
NSNotificationCenter: the ability to listen ('connect' in the
MochiKit.Signal lessic) to a given event, whatever object may notify
(aka 'signal') it.
This will allow an even greater flexibility in how you can arrange the
code, as it will be possible to bind a listener to a notifier even
before having created the later.
Is there any obvious reason this extended semantic has not been
implemented that I am missing? If no special complains are raised, I
would like to try to extend the Signal module in order to accept a
null src parameter in the connect method.
I think this is a good idea. Please give it a shot, and attach your
code to a new trac ticket. We'll review it and get it in there if it
looks good.
Thanks!
Beau
--~--~-~--~~~---~--~~
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: Is anyone working on autocomplete for MochiKit?
On 1-Aug-06, at 7:07 AM, Thomas Hervé wrote: As you seem to have spotted, Controls.js is not supported at all. It's here by accident, and there're very few chances that it'll be in the next MochiKit release, or even in a release one day. Bob would be a better judge, but I don't think autocomplete/ajax editor is a feature suited for MochiKit. For now, there are no docs, no examples, and no maintainer for this file. There's a lot of work needed for removing Prototype stuff and using MochiKit instead. Every volunteer are welcome, though :). I agree with Thomas, I don't think widgets of any sort belong in MochiKit itself. Beau --~--~-~--~~~---~--~~ 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: packing mochikit
On 1-Aug-06, at 5:41 PM, Tim Stebbing wrote: Just after some thoughts about more compact mochikit.js building. I had a vague idea that if we could write a script that would generate a dependency graph for all functions in mochikit, then you could specify the functions your application uses, and generate a packed mochikit.js with only the modules and functions + dependencies your application requires.. about as small as you could possibly get. thoughts? Dojo is working on something like this. They've got a JavaScript linker in the works via Google's Summer of Code: http://blog.dojotoolkit.org/2006/07/22/summer-of-code If you'd like to help out, try getting in touch with Satish. I'm looking forward to the results of this work. Beau --~--~-~--~~~---~--~~ 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: Is anyone working on autocomplete for MochiKit?
On 31-Jul-06, at 8:27 AM, GHUM wrote: (event handling onkeypress is not working with MochiKit.Signal, wrong attribute-Access to event-object) Signal should work. What's wrong with it? Can you post a complete example? Thanks, Beau --~--~-~--~~~---~--~~ 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: Is anyone working on autocomplete for MochiKit?
On 31-Jul-06, at 10:04 AM, Harald Armin Massa wrote:
Signal works beautifully. The problem sits within the Controls.js:
{{{...}}}
There is no event.keyString within MochiKit.Signal, that should
be event.key().string; and there is also no KEY_RETURN, that is
called KEY_ENTER .
So I started debugging Controls.js from the SVN Head, which is
there by Error as I found from this group. :)
I'm not too familiar with that code, but keyString is definitely
wrong. I've committed a fix:
http://trac.mochikit.com/changeset/1062
If you find any other problems like this, please submit a bug or let
us know on the list.
Thanks!
Beau
--~--~-~--~~~---~--~~
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: Is there any problem with having many connects on a page?
On 31-Jul-06, at 10:53 AM, Jorge Godoy wrote: Could you take a look at it? Is my code wrong? Should I adopt a different approach to the problem? :-) I'm really willing to go on with this part of the code (even though I'm working on different parts simultaneously, this is pending on my side...). Hi Jorge, If you used native browser events to connect to a lot of elements, your page would probably slow to a crawl as well. I don't think your code or Signal are introducing any other problems on top of this one. A solution to your problem might be to connect() at a higher level for an event, say on document or window. From there, you can see where it came from (http://mochikit.com/doc/html/MochiKit/ Signal.html#fn-target). Something like this *should* work in your situation, but you'll need to write and test the code to be sure. Beau --~--~-~--~~~---~--~~ 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: Is anyone working on autocomplete for MochiKit?
On 31-Jul-06, at 1:04 PM, Harald Armin Massa wrote: thank you very much! The other bug in those lines ist: KEY_RETURN should be KEY_ENTER, because Return and Enter both create KEY_ENTER events. Hmm, I'd need to take a closer look at that one. Some browsers do make the distinction. When I get some more time, I'll take a close look at all of that code. Thanks, Beau --~--~-~--~~~---~--~~ 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: Favorite JavaScript books?
On 29-Jul-06, at 12:35 PM, Kevin Dangoor wrote: I've just finished my first draft chapter about MochiKit for the TurboGears book. The book seeks to give a Python programmer enough grounding to use JavaScript and MochiKit effectively but leaves out *lots* of detail about JavaScript that people might be interested in. I like to suggest a JavaScript book or two for people who want more detail. Are there any favorite books that you've read? I read most of the 4th edition of the rhino book to learn JS. It was very good. The updated 5th edition will be released next month: http://www.oreilly.com/catalog/jscript5/ Beau --~--~-~--~~~---~--~~ 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: Trapping Safari's ENTER key
On 26-Jul-06, at 11:04 PM, chris feldmann wrote: Pigmeu, I thank you for your report. Beau, do you concur? I'd like to check Safari's bugzilla to see if this has been reported there. If it is, I'd like to refer to it from MochiKit's docs. If it's not, I'll need to make a reduced test case and then refer to it from MochiKit's docs. Has anyone found this in bugzilla? Beau --~--~-~--~~~---~--~~ 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: Trapping Safari's ENTER key
On 25-Jul-06, at 10:35 AM, chris feldmann wrote:
I am trying to disable form submission on enter keydown. This snippet
works on every platform except safai, which even does the visual
submit press animation cue and then submits. Is there some secret
sauce for safari's enter key?
connect( window, onload, function(){
connect( document, onkeydown, function( e ){
e.stop();
var key = e.key();
for( p in key ){
logDebug( p + : + key[p] );
}
if( key.code == 13 || key.code == 3 ){
return false;
}
} );
Hi Chris,
Try looking for key.string == 'KEY_ENTER'. If that doesn't work,
please post a full example for me to play with.
Thanks,
Beau
--~--~-~--~~~---~--~~
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: Is there any problem with having many connects on a page?
On 25-Jul-06, at 5:30 PM, Jorge Godoy wrote: Here it is. You'll just have to fix the path to the packed version of MochiKit. This is just multiplying each numeric value by 3. I've just made a few simplifications from my real case (where my for loop iterates of a JSON result containing data that will be turned into table rows instead of generating a loop with known indexes), but kept the structure of everything else. I don't think you can attach anything to list posts. Could you please submit a trac ticket with an attachment? Thanks! Beau --~--~-~--~~~---~--~~ 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: Event propagation question
On 19-Jul-06, at 7:26 AM, Chris Nokleberg wrote: In this particular case there is grandparent-parent-child. The child and the grandparent both need to handle the event, but because the child is handling it the parent should ignore it. There's no way to make the event skip over the parent so the current hack is to just set a property and have code in the parent to ignore it. The grandparent is in a completely separate library/module so a custom event wouldn't work (unless I constructed an event object that looked just like a normal mousedown). Chris, How would you handle this with native browser events? Beau --~--~-~--~~~---~--~~ 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: Is there any problem with having many connects on a page?
On 19-Jul-06, at 7:02 AM, Jorge Godoy wrote: I'm generating some tables for data input and I'd like to perform one calculation automatically, so I'd connect all inputs from one column to an onchange event (using MochiKit.Signal, of course). If I have something like 1000 rows on this table, would having 1000 connects be too much? Is there a better way to make this automatic? (I'd like to avoid having to press a button to perform the calculation, but if there's no way this is what I'll implement...) This will be running mainly on Firefox (Linux and Windows) and Internet Explorer (Windows). Machines are reasonably fine and running Windows XP (there's one with an updated version of IE running Windows 98, but only because of other software, I believe it would run XP just fine.). You should probably be fine. That said, test it with say 5,000 rows and see what happens, especially in IE. Firefox is not immune though, you should test it thoroughly too. If this breaks somehow, please open a new Trac ticket and attach your test case. --~--~-~--~~~---~--~~ 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: Back, Forward best practice
On 5-Jul-06, at 2:37 AM, elio wrote: I would like start to add the management of back, forward keys after looking few ways, (may be in the next week/s). Is there any intenction to make a Mochikit module or to follow a common way for all people that made Mochikit choice? Signal will help with arrow keys (see http://mochikit.com/examples/ key_events/index.html), but MochiKit doesn't have any modules that interact with browser history. --~--~-~--~~~---~--~~ 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: Input Mask
On 5-Jul-06, at 3:48 AM, Jorge Godoy wrote: Is there some easy way to implement an input mask with MochiKit or is there some other library around that plays nice with MochiKit and adds this functionality? Restricting what chars may be input would be nice, but I'm more concerned with formatting the input field. No, there's no input mask abstraction in MochiKit. You could easily write one with Signal's key support: http://mochikit.com/examples/key_events/index.html http://mochikit.com/doc/html/MochiKit/Signal.html#fn-key --~--~-~--~~~---~--~~ 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 design of site is cool
On 21-Jun-06, at 7:03 AM, troels knak-nielsen wrote: [loading index…] stays. As does [...] I admit it - I'm using IE, but still don't think I deserved that. I think this might be an older bug. Do you remember IE working before? (I reverted on a local copy, and IE was still broken.) --~--~-~--~~~---~--~~ 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 design of site is cool
On 21-Jun-06, at 7:49 AM, chris feldmann wrote: [loading index…] stays. As does [...] I admit it - I'm using IE, but still don't think I deserved that. Verified, win2k, ie 6.0. Alright, here's the ticket: http://trac.mochikit.com/ticket/135 --~--~-~--~~~---~--~~ 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: window.onunload
On 21-Jun-06, at 12:45 AM, Mc wrote: confirmUnload is better indeed. I assume you added the elseif in preventDefault for people that first call confirmUnload and then e.stop or e.preventDefault in the onbeforeunload handler? And can I ask you to have a look at another onunload issue please? http://trac.mochikit.com/ticket/113 elseif: Yes, exactly. IE would have replaced the message with false otherwise. #113: That's on my radar, but it's important to get right, and will require a lot of testing. It'll be fixed before 1.4 is released. --~--~-~--~~~---~--~~ 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: median() and mean()
On 21-Jun-06, at 5:30 PM, Bob Ippolito wrote:
I needed median and mean functions for something I'm working on.
Should they go into MochiKit somewhere? Are they correct? Fast
enough?
/* http://www.nist.gov/dads/HTML/mean.html */
var mean = function() {
var data = flattenArguments(arguments);
return sum(data) / data.length;
};
/* http://www.nist.gov/dads/HTML/median.html */
var median = function() {
var data = flattenArguments(arguments);
data.sort(compare);
if (data.length % 2 == 0) {
var upper = data.length / 2;
return (data[upper] + data[upper - 1]) / 2;
} else {
return data[(data.length - 1) / 2];
}
};
These look correct and fast enough. I might've written mean such
that it inlined more or less what flattenArguments does and
calculated the sum and length at the same time without building an
intermediate Array at all. median could be similarly special cased
but that would be a pain in the ass to do faster and it isn't
really very commonly used anyway. Note that using sum() currently
introduces a dependency on MochiKit.Iter, but I'd be open to moving
it to MochiKit.Base and specialize based upon the input type and
iter availability like map() does.
The empty list cases should be handled somehow.. mean obviously
returns NaN because it's doing divide by zero, but median much less
obviously returns NaN: (undefined + undefined)/2. I'm not sure if
people would expect 0.0 or an error to be thrown, I doubt NaN is
desired though.
Renaming mean to average or avg might make sense. I think more
people are familiar with the term average.
I'll work on mean. Moving sum seems like way more work than just
writing a loop. Instead of renaming mean, what about aliasing it (and
note that in the docs)? Here's what JavaScript does with similar
functions that expect arguments:
Math.min()
Infinity
Math.max()
-Infinity
Math.ceil()
NaN
Math.cos()
NaN
And MochiKit:
listMin()
TypeError: Undefined value [...]
listMax()
TypeError: Undefined value [...]
listMin([])
null
listMax([])
null
I think listMin and listMax follow Math.min and .max. mean and median
should probably return NaN.
--~--~-~--~~~---~--~~
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: why the interpreter demo can't use help()
On 20-Jun-06, at 2:33 AM, Wei Litao wrote: I use firefox. I tested dev version and local version and the link from your mail. The result is the same: help(map) blocking on Deferred(2, unfired)... Then no document whould be shown no metter how long I am waitting for. BTW, I have tested in IE, in my IE the result is help(map) documentation for MochiKit.Base.map not found Alright, I can reproduce this in Firefox Mac/Win, Opera Mac/Win, IE, but it works in Safari. Thanks for reporting this. Trac: http://trac.mochikit.com/ticket/134 --~--~-~--~~~---~--~~ 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: download version 1.3 not 1.3.1?
On 19-Jun-06, at 10:56 AM, petersabaini wrote: http://mochikit.com/download.html still references 1.3 as the current stable version -- is that in fact version 1.3.1? or is 1.3.1 still considered unstable? please forgive me if this is a FAQ... Thanks for reporting this. Bob's updated the download page. --~--~-~--~~~---~--~~ 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: window.onunload
How about e.returnValue(Are you sure?); instead? That would probably be easier to implement than the property, but if the implementation of the property is doable, I'ld rather have that, as that is the way it works on native events for both IE and Firefox. Right, but for other reasons we'd already converted everything to a method access on the normalized MochiKit API. This returnValue would be the only departure from this. --~--~-~--~~~---~--~~ 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: Dragging DIV and positioning
On 14-Jun-06, at 3:18 PM, david wrote:
I'm working with the Drag Drop example on the website, using the
draggable.js script. I've got a function on my page that creates new
DIV elements and then connects them to the Draggable functions so that
the user can move them around the page.
Everything works great to this point.
The problem is that when I create the new DIV elements (using
createDOM
or standard Javascript functions), they are created and placed on a
(seemingly) random position on the page.
I want all new elements to start at position 0,0. Unfortunately,
when I
create the element and place it at 0,0, the dragging no longer
works. I
have tried explicitly setting the style.top/left properties on the new
element as well as the setElementPosition() function. Both of these
methods break the drag-ability of the new element.
I'm guessing it is because the following is set on the element:
style=top:0; left:0 which overrides the function in draggable.js
which sets the location of the element. So I tried clearing the
style.top and style.left properties of the element (after moving it to
0,0), but this moved the new element back to its initial starting
point.
Here's an code snippet:
//Get reference to form
var f = $(form1);
//Create new DIV to hold text
var textElement = createDOM(DIV);
textElement.id=element_ + m_ElementCount;
textElement.className=draggable red text;
//Add text element to form
f.appendChild(textElement);
//Move element to 0,0
setElementPosition(textElement,{x:0, y:0});
//Make text element draggable
connect(textElement, 'onmousedown', Drag.start);
David, could you please post a complete example (with HTML)?
--~--~-~--~~~---~--~~
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: window.onunload
On 14-Jun-06, at 11:10 AM, Mc wrote: From http://msdn.microsoft.com/workshop/author/dhtml/reference/events/ onbeforeunload.asp Remarks When a string is assigned to the returnValue property of window.event, a dialog box appears that gives users the option to stay on the current page and retain the string that was assigned to it. The default statement that appears in the dialog box, Are you sure you want to navigate away from this page? ... Press OK to continue, or Cancel to stay on the current page., cannot be removed or altered. The string you provide is shown first, followed by the specified statements. I've tested it on Firefox as well and I think it gives a slightly different text but works as advertised :-) Ciao, Mc. Do you think it belongs on the Signal.Event object? Could you whip up an implementation? Mozilla notes: https://bugzilla.mozilla.org/show_bug.cgi?id=68215 https://bugzilla.mozilla.org/show_bug.cgi?id=245809 Thanks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit -~--~~~~--~~--~--~---
[mochikit] Re: Rounded Corners Demo fails
On 13-Jun-06, at 1:07 PM, Clifford Snow wrote: I just learned of MochiKit by looking through the available software for Fedora Core 5. It looks very useful. However, the rounded corners demo fails in Firefox 1.5.03. The following error message is generated: Error: uncaught exception: [Exception... Could not convert JavaScript argument arg 0 [nsIDOMViewCSS.getComputedStyle] nsresult: 0x80570009 (NS_ERROR_XPC_BAD_CONVERT_JS) location: JS frame :: http://mochikit.com/MochiKit/Style.js :: anonymous :: line 140 data: no] Clifford Snow Thanks for reporting this. I've fixed it in trunk and on mochikit.com: http://mochikit.com/examples/rounded_corners/index.html --~--~-~--~~~---~--~~ 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: A Designer Lost In Programming
On 10-Jun-06, at 2:37 PM, Jon wrote: Ok, I removed that. And I've uploaded everything. The html file is here: http://utvikling.atspredelse.com/no-subs/index.html (sorry for all the Norwegian stuff) and the javascript file is here: http://utvikling.atspredelse.com/no-subs/siste-utgivelse.js (It takes some time to load now, I don't know why, so if anyone could tell me, I would be really happy) Jon. Try fixing the HTML errors, especially the /scritp typo: http://validator.w3.org/check?uri=http%3A%2F% 2Futvikling.atspredelse.com%2Fno-subs%2Findex.html --~--~-~--~~~---~--~~ 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: computedStyle
On 7-Jun-06, at 7:13 PM, Bob Ippolito wrote: Base seems like a good enough place for it. Ignoring performance, is backwards compatibility even an issue? I don't think it would break anything to camelize everywhere appropriate. I don't really know. I replaced computedStyle entirely, and added a test for it. From what I understand, this could break old code that did something like computedStyle(elem, 'backgroundColor') instead of computedStyle(elem, 'background-color'). This isn't a big deal in MochiKit code because it never queries on properties longer than one word. I'd like to get more feedback on these changes. Here's the ticket: http://trac.mochikit.com/ticket/116 --~--~-~--~~~---~--~~ 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: computedStyle
On 9-Jun-06, at 6:54 PM, Bob Ippolito wrote:
On Jun 9, 2006, at 6:15 PM, Beau Hartshorne wrote:
On 7-Jun-06, at 7:13 PM, Bob Ippolito wrote:
Base seems like a good enough place for it. Ignoring performance,
is backwards compatibility even an issue? I don't think it would
break anything to camelize everywhere appropriate.
I don't really know. I replaced computedStyle entirely, and added a
test for it. From what I understand, this could break old code that
did something like computedStyle(elem, 'backgroundColor') instead of
computedStyle(elem, 'background-color'). This isn't a big deal in
MochiKit code because it never queries on properties longer than one
word.
I'd like to get more feedback on these changes. Here's the ticket:
http://trac.mochikit.com/ticket/116
I don't see how it would change behavior, since camelize is going
to be a no-op for already camelized names...
camelize('backgroundColor')
backgroundColor
camelize('background-color')
backgroundColor
The problem was that one branch in computedStyle expects hyphen case.
We can convert the camel case to hyphen case in just that branch. The
function should work either way now:
http://trac.mochikit.com/changeset/932
--~--~-~--~~~---~--~~
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] computedStyle
Someone submitted a ticket asking for some clarification in the docs: http://trac.mochikit.com/ticket/116 Why we shouldn't just normalize (camelize, from New.js) the behavior for IE? --~--~-~--~~~---~--~~ 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: computedStyle
On 7-Jun-06, at 6:26 PM, Bob Ippolito wrote: On Jun 7, 2006, at 4:49 PM, Beau Hartshorne wrote: Someone submitted a ticket asking for some clarification in the docs: http://trac.mochikit.com/ticket/116 Why we shouldn't just normalize (camelize, from New.js) the behavior for IE? Let's go ahead and camelize in the place(s) where it would make a difference. The only reason not to is potential difference in performance, but that'd be a very premature optimization. For backwards compatibility and performance, we can camelize the two argument version, and leave the three argument version alone. Should we move camelize to Base? --~--~-~--~~~---~--~~ 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: Element position and borders
Good question. I remember looking into this, and I think we lose a *lot* of performance if we normalize the behavior when we do a style lookup. It might be best to note the problem in the documentation. Either way, please add a new trac ticket after you check this. http://trac.mochikit.com/newticket Thanks! On 2-Jun-06, at 10:11 AM, Arnar Birgisson wrote: Hi there, Seems that getElementPosition differs between browsers if the element has borders. Haven't checked this thorough (don't have time until after the weekend) - but it seems IE, Safari and Opera return the coordinates inside the border, but Firefox at the outside. I.e. coordinates for an element with 1px border will be (-1,-1) off in FF (maybe it's opposite, just took a quick look). Is this something that MochiKit should account for? Arnar --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit -~--~~~~--~~--~--~---
[mochikit] Re: Bug in getElementPosition
On 27-May-06, at 12:46 AM, Hamish Friedlander wrote:
Whoops. Not sure why the partial send. Apologies to group. Lets try
again
There appears to be a bug in getElementPosition. At the top of the
function is
if (elem.x elem.y) {
/* it's just a MochiKit.Style.Coordinates object */
It seems like ( in Firefox at any rate ) several normal DOM
elements have x and y attributes. At least one of these is
generally set to 0, so the test fails and there aren't any
problems. However on some floating elements this is not true and
the wrong result is returned.
My poor workaround is to add isUndefinedOrNull(elem.nodeType) to
the test to try and eliminate the false matches. I'm not sure what
the original intent of supporting arbitrary positioning using x and
y attributes was though - is there a better way to detect this?
Hamish,
Do you remember which DOM elements had nonzero x and y attributes?
The problem should be fixed in trunk, but I'd like to add a test case
for this.
Thanks,
Beau
--~--~-~--~~~---~--~~
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 getElementPosition
On 27-May-06, at 12:46 AM, Hamish Friedlander wrote:
Whoops. Not sure why the partial send. Apologies to group. Lets try
again
There appears to be a bug in getElementPosition. At the top of the
function is
if (elem.x elem.y) {
/* it's just a MochiKit.Style.Coordinates object */
It seems like ( in Firefox at any rate ) several normal DOM
elements have x and y attributes. At least one of these is
generally set to 0, so the test fails and there aren't any
problems. However on some floating elements this is not true and
the wrong result is returned.
My poor workaround is to add isUndefinedOrNull(elem.nodeType) to
the test to try and eliminate the false matches. I'm not sure what
the original intent of supporting arbitrary positioning using x and
y attributes was though - is there a better way to detect this?
Hamish,
Could you please do me a favor and add your report to the bug tracker:
http://trac.mochikit.com/newticket
Thanks for reporting this!
Beau
--~--~-~--~~~---~--~~
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.DOM class* functions not working in this situation.
On 26-May-06, at 4:52 PM, Samuel Webster wrote:
Hi guys, I'm having some difficulty getting the following code snippit
to work:
map(function (element) {
connect(element, 'onmouseover', function (event) {
toggleElementClass('tabHover', element);
});
connect(element, 'onmouseout', function (event) {
toggleElementClass('tabHover', element);
});
}, getElementsByTagAndClassName('li', 'tab', 'tab-list'));
When I hover over the elements, it does not toggle that class. Now,
this might not be the right function to use, but I've tried a
combination of addElementClass(element, 'tabHover') and
removeElementClass(element, 'tabHover') and that hasn't worked either.
I'm not sure exactly what I'm missing and can't wait 'till I hear back
from you guys!
In addition to a full example, please tell us which browser/platform
you're using.
Thank you,
Beau
--~--~-~--~~~---~--~~
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: Super-newbie question
On 26-May-06, at 4:56 PM, Jay Parlar wrote:
I'm just starting to learn MochiKit (actually, I'm just starting to
learn JavaScript as well), but I'm a long time Python guy, so I
felt it
would be a good fit.
Anyway, I'm trying to do a very simple 'connect', and I'm seeing some
strange behaviour.
I have the following in my script:
connect('tester', 'onclick', requestTags);
where 'tester' is the id of a link on the page, and requestTags is a
very simple function. If this is the only connect call I have, then
nothing happens when I click on the link. However, if I do this
instead:
var con = function() {
connect('tester', 'onclick', requestTags);
}
connect(window, 'onload', con);
then everything works perfectly.
Why is it that I first have to do a connection with the window? The
documents don't seem to mention anything about that (and I only got
the
idea from another post on this group).
Thanks in advance, and sorry if this is a really stupid question,
Jay P.
Hi Jay,
The reason you need to do this is the JavaScript in the head is
being executed before the rest of the page -- including your 'tester'
-- is loaded.
Beau
--~--~-~--~~~---~--~~
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] Uncheck
What's the best way to do the equivalent of element.checked = false; with DOM/MochiKit? Beau --~--~-~--~~~---~--~~ 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 VISUAL
On 17-May-06, at 10:42 AM, Jose R wrote:
Please could you or some one provides me with an example? i dont know
why this doesnt works... im trying to use:
slideDown(element [, options]) function but i dont get it... i get
errors on internet explorer... this is what im doing with another
function with the same result:
Move(banner, {x: 500});
is this correct?
do i need to include also DOM.js or Visual.js? im including just
Mochikit.js to html page.
Jose,
We're still working on the Visual stuff. It may still be buggy and
undocumented.
Thanks,
Beau
--~--~-~--~~~---~--~~
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: window.onunload
On 17-May-06, at 12:05 PM, Doug Crawford wrote: I ran into the same problem. If you use connect(window, 'onbeforeunload', ...) it should work on all browsers. On this same subject I noticed that MochiKit.Signal is disconnecting all of the DOM connections when the page unloads and it is doing this by registering on window.onunload which does not work in firefox. This might be intentional. I believe only IE has the memory leak bug related to circular DOM references So perhaps in firefox it is unnecessary to explicitly disconnect all DOM events when a page is unloaded. No, we weren't being that clever. If this helps Firefox or Safari clean up the page, we should probably switch to the onbeforeunload event in Signal. I'll think of a way to add test coverage for this. (Do iframes fire onbeforeunload events?) --~--~-~--~~~---~--~~ 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: window.onunload
Thanks Doug, I'll check into all of this when I get time for the ticket. On 17-May-06, at 1:31 PM, Doug Crawford wrote: I am not sure about iframes and actually the only browsers I have tested this with are IE and Firefox. I am guessing it will work with iframes and with other browsers. --~--~-~--~~~---~--~~ 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 Vs Prototype - For begginers
On 17-May-06, at 2:34 PM, Bob Ippolito wrote: I'm not going to have several versions of the docs on the site as that does all sorts of bad things for search engines. For example, if you search for PostgreSQL documentation you'll probably end up finding something in the old versions of the docs and that annoys the hell out of me. I'll accept patches if someone wants to go through the docs and come up with a clever and concise way to mark when a function was made available, but I am not going to have more than one version of the docs on the site. I like having the trunk version of docs and tests available on the site because if I didn't nobody would look at them until it's too late. Note that every version of MochiKit has always shipped with a full and identical copy of exactly the correct documentation for that release... robots.txt and a meta tag would fix that. The major search engines respect it. Let the search engines index /trunk, but keep them out of the release branches. I think it would cut down on some list and tracker noise. Beau --~--~-~--~~~---~--~~ 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: Bad link to Dojo on About page
On 13-May-06, at 8:35 AM, Gary wrote: I'm just surveying JavaScript libraries and resources right now, and discovered that the link to Dogo on http://www.mochikit.com/about.html is wrong. It links to dojotoolkit.com, but it should be dojotoolkit.org. Sorry if this is the wrong place for this, but I didn't see any link for web site feedback, and submitting an issue in the tracker seemed wrong. Gary Hi Gary, Thanks for reporting this, it's fixed: http://trac.mochikit.com/changeset/875 We keep a close eye on trac's timeline, so even typos like this should probably go into the tracker. Thanks, Beau --~--~-~--~~~---~--~~ 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: Retrieving arguments
On 3-May-06, at 9:52 AM, François wrote: Hi, When signal() is called, one can pass an argument to the slot. Am I right to use e.event() to retrieve this argument from within the slot? I discovered this haphazardly, and wanted to confirm it's the regular way. The docs do not specify any way to do this, as far as I can tell. In fact, it is stated that You should not need to use the event() property of e. Thanks, F. By the way: incredibly easy to use event management library. Hats down to the team. There are two systems for handling events. The browser event system will pass one argument to the slot, and that argument has an e.event () method that returns the native browser event. You should never need to access the browser event, instead use the other methods described in the docs to get mouse position, etc. The custom event system lets you create your own events by signaling them. When you do this, you can pass your own arguments through to your slots. When you use the custom event system, no browser event is generated. If this doesn't clear things up, please post some code with your actual/expected results to the list. Thanks! Beau --~--~-~--~~~---~--~~ 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: Retrieving arguments
Hi François,
var someObject = {}
function func(obj, str){
alert(obj.abc);
alert(obj.def);
alert(str);
}
connect(someObject, 'pouf', myObject.func);
signal(someObject, 'pouf', {abc:'yes', def:'no'}, 'last');
Notice that the extra parameters passed in signal() are passed onto
the function. The e.event() method is only available on the single
parameter passed when a native browser event is executed. I think
this is the source of your misunderstanding.
As for a good example of custom events, I haven't had the time to
cook one up. Does anyone have a good example?
On 3-May-06, at 11:04 AM, François wrote:
Beau Hartshorne wrote:
If this doesn't clear things up, please post some code with your
actual/expected results to the list.
Thanks for the quick answer. Some code to clear things up for me:
BEGIN CODE
var ident1, ident2, ident3, ident4;
var myObject = {};
myObject.func = function(e){
alert(e.event().abc); // Want to get to the object passed as the
argument with //signal()
}
var pack = {};
pack.aler = function(e){
signal('someEnclosingDiv','pouf', {abc:'yes', def:'no'});
};
function setup(){
ident1 = connect(discon, onclick, discon);
ident2 = connect(alink, onclick, pack, 'aler');
englob = connect(someEnclosingDiv, 'pouf', myObject.func);
}
ident3 = connect(window, onload, setup);
function discon (){
disconnect(ident1);
disconnect(ident2);
disconnect(ident3);
ident4 = connect(con, onclick, con);
}
function con (){
ident1 = connect(discon, onclick, discon);
ident2 = connect(alink, onclick, pack, 'aler');
disconnect(ident4);
}
END CODE
This bit of code basically sets three links to use the connection,
disconnect all signals, and a third one to reconnect them.
I do get the alert no from the argument passed with signal(), but I
was just wondering, in my first post, if this was the proper way to
get
to it from within the slot. Is there any other way to retrieve the
argument when using, as I did here, a custom event?
Can I bother you with this other question? Please ignore it if it's
too general.
What I want to accomplish here is a 'chain' of events that will
trigger, at the upper level of my DOM tree (someEnclosingDiv), a
specific reaction, related to a specific event lower down the tree (a
link in this case, enclosed in the former).
What is the proper or more common structure to accomplish this?
Basically, I want the upper level div to react, say, to a 'close'
signal from a button, or to some other event from another button, and
keep all the parts involved as loosely coupled as possible.
I've searched for patterns, or some indication, but found nothing
satisfying. I haven't programmed much with QT, so lack the experience
in GUI programming that would be handy in this situation.
Thanks,
F.
--~--~-~--~~~---~--~~
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: partial.apply
On 30-Apr-06, at 4:50 AM, venk wrote:
hi,
i am new to the mochikit world. and my stumbling block at the moment
is partial.apply.
i am able to understand that partial creates a partial function.
but,
what is apply? if i type, partial.apply in the interpreter, it
returns,
function apply() { [native code] }
but, i was not able to find any documentation for this function (or
did i miss it?).
can someone help me out?
Apply is implemented by the browser, not by MochiKit. Here are some
docs for it:
http://developer.mozilla.org/en/docs/
Core_JavaScript_1.5_Reference:Objects:Function:apply
--~--~-~--~~~---~--~~
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: question about signals on DOM elements
If the name doesn't work, it's easy to fix. Pick something short, and see if there's a standard you can follow. Just attach something to trac, and if it fits, I'll merge it into Signal. Thank you! On 6-Apr-06, at 5:13 PM, Doug Crawford wrote: I could try. I have never submitted anything before. I was just planning to use nodeWalk in Mochkit.Base to walk the subtree to call disconnectAll() if that function is present. What should this function be named? --~--~-~--~~~---~--~~ 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: question about signals on DOM elements
Doug, Would you mind taking a shot at this and submitting a patch for Signal to trac? Thanks! Beau On 5-Apr-06, at 10:05 AM, Doug Crawford wrote: I would like to see a new function in MochiKit.Signal that explicitly calls disconnectAll recursively throughout the subtree. It would be easy to implement this myself, but it sounds like everyone will need the same functionality when working with DOM signals and thick clients in IE. --~--~-~--~~~---~--~~ 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 connection status
No, but we should be able to add something like this. On 4-Apr-06, at 7:31 AM, Melkor wrote: For testing pourposes I would like to have a method to check the connection status of a signal associated with a DOM object. Is there a method so I can at least write: assert(isConnected(domElement, 'onclick'); --~--~-~--~~~---~--~~ 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: Signals status?
Right, but I should handle this a bit more elegantly than returning a 't' for F5. I'll rework key().string to return undefined to onkeypress listeners when someone types a character code. On 29-Mar-06, at 12:54 PM, Thomas Hervé wrote: I think Beau makes it this way for compatibility purpose (keypress works very bad on Safari; actually some like prototype refuse to register keypress events on it). It's actually well documented in Signal : if you want to filter Special Keys, use keydown. This said, you have access to everything you might need with the event() method, so I don't think it's a Signal problem --~--~-~--~~~---~--~~ 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: Signals status?
Thank you Dethe, I'll look into this. On 28-Mar-06, at 1:35 PM, Dethe Elza wrote: Well, I'm trying real hard *not* to look for control codes in keypress, but when I press F5 then keypress is firing and the evt.key().string is t, while the evt.key().code is 116. If I press the t key I get the exact same results. Now, if I dive down to the native event, the evt.event().keyCode is 0 for t and the evt.event().charCode is 0 for F5, but that's the only way I can tell them apart right now. I'm trying to filter non-printing keys out, so I need some way to detect F5 in keypress so I can ignore it. --~--~-~--~~~---~--~~ 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: Disconnect All?
I think I like disconnectAll(elem) and disconnectAll(elem, ['onmousedown', 'customSignal']) best. Other thoughts? On 27-Mar-06, at 5:03 PM, troels knak-nielsen wrote: Very good idea - I remember looking for exactly that the other day.Useful for putting in the destructor/teardown of a controller-object (widget). For the sake of interoperability, I think it's better with a separate method, rather than extending the signature of disconnect. Better to stay close to the standard removeEventListener. disconnectAll(elem); or disconnectAll(elem, onmousedown); perhaps even disconnectAll(elem, onmousedown, onmouseup); or disconnectAll(elem, [onmousedown, onmouseup]); --~--~-~--~~~---~--~~ 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] Signal Example
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? Thanks! --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups MochiKit group. To post to this group, send email to mochikit@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/mochikit -~--~~~~--~~--~--~---
[mochikit] Re: Signal Example
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? Great, I exported now. I'm happy with all of the DOM stuff, but I'm actually not a big user of the slots mechanism. I'm just starting to look at it now, and one thing I don't like is the requirement to registerSignals before connecting them. Dojo doesn't require this, but I haven't used this part of Signal enough to develop a strong feeling for or against registerSignals. I think some of the variable naming need to be cleaned up as well -- aren't slots, observers, and listeners the same thing? I'm working on a button example that should make use of other parts of the Signal API. It'll be a bit more complicated than draggable, but should show off some nice features. --~--~-~--~~~---~--~~ 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] elementPosition Tests
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? --~--~-~--~~~---~--~~ 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] MochiKit.Signal.registerSignals
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 --~--~-~--~~~---~--~~ 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()
Signal should not leak no matter what you do. That said, please do test your code with Drip and let me know if you find any problems. On 21-Mar-06, at 7:36 AM, Doug Crawford wrote: Typically, if you pass an element to an event handler via partial that references the element that is registering the handler it will cause a memory leak in IE. But I assume this will not happen with MochiKit.Signal since DOM handlers are unregistered during the window unload event. Is this correct? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
