[mochikit] Re: patch to connect custom signals to dom elements

2008-05-06 Thread Per Cederberg

I've also been bitten by this same issue, but didn't dig deeper into
it before. Great analysis and nice with a patched solution!

Looking at the code in MochiKit.Signal, I have two comments:

1. connect(src, signal, dst, func) uses late binding to dst[func] for
DOM signals, but uses early binding in other cases (with
MochiKit.Base.bind). I think we should use late binding at all times
instead.

2. I don't agree with the solution to the issue that signal() doesn't
fulfill its contract (as per the documentation). Rather, I think a
better solution would be to modify signal() to call ident.objOrFunc
and ident.objOrFunc directly instead of using ident.listener. Then it
would be fully up to the caller of signal() which arguments are to be
specified and in which order. Using the on prefix seems a bit like
an ad-hoc work-around to me.

Cheers,

/Per

On Mon, May 5, 2008 at 7:44 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:

  Hi all,

  I have found it very handy while building widgets to be able to
  connect custom signals on DOM elements to arbitrary handlers.
  Unfortunately signal( elem, signalName, param1, param2, ...) didn't
  work as expected.

  I traced this down to the isDOM check in the connect function.

  Signal.connect is assuming that if the src object has an
  addEventListener or an attachEvent attribute then the handler wants to
  be passed the MochiKit.Event object.  For my handlers bound to custom
  signals this is not the case, it wouldn't really matter except that I
  also like to pass arguments via MochiKit.signal to these handlers.

  My fix is based on the documented assumption that MochiKit assumes an
  `on' prefix for all DOM event signals.  I assume that MochiKit's goal
  here is to homogonise the different events between browsers.  For
  example, MochiKit assumes `on...' and then removes it for browsers
  that want to have `click' connected instead of 'onclick', etc.

  Thus if in Signal.connect the isDOM calculation is strengthened to
  make this assumption explicit then we get the ability to connect
  custom signals to DOM elements and have Signal.signal pass any extra
  parameters correctly.  Eg;

   var isDOM = (src.addEventListener || src.attachEvent) 
  (sig.substr(0,2) === 'on');

  The only caveat is that custom signals cannot start with 'on' which I
  think is acceptable as that is already a documented assumption by
  MochiKit.

  This allows for the following code to work;

  var myHandler = function( one, two, three ) { log( one, two,
  three ); };
  connect( 'my-div', 'my-custom-event', myHandler );
  signal ( 'my-div', 'my-custom-event', 1, 2, 3 );

  this will log 1 2 3.

  Below is a diff against SVN Revision 1368 including changes to the
  test suite.

  I have tested against FF2 and IE7 which is all I have access to, I
  would appreciate it if others with access to other browsers could run
  the test too.

  Regards, Simon Cusack.


  diff -r ae903235ba94 MochiKit/Signal.js
  --- a/MochiKit/Signal.jsMon May 05 13:37:27 2008 +1000
  +++ b/MochiKit/Signal.jsMon May 05 15:39:44 2008 +1000
  @@ -63,7 +63,7 @@
  str += '}';
  }
  }
  -if (this.type() == 'mouseover' || this.type() == 'mouseout'
  ||
  +if (this.type() == 'mouseover' || this.type() == 'mouseout'
  ||
  this.type() == 'mouseenter' || this.type() ==
  'mouseleave') {
  str += ', relatedTarget(): ' +
  repr(this.relatedTarget());
  }
  @@ -516,10 +516,10 @@
  if (sig === 'onload' || sig === 'onunload') {
  return function (nativeEvent) {
  obj[func].apply(obj, [new E(src, nativeEvent)]);
  -
  +
  var ident = new MochiKit.Signal.Ident({
  source: src, signal: sig, objOrFunc: obj,
  funcOrStr: func});
  -
  +
  MochiKit.Signal._disconnect(ident);
  };
  } else {
  @@ -531,10 +531,10 @@
  if (sig === 'onload' || sig === 'onunload') {
  return function (nativeEvent) {
  func.apply(obj, [new E(src, nativeEvent)]);
  -
  +
  var ident = new MochiKit.Signal.Ident({
  source: src, signal: sig, objOrFunc: func});
  -
  +
  MochiKit.Signal._disconnect(ident);
  };
  } else {
  @@ -613,7 +613,13 @@
  obj = src;
  }

  -var isDOM = !!(src.addEventListener || src.attachEvent);
  +//  The documentation states that DOM signals all start with
  +//  'on', so make this an explicit check, which has the bonus
  +//  of allowing us to connect custom signals to elements and
  +//  have our handler get called with the params passed to
  +//  signal instead of the wrapped native Event object.
  +var isDOM = (src.addEventListener || src.attachEvent) 
  (sig.substr(0,2) === 'on');
  +
  

[mochikit] Re: patch for ticket 304

2008-05-06 Thread Per Cederberg

Thanks for the patch! The relevant changes have been made, so things
should work properly in svn again.

/Per

On Mon, May 5, 2008 at 4:14 AM, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:

  Hi,

  tried to add this patch to the trac ticket that I raised but couldn't,
  so it is here instead.  Sorry if I didn't follow the correct protocol;

  8

  Refactored isChildNode to use MochiKit.Base predicates.

  Changed logic in tests to guard against cases when the child or parent
  node is not part of the DOM.

  Added extra tests to test suite, verified working on FF2, IE7.

  diff -r 8d983df7eccc MochiKit/DOM.js
  --- a/MochiKit/DOM.js   Wed Apr 30 17:16:32 2008 +1000
  +++ b/MochiKit/DOM.js   Mon May 05 11:48:42 2008 +1000
  @@ -352,20 +352,25 @@
  /** @id MochiKit.DOM.isChildNode */
  isChildNode: function (node, maybeparent) {
  var self = MochiKit.DOM;
  -if (typeof(node) == string) {
  -node = self.getElement(node);
  -}
  -if (typeof(maybeparent) == string) {
  -maybeparent = self.getElement(maybeparent);
  -}
  -if (typeof(node) == 'undefined' || node === null) {
  -return false;
  -}
  -while (node !== self._document) {
  +// ensure we are dealing with DOM elements not IDs
  +node= self.getElement(node);
  +maybeparent = self.getElement(maybeparent);
  +var tagName = null;
  +
  +if (node  maybeparent  (node !== self._document)) {
  +  while (node) {
  if (node === maybeparent) {
  -return true;
  +  return true;
  }
  +
  +// not all nodes have tagNames, eg text nodes.
  +tagName = node.tagName  node.tagName.toUpperCase();
  +if ((tagName === BODY) || (tagName === HTML)) {
  +  break;
  +}
  +
  node = node.parentNode;
  +  }
  }
  return false;
  },
  diff -r 8d983df7eccc tests/test_MochiKit-DOM.html
  --- a/tests/test_MochiKit-DOM.html  Wed Apr 30 17:16:32 2008 +1000
  +++ b/tests/test_MochiKit-DOM.html  Mon May 05 11:48:42 2008 +1000
  @@ -4,8 +4,8 @@
  script type=text/javascript src=../MochiKit/Base.js/
  script
  script type=text/javascript src=../MochiKit/Iter.js/
  script
  script type=text/javascript src=../MochiKit/DOM.js/script
  -script type=text/javascript src=../MochiKit/Style.js/
  script
  -script type=text/javascript src=SimpleTest/SimpleTest.js/
  script
  +script type=text/javascript src=../MochiKit/Style.js/
  script
  +script type=text/javascript src=SimpleTest/SimpleTest.js/
  script
  link rel=stylesheet type=text/css href=SimpleTest/
  test.css
   /head
   body
  @@ -69,8 +69,8 @@
  is( lst.join( ), original new, callStack in correct order
  (abort) );
  o.blah();
  is( lst.join( ), original new original new, callStack in
  correct order (again) );
  -
  -
  +
  +
  is( escapeHTML(\bar), lt;gt;quot;amp;bar,
  escapeHTML ); // for emacs highlighting: 

  var isDOM = function (value, expected, message) {
  @@ -93,7 +93,7 @@
  isDOM( d, 'spanword upspan/Think Different/span',
  'insertSiblingNodesBefore' );

  insertSiblingNodesAfter(d.childNodes[0], 'purple monkey',
  document.createElement('span'));
  -isDOM( d, 'spanword uppurple monkeyspan/span/Think
  Different/span', 'insertSiblingNodesAfter' );
  +isDOM( d, 'spanword uppurple monkeyspan/span/Think
  Different/span', 'insertSiblingNodesAfter' );

  d = createDOM(span);
  isDOM( d, span/, createDOM empty );
  @@ -107,7 +107,7 @@
  is( getNodeAttribute(d, 'baz'), wibble, createDOM
  attribute );
  removeNodeAttribute(d, spam);
  is( scrapeText(d), onetwothree, createDOM contents );
  -
  +
  isDOM( d, 'span baz=wibble foo=baronetwothree/span',
  createDOM contents );

  d = createDOM(span, null, function (f) {
  @@ -136,7 +136,7 @@
  domConverters.unregister(taco);

  isDOM( d, spanGoddamn, I like pork tacos/span, createDOM
  with custom converter );
  -
  +
  is(
  escapeHTML(toHTML(SPAN(null))),
  escapeHTML(toHTML(createDOM(span, null))),
  @@ -148,8 +148,8 @@

  var st = DIV(null, STRONG(null, d), oor , STRONG(null, f,
  SPAN(null, r), a), me);
  is( scrapeText(st), door frame, scrape in-order );
  -
  -
  +
  +
  ok( !isUndefinedOrNull(getElement(test)), getElement might
  work );
  ok( !isUndefinedOrNull($(test)), $alias$$ CASH MONEY alias
  might work );

  @@ -171,10 +171,10 @@
  toggleElementClass(bar, d);
  ok( d.className == baz, toggleElementClass:  + d.className);
  toggleElementClass(bar, d);
  -ok( hasElementClass(d, baz, bar),
  +ok( hasElementClass(d, baz, bar),
  toggleElementClass 2:  + d.className);
  addElementClass(d, bar);
  -ok( hasElementClass(d, baz, bar),
  +ok( hasElementClass(d, baz, bar),
  

[mochikit] Anyone Else Interested in a New Synthesized onReady Event (ala JQuery)?

2008-05-06 Thread machineghost

Hey All,

In trying to explain why he liked jQuery, a co-worker of mine clued me
in to a fairly cool method in that library: ready(someFunc);.  For
those who aren't familiar with jQuery, you can think of this method as
something like:
partial(connect, document, DOMContentLoaded)

In other word, it connects the provided function to the
DOMContentLoaded document event.  Now, the specific jQuery syntax I
could care less about (with partial I can already make any connect
variant I want), but what is really cool about the function is that it
makes it really easy to use the DOMContentLoaded event.  And why is
that cool?

1) The DOMContentLoaded event fires sooner (and if you have a heavy
page, MUCH sooner) than the onLoad event (although you can't do
stuff that depends on the rendered DOM, like getElementDimensions,
until onLoad goes off).  As a result, you can get significant
performance improvements just by changing (most of) your onLoad code
to be onDOMContentLoaded code.

2) Internet Explorer doesn't support DOMContentLoaded :-(  Luckily
however, this guy:
http://javascript.nwbox.com/IEContentLoaded/
figured out a hack to emulate the event in IE.  When you call
ready(someFunc), behind the scenes JQuery handles figuring out
whether to use the hack or the real event.

Now, I don't have any desire to switch to jQuery; it has the same
basic stuff as Mochikit, but none of the wonderful advanced stuff like
partial, keys, etc.  I would however like to have access to this
fake event.  Am I alone in this, or would others on this list like
to see a synthesized Mochikit DOMContentLoaded event (similar to the
existing synthesized onmouseenter and onmouseleave events)?

If there is interest in this event I'll be happy to help write a
proper Mochikit patch, but if not I'll just steal (quick and dirty
style) the jQuery event for my own purposes.
--~--~-~--~~~---~--~~
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: Anyone Else Interested in a New Synthesized onReady Event (ala JQuery)?

2008-05-06 Thread Felipe Alcacibar B

MochiKit is wonderful, as you wrote ir, but is the base, you can made
too much things, but you may need read or investigate some more time
like jQuery.

I prefer call it domready, because it is when dom nodes are loaded, i
use this code to implement domready, and i not have any problem.

[code]
var __domready__ = false;
if (document.addEventListener)
document.addEventListener(DOMContentLoaded, function() { if(!
__domready__) { __domready__ = true; window.signal(window,
'ondomready') }; }, false);

/[EMAIL PROTECTED] @*/
/[EMAIL PROTECTED] (@_win32)
document.write(script id=__ie_onload defer
src=javascript:void(0)\/script);
document.getElementById(__ie_onload).onreadystatechange =
function() {
if (this.readyState == complete) {
signal(window, 'ondomready');
}
};
/[EMAIL PROTECTED] @*/

if (/WebKit/i.test(navigator.userAgent)) {
  var __domready__timer__ = setInterval(function() {
if (/loaded|complete/.test(document.readyState)) signal(window,
'ondomready');
clearInterval(ctimer);
  }, 10);
}
[/code]

and when i need to call them i use

[code]
connect(window, 'ondomready', function () {
  alert('now i know kung fu');
});
[/code]


Felipe Alcacibar Buccioni
Developer of systems and solutions

On 6 mayo, 17:47, machineghost [EMAIL PROTECTED] wrote:
 Hey All,

 In trying to explain why he liked jQuery, a co-worker of mine clued me
 in to a fairly cool method in that library: ready(someFunc);.  For
 those who aren't familiar with jQuery, you can think of this method as
 something like:
 partial(connect, document, DOMContentLoaded)

 In other word, it connects the provided function to the
 DOMContentLoaded document event.  Now, the specific jQuery syntax I
 could care less about (with partial I can already make any connect
 variant I want), but what is really cool about the function is that it
 makes it really easy to use the DOMContentLoaded event.  And why is
 that cool?

 1) The DOMContentLoaded event fires sooner (and if you have a heavy
 page, MUCH sooner) than the onLoad event (although you can't do
 stuff that depends on the rendered DOM, like getElementDimensions,
 until onLoad goes off).  As a result, you can get significant
 performance improvements just by changing (most of) your onLoad code
 to be onDOMContentLoaded code.

 2) Internet Explorer doesn't support DOMContentLoaded :-(  Luckily
 however, this guy:http://javascript.nwbox.com/IEContentLoaded/
 figured out a hack to emulate the event in IE.  When you call
 ready(someFunc), behind the scenes JQuery handles figuring out
 whether to use the hack or the real event.

 Now, I don't have any desire to switch to jQuery; it has the same
 basic stuff as Mochikit, but none of the wonderful advanced stuff like
 partial, keys, etc.  I would however like to have access to this
 fake event.  Am I alone in this, or would others on this list like
 to see a synthesized Mochikit DOMContentLoaded event (similar to the
 existing synthesized onmouseenter and onmouseleave events)?

 If there is interest in this event I'll be happy to help write a
 proper Mochikit patch, but if not I'll just steal (quick and dirty
 style) the jQuery event for my own purposes.
--~--~-~--~~~---~--~~
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: Anyone Else Interested in a New Synthesized onReady Event (ala JQuery)?

2008-05-06 Thread Felipe Alcacibar B

oops, some mistake in the webkit part, sorry

[code]
if (/WebKit/i.test(navigator.userAgent)) {
  var __domready__timer__ = setInterval(function() {
if (/loaded|complete/.test(document.readyState)) signal(window,
'ondomready');
clearInterval(__domready__timer__);
  }, 10);
[/code]

On 7 mayo, 00:12, Felipe Alcacibar B [EMAIL PROTECTED] wrote:
 MochiKit is wonderful, as you wrote ir, but is the base, you can made
 too much things, but you may need read or investigate some more time
 like jQuery.

 I prefer call it domready, because it is when dom nodes are loaded, i
 use this code to implement domready, and i not have any problem.

 [code]
 var __domready__ = false;
 if (document.addEventListener)
 document.addEventListener(DOMContentLoaded, function() { if(!
 __domready__) { __domready__ = true; window.signal(window,
 'ondomready') }; }, false);

 /[EMAIL PROTECTED] @*/
 /[EMAIL PROTECTED] (@_win32)
 document.write(script id=__ie_onload defer
 src=javascript:void(0)\/script);
 document.getElementById(__ie_onload).onreadystatechange =
 function() {
 if (this.readyState == complete) {
 signal(window, 'ondomready');
 }
 };
 /[EMAIL PROTECTED] @*/

 if (/WebKit/i.test(navigator.userAgent)) {
   var __domready__timer__ = setInterval(function() {
 if (/loaded|complete/.test(document.readyState)) signal(window,
 'ondomready');
 clearInterval(ctimer);
   }, 10);}

 [/code]

 and when i need to call them i use

 [code]
 connect(window, 'ondomready', function () {
   alert('now i know kung fu');});

 [/code]

 Felipe Alcacibar Buccioni
 Developer of systems and solutions

 On 6 mayo, 17:47, machineghost [EMAIL PROTECTED] wrote:

  Hey All,

  In trying to explain why he liked jQuery, a co-worker of mine clued me
  in to a fairly cool method in that library: ready(someFunc);.  For
  those who aren't familiar with jQuery, you can think of this method as
  something like:
  partial(connect, document, DOMContentLoaded)

  In other word, it connects the provided function to the
  DOMContentLoaded document event.  Now, the specific jQuery syntax I
  could care less about (with partial I can already make any connect
  variant I want), but what is really cool about the function is that it
  makes it really easy to use the DOMContentLoaded event.  And why is
  that cool?

  1) The DOMContentLoaded event fires sooner (and if you have a heavy
  page, MUCH sooner) than the onLoad event (although you can't do
  stuff that depends on the rendered DOM, like getElementDimensions,
  until onLoad goes off).  As a result, you can get significant
  performance improvements just by changing (most of) your onLoad code
  to be onDOMContentLoaded code.

  2) Internet Explorer doesn't support DOMContentLoaded :-(  Luckily
  however, this guy:http://javascript.nwbox.com/IEContentLoaded/
  figured out a hack to emulate the event in IE.  When you call
  ready(someFunc), behind the scenes JQuery handles figuring out
  whether to use the hack or the real event.

  Now, I don't have any desire to switch to jQuery; it has the same
  basic stuff as Mochikit, but none of the wonderful advanced stuff like
  partial, keys, etc.  I would however like to have access to this
  fake event.  Am I alone in this, or would others on this list like
  to see a synthesized Mochikit DOMContentLoaded event (similar to the
  existing synthesized onmouseenter and onmouseleave events)?

  If there is interest in this event I'll be happy to help write a
  proper Mochikit patch, but if not I'll just steal (quick and dirty
  style) the jQuery event for my own purposes.
--~--~-~--~~~---~--~~
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: Anyone Else Interested in a New Synthesized onReady Event (ala JQuery)?

2008-05-06 Thread Per Cederberg

I liked the ondomready name and structure. Looking at MSDN, they
provide the following solution instead of writing new script tags into
the document (not tested, just pasted):

document.onreadystatechange=fnStartInit;
function fnStartInit()
{
   if (document.readyState==complete)
   {
  // Finish initialization.
   }
}

Otherwise I like the proposed solutions and vote for inclusion to
MochiKit.Signal. Never know when it might be handy.

Cheers,

/Per

On Wed, May 7, 2008 at 6:21 AM, Felipe Alcacibar B [EMAIL PROTECTED] wrote:

  oops, some mistake in the webkit part, sorry

  [code]

 if (/WebKit/i.test(navigator.userAgent)) {
   var __domready__timer__ = setInterval(function() {
 if (/loaded|complete/.test(document.readyState)) signal(window,
  'ondomready');
 clearInterval(__domready__timer__);
   }, 10);
  [/code]



  On 7 mayo, 00:12, Felipe Alcacibar B [EMAIL PROTECTED] wrote:
   MochiKit is wonderful, as you wrote ir, but is the base, you can made
   too much things, but you may need read or investigate some more time
   like jQuery.
  
   I prefer call it domready, because it is when dom nodes are loaded, i
   use this code to implement domready, and i not have any problem.
  
   [code]
   var __domready__ = false;
   if (document.addEventListener)
   document.addEventListener(DOMContentLoaded, function() { if(!
   __domready__) { __domready__ = true; window.signal(window,
   'ondomready') }; }, false);
  
   /[EMAIL PROTECTED] @*/
   /[EMAIL PROTECTED] (@_win32)
   document.write(script id=__ie_onload defer
   src=javascript:void(0)\/script);
   document.getElementById(__ie_onload).onreadystatechange =
   function() {
   if (this.readyState == complete) {
   signal(window, 'ondomready');
   }
   };
   /[EMAIL PROTECTED] @*/
  
   if (/WebKit/i.test(navigator.userAgent)) {
 var __domready__timer__ = setInterval(function() {
   if (/loaded|complete/.test(document.readyState)) signal(window,
   'ondomready');
   clearInterval(ctimer);
 }, 10);}
  
   [/code]
  
   and when i need to call them i use
  
   [code]
   connect(window, 'ondomready', function () {
 alert('now i know kung fu');});
  
   [/code]
  
   Felipe Alcacibar Buccioni
   Developer of systems and solutions
  
   On 6 mayo, 17:47, machineghost [EMAIL PROTECTED] wrote:
  
Hey All,
  
In trying to explain why he liked jQuery, a co-worker of mine clued me
in to a fairly cool method in that library: ready(someFunc);.  For
those who aren't familiar with jQuery, you can think of this method as
something like:
partial(connect, document, DOMContentLoaded)
  
In other word, it connects the provided function to the
DOMContentLoaded document event.  Now, the specific jQuery syntax I
could care less about (with partial I can already make any connect
variant I want), but what is really cool about the function is that it
makes it really easy to use the DOMContentLoaded event.  And why is
that cool?
  
1) The DOMContentLoaded event fires sooner (and if you have a heavy
page, MUCH sooner) than the onLoad event (although you can't do
stuff that depends on the rendered DOM, like getElementDimensions,
until onLoad goes off).  As a result, you can get significant
performance improvements just by changing (most of) your onLoad code
to be onDOMContentLoaded code.
  
2) Internet Explorer doesn't support DOMContentLoaded :-(  Luckily
however, this guy:http://javascript.nwbox.com/IEContentLoaded/
figured out a hack to emulate the event in IE.  When you call
ready(someFunc), behind the scenes JQuery handles figuring out
whether to use the hack or the real event.
  
Now, I don't have any desire to switch to jQuery; it has the same
basic stuff as Mochikit, but none of the wonderful advanced stuff like
partial, keys, etc.  I would however like to have access to this
fake event.  Am I alone in this, or would others on this list like
to see a synthesized Mochikit DOMContentLoaded event (similar to the
existing synthesized onmouseenter and onmouseleave events)?
  
If there is interest in this event I'll be happy to help write a
proper Mochikit patch, but if not I'll just steal (quick and dirty
style) the jQuery event for my own purposes.
  


--~--~-~--~~~---~--~~
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: Anyone Else Interested in a New Synthesized onReady Event (ala JQuery)?

2008-05-06 Thread Bob Ippolito

This would definitely be convenient, it's always been on my list and
I've hacked together crappy (polling) implementations once or twice,
but I never needed it bad enough to tackle all of the cross-browser
issues myself :)

On Tue, May 6, 2008 at 10:51 PM, Per Cederberg [EMAIL PROTECTED] wrote:

  I liked the ondomready name and structure. Looking at MSDN, they
  provide the following solution instead of writing new script tags into
  the document (not tested, just pasted):

  document.onreadystatechange=fnStartInit;
  function fnStartInit()
  {
if (document.readyState==complete)
{
   // Finish initialization.
}
  }

  Otherwise I like the proposed solutions and vote for inclusion to
  MochiKit.Signal. Never know when it might be handy.

  Cheers,

  /Per



  On Wed, May 7, 2008 at 6:21 AM, Felipe Alcacibar B [EMAIL PROTECTED] wrote:
  
oops, some mistake in the webkit part, sorry
  
[code]
  
   if (/WebKit/i.test(navigator.userAgent)) {
 var __domready__timer__ = setInterval(function() {
   if (/loaded|complete/.test(document.readyState)) signal(window,
'ondomready');
   clearInterval(__domready__timer__);
 }, 10);
[/code]
  
  
  
On 7 mayo, 00:12, Felipe Alcacibar B [EMAIL PROTECTED] wrote:
 MochiKit is wonderful, as you wrote ir, but is the base, you can made
 too much things, but you may need read or investigate some more time
 like jQuery.

 I prefer call it domready, because it is when dom nodes are loaded, i
 use this code to implement domready, and i not have any problem.

 [code]
 var __domready__ = false;
 if (document.addEventListener)
 document.addEventListener(DOMContentLoaded, function() { if(!
 __domready__) { __domready__ = true; window.signal(window,
 'ondomready') }; }, false);

 /[EMAIL PROTECTED] @*/
 /[EMAIL PROTECTED] (@_win32)
 document.write(script id=__ie_onload defer
 src=javascript:void(0)\/script);
 document.getElementById(__ie_onload).onreadystatechange =
 function() {
 if (this.readyState == complete) {
 signal(window, 'ondomready');
 }
 };
 /[EMAIL PROTECTED] @*/

 if (/WebKit/i.test(navigator.userAgent)) {
   var __domready__timer__ = setInterval(function() {
 if (/loaded|complete/.test(document.readyState)) signal(window,
 'ondomready');
 clearInterval(ctimer);
   }, 10);}

 [/code]

 and when i need to call them i use

 [code]
 connect(window, 'ondomready', function () {
   alert('now i know kung fu');});

 [/code]

 Felipe Alcacibar Buccioni
 Developer of systems and solutions

 On 6 mayo, 17:47, machineghost [EMAIL PROTECTED] wrote:

  Hey All,

  In trying to explain why he liked jQuery, a co-worker of mine clued me
  in to a fairly cool method in that library: ready(someFunc);.  For
  those who aren't familiar with jQuery, you can think of this method as
  something like:
  partial(connect, document, DOMContentLoaded)

  In other word, it connects the provided function to the
  DOMContentLoaded document event.  Now, the specific jQuery syntax I
  could care less about (with partial I can already make any connect
  variant I want), but what is really cool about the function is that it
  makes it really easy to use the DOMContentLoaded event.  And why is
  that cool?

  1) The DOMContentLoaded event fires sooner (and if you have a heavy
  page, MUCH sooner) than the onLoad event (although you can't do
  stuff that depends on the rendered DOM, like getElementDimensions,
  until onLoad goes off).  As a result, you can get significant
  performance improvements just by changing (most of) your onLoad code
  to be onDOMContentLoaded code.

  2) Internet Explorer doesn't support DOMContentLoaded :-(  Luckily
  however, this guy:http://javascript.nwbox.com/IEContentLoaded/
  figured out a hack to emulate the event in IE.  When you call
  ready(someFunc), behind the scenes JQuery handles figuring out
  whether to use the hack or the real event.

  Now, I don't have any desire to switch to jQuery; it has the same
  basic stuff as Mochikit, but none of the wonderful advanced stuff like
  partial, keys, etc.  I would however like to have access to this
  fake event.  Am I alone in this, or would others on this list like
  to see a synthesized Mochikit DOMContentLoaded event (similar to the
  existing synthesized onmouseenter and onmouseleave events)?

  If there is interest in this event I'll be happy to help write a
  proper Mochikit patch, but if not I'll just steal (quick and dirty
  style) the jQuery event for my own purposes.

  

  


--~--~-~--~~~---~--~~
You received this message