Earlier this year

• Nov 21, 2009

  r140 (Correcting typos in comments, small code normalization to fi...) committed by eugene.lazutkin   -   Correcting typos in comments, small code normalization to fix potential bugs.

  Correcting typos in comments, small code normalization to fix potential bugs.
• Nov 20, 2009

  r139 (adding a bunch of closing head elements and a new nodelist a...) committed by phiggins   -   adding a bunch of closing head elements and a new nodelist api GRAB, FTW. bumping minimum version to 1.4 because it uses 1.4 specific apis now

  adding a bunch of closing head elements and a new nodelist api GRAB, FTW. bumping minimum version to 1.4 because it uses 1.4 specific apis now
• Nov 07, 2009

  r138 (adding dojo.getSelection and cleanup keys a tiny bit.adjustm...) committed by phiggins   -   adding dojo.getSelection and cleanup keys a tiny bit.adjustments to hoverClass for size

  adding dojo.getSelection and cleanup keys a tiny bit.adjustments to hoverClass for size
• Oct 31, 2009

  r137 (restoring public function d.fn and adding some more undersco...) committed by phiggins   -   restoring public function d.fn and adding some more underscorejs-isms (clean implementations)

  restoring public function d.fn and adding some more underscorejs-isms (clean implementations)
• Oct 30, 2009

  r136 (adding dojo.compose to base plugd with tests) committed by phiggins   -   adding dojo.compose to base plugd with tests

  adding dojo.compose to base plugd with tests
• Sep 23, 2009

  r135 (adding in dojo.now() + tests. speedup forIn. ) committed by phiggins   -   adding in dojo.now() + tests. speedup forIn.

  adding in dojo.now() + tests. speedup forIn.
• Sep 22, 2009

  r134 (proto code to show blowery) committed by phiggins   -   proto code to show blowery

  proto code to show blowery
• Sep 08, 2009

  r133 (no need to mix, object ref ftw) committed by phiggins   -   no need to mix, object ref ftw

  no need to mix, object ref ftw
• Sep 08, 2009

  r132 (small reduction) committed by phiggins   -   small reduction

  small reduction
• Aug 10, 2009

  r131 (testing if custom events bubble) committed by phiggins   -   testing if custom events bubble

  testing if custom events bubble
• Aug 10, 2009

  r130 (adding lots of trigger tests) committed by phiggins   -   adding lots of trigger tests

  adding lots of trigger tests
• Aug 10, 2009

  r129 (updating trigger to handle custom IE events, or anything doj...) committed by phiggins   -   updating trigger to handle custom IE events, or anything dojo.connect()ed to, and mouseenter in FF

  updating trigger to handle custom IE events, or anything dojo.connect()ed to, and mouseenter in FF
• Aug 08, 2009

  r128 (exposing dojo._trigger as fast path, better docs, dropping c...) committed by phiggins   -   exposing dojo._trigger as fast path, better docs, dropping closed triggerObject

  exposing dojo._trigger as fast path, better docs, dropping closed triggerObject
• Aug 04, 2009

  issue 10 (base.js does not appear to play well with dijit.layout.TabCo...) reported by tonyissakov   -   Using Nightly (5 Aug) dojo, Latest source of base.js from code.google.com With the dijit test case "test_TabContainer.html", add plugd base.js after dojo.js load. Reload and for me the tabs are no longer drawn correctly.

  Using Nightly (5 Aug) dojo, Latest source of base.js from code.google.com With the dijit test case "test_TabContainer.html", add plugd base.js after dojo.js load. Reload and for me the tabs are no longer drawn correctly.
• Jul 19, 2009

  3 Wiki pages changed by phiggins   -  

  Edited APIDocs, BuildingPlugd">BuildingPlugd, GettingStarted">GettingStarted

  Edited APIDocs, BuildingPlugd">BuildingPlugd, GettingStarted">GettingStarted
• Jul 19, 2009

  r126 (adding in keys.js plugin. might change it to getKeys toavoid...) committed by phiggins   -   adding in keys.js plugin. might change it to getKeys toavoid the clobbering

  adding in keys.js plugin. might change it to getKeys toavoid the clobbering
• Jul 03, 2009

  r125 (cleanup node.js, remove _Node.fn (use .prototype), docs and ...) committed by phiggins   -   cleanup node.js, remove _Node.fn (use .prototype), docs and tests. run in ie8, ff35,31 sf4, chrome2

  cleanup node.js, remove _Node.fn (use .prototype), docs and tests. run in ie8, ff35,31 sf4, chrome2
• Jun 22, 2009

  r124 (fixing connect() array shifting logic, adding in toList()) committed by phiggins   -   fixing connect() array shifting logic, adding in toList()

  fixing connect() array shifting logic, adding in toList()
• Jun 21, 2009

  r123 (adding dojo.node support to dojo.trigger plugin optionally) committed by phiggins   -   adding dojo.node support to dojo.trigger plugin optionally

  adding dojo.node support to dojo.trigger plugin optionally
• Jun 21, 2009

  r122 (actually pushing node.js -- whoops) committed by phiggins   -   actually pushing node.js -- whoops

  actually pushing node.js -- whoops
• Jun 21, 2009

  r121 (adding in dojo.node, also removing a bunch of api's provided...) committed by phiggins   -   adding in dojo.node, also removing a bunch of api's provided in Dojo Core officially in trunk - please please let me know if I broke anything

  adding in dojo.node, also removing a bunch of api's provided in Dojo Core officially in trunk - please please let me know if I broke anything
• Jun 15, 2009

  issue 9 (block() determines the div's height incorrectly and also eve...) commented on by khamenya   -   it also didn't tolerate the move of blocked div... Anyway I got it working for my project. The tiny patch is attached. P.S. it should hardly work for ie6 though. Also, the handlers on resize/move events are not needed anymore (I just didn't want touch things that I do not understand...).

  it also didn't tolerate the move of blocked div... Anyway I got it working for my project. The tiny patch is attached. P.S. it should hardly work for ie6 though. Also, the handlers on resize/move events are not needed anymore (I just didn't want touch things that I do not understand...).
• Jun 15, 2009

  issue 9 (block() determines the div's height incorrectly and also eve...) commented on by khamenya   -   I've just checked the div's height right before block() invocation with dojo.style(dojo.byId('divcontainer'), 'height') at this moment it is indeed higher than the final appropriate value. That is, the whole Dojo widgets and other divs are perhaps are not yet rendered. That is block() comes to early. The question is Q: could the block() be async-safe? (would be a best case) or Q: could it somehow be determined that Dojo elements are already rendered?

  I've just checked the div's height right before block() invocation with dojo.style(dojo.byId('divcontainer'), 'height') at this moment it is indeed higher than the final appropriate value. That is, the whole Dojo widgets and other divs are perhaps are not yet rendered. That is block() comes to early. The question is Q: could the block() be async-safe? (would be a best case) or Q: could it somehow be determined that Dojo elements are already rendered?
• Jun 15, 2009

  issue 9 (block() determines the div's height incorrectly and also eve...) reported by khamenya   -   1. I can't supply an exact repro. 2. My case is as following. I create programmatically some widgets inside of a div and place them with the placeAt. Right after that happens a call: dojo.block(dojo.byId('divcontainer')); When script finishes one can see, that the height of the container div is falsely determined by block() and it puts a curtain about 3 times bigger in Y-schale than appropriate. if instead of doing the above call batched in a script I do it from console, i.e. giving more time to a browser, then it works OK. If instead of the above call I do these 3 calls batched in script: dojo.block(dojo.byId('divcontainer')); dojo.unblock(dojo.byId('divcontainer')); dojo.block(dojo.byId('divcontainer')); then there is no curtain put at all. Dojo 1.3.1 is used

  1. I can't supply an exact repro. 2. My case is as following. I create programmatically some widgets inside of a div and place them with the placeAt. Right after that happens a call: dojo.block(dojo.byId('divcontainer')); When script finishes one can see, that the height of the container div is falsely determined by block() and it puts a curtain about 3 times bigger in Y-schale than appropriate. if instead of doing the above call batched in a script I do it from console, i.e. giving more time to a browser, then it works OK. If instead of the above call I do these 3 calls batched in script: dojo.block(dojo.byId('divcontainer')); dojo.unblock(dojo.byId('divcontainer')); dojo.block(dojo.byId('divcontainer')); then there is no curtain put at all. Dojo 1.3.1 is used
• Jun 12, 2009

  r120 (duplicate method. adding in require()) committed by phiggins   -   duplicate method. adding in require()

  duplicate method. adding in require()
• Jun 09, 2009

  r119 (tag from 1.3.0 that remained uncommitted) committed by phiggins   -   tag from 1.3.0 that remained uncommitted

  tag from 1.3.0 that remained uncommitted
• May 30, 2009

  issue 6 ([Patch] dojo.ancestor) commented on by mich...@schuerig.de   -   Continued at http://bugs.dojotoolkit.org/ticket/9359

  Continued at http://bugs.dojotoolkit.org/ticket/9359
• May 29, 2009

  r118 (there is no need for this to use base.js) committed by phiggins   -   there is no need for this to use base.js

  there is no need for this to use base.js
• May 29, 2009

  issue 4 (val broken in IE?) Status changed by phiggins   -   val() is in Dojo trunk now. Issues should be filed there.

  Status: Invalid

  val() is in Dojo trunk now. Issues should be filed there.

  Status: Invalid
• May 29, 2009

  issue 6 ([Patch] dojo.ancestor) Status changed by phiggins   -   michael: In Dojo trunk we now have parent/parents/siblings/closest/children/next/prev/fist/last/even/odd functions in dojo.NodeList-traverse ... Going to mark this as fixed. Plugd's trunk is up to date with Dojo's trunk including these functions. Thanks for the patch and filing this! Keep em' coming, anything you think of :)

  Status: Verified

  michael: In Dojo trunk we now have parent/parents/siblings/closest/children/next/prev/fist/last/even/odd functions in dojo.NodeList-traverse ... Going to mark this as fixed. Plugd's trunk is up to date with Dojo's trunk including these functions. Thanks for the patch and filing this! Keep em' coming, anything you think of :)

  Status: Verified
• May 29, 2009

  issue 8 ([Patch] Implement next()/prev() methods for dojo.NodeList) Status changed by phiggins   -   These functions are available in Dojo trunk as of rev [17568] and [17573] ... I had intended to implement them in plugd, but turns out Dojo went full on and with NodeList-extensions. Also, end() was implemented, and stash() being used on most functions that return a new NodeList, so you can .next().end().prev().next().end().end() to your hearts content :) I've already updated plugd's trunk to be 1:1 with Dojo's, so they are now locked to each other again, so your patch will definitely help pre 1.4 users. Not sure how to do that effectively. It is complicated enough with the linear code path I've been keeping.

  Status: Invalid

  These functions are available in Dojo trunk as of rev [17568] and [17573] ... I had intended to implement them in plugd, but turns out Dojo went full on and with NodeList-extensions. Also, end() was implemented, and stash() being used on most functions that return a new NodeList, so you can .next().end().prev().next().end().end() to your hearts content :) I've already updated plugd's trunk to be 1:1 with Dojo's, so they are now locked to each other again, so your patch will definitely help pre 1.4 users. Not sure how to do that effectively. It is complicated enough with the linear code path I've been keeping.

  Status: Invalid
• May 29, 2009

  issue 8 ([Patch] Implement next()/prev() methods for dojo.NodeList) reported by forberg   -   I miss the next()/prev() methods for even more DOM traversing in dojo. So here i have a patch to plugd that might be accepted? The methods also support filtering. dojo.extend(dojo.NodeList, { next: function(f) { var r = new dojo.NodeList(); this.forEach(dojo.hitch(this, function(i) { var n = this._nodeType(i, "nextSibling"); if (n) { r.push(n); } })); if(f) { r = r.filter(f); } return r; }, prev: function(f) { var r = new dojo.NodeList(); this.forEach(dojo.hitch(this, function(i) { var n = this._nodeType(i, "previousSibling"); if (n) { r.push(n); } })); if(f) { r = r.filter(f); } return r; }, _nodeType: function(node, type) { node = node[type]; if (node) { while (node && node.nodeType != 1) node = node[type]; return node; } return false; } });

  I miss the next()/prev() methods for even more DOM traversing in dojo. So here i have a patch to plugd that might be accepted? The methods also support filtering. dojo.extend(dojo.NodeList, { next: function(f) { var r = new dojo.NodeList(); this.forEach(dojo.hitch(this, function(i) { var n = this._nodeType(i, "nextSibling"); if (n) { r.push(n); } })); if(f) { r = r.filter(f); } return r; }, prev: function(f) { var r = new dojo.NodeList(); this.forEach(dojo.hitch(this, function(i) { var n = this._nodeType(i, "previousSibling"); if (n) { r.push(n); } })); if(f) { r = r.filter(f); } return r; }, _nodeType: function(node, type) { node = node[type]; if (node) { while (node && node.nodeType != 1) node = node[type]; return node; } return false; } });
• May 22, 2009

  r117 (more reductions for overlapping functionality in dojo base n...) committed by phiggins   -   more reductions for overlapping functionality in dojo base now

  more reductions for overlapping functionality in dojo base now
• May 22, 2009

  r116 (updating plugd to work with new dojo methods introduced in [...) committed by phiggins   -   updating plugd to work with new dojo methods introduced in [17568] refs #8612

  updating plugd to work with new dojo methods introduced in [17568] refs #8612
• May 21, 2009

  r115 (reducing twit plugin code size by using new script plugin fe...) committed by phiggins   -   reducing twit plugin code size by using new script plugin features

  reducing twit plugin code size by using new script plugin features
• May 21, 2009

  r114 (for convenience) committed by phiggins   -   for convenience

  for convenience
• May 21, 2009

  r113 (making the plugin thinger its own module) committed by phiggins   -   making the plugin thinger its own module

  making the plugin thinger its own module
• May 20, 2009

  r112 (this one feels like a no-brainer) committed by phiggins   -   this one feels like a no-brainer

  this one feels like a no-brainer
• May 20, 2009

  r111 (making addScript handle inline callback definitions. somethi...) committed by phiggins   -   making addScript handle inline callback definitions. something=? will force jsonp loading and create the callback stub for you

  making addScript handle inline callback definitions. something=? will force jsonp loading and create the callback stub for you
• May 19, 2009

  r110 (adding .size() method and basic unit tests. probably not rea...) committed by phiggins   -   adding .size() method and basic unit tests. probably not ready for primetime, but is convenient for stuff you know you can do

  adding .size() method and basic unit tests. probably not ready for primetime, but is convenient for stuff you know you can do
• May 19, 2009

  r109 (just playing around. no one should be using this module anyw...) committed by phiggins   -   just playing around. no one should be using this module anyway

  just playing around. no one should be using this module anyway
• May 19, 2009

  r108 (adding ability to prefix exported methods. making it more mo...) committed by phiggins   -   adding ability to prefix exported methods. making it more moo-ish with $

  adding ability to prefix exported methods. making it more moo-ish with $
• May 19, 2009

  r107 (making @reply links global regexp, was only matching first) committed by phiggins   -   making @reply links global regexp, was only matching first

  making @reply links global regexp, was only matching first
• May 08, 2009

  r106 (comment out test that only exists locally for now) committed by phiggins   -   comment out test that only exists locally for now

  comment out test that only exists locally for now
• May 08, 2009

  issue 7 (config do using(var djConfig ={conflict:true}) not works!) Status changed by phiggins   -   I've added unit tests ensuring both djConfig="" and var djConfig={} work to trigger dojo.conflict() ... your attached test is loading jquery.js as well, which uses the $ when no calling jQuery.noConflict(). It is not supported to run Dojo in conflict mode alongside jQuery (this is the whole point of dojo.conflict()) ... If you wish to run Dojo alongside jQuery, simply don't use conflict(). Tests added in [105]

  Status: Invalid

  I've added unit tests ensuring both djConfig="" and var djConfig={} work to trigger dojo.conflict() ... your attached test is loading jquery.js as well, which uses the $ when no calling jQuery.noConflict(). It is not supported to run Dojo in conflict mode alongside jQuery (this is the whole point of dojo.conflict()) ... If you wish to run Dojo alongside jQuery, simply don't use conflict(). Tests added in [105]

  Status: Invalid
• May 08, 2009

  r105 (adding tests ensuring djConfig.conflict works in both cases) committed by phiggins   -   adding tests ensuring djConfig.conflict works in both cases

  adding tests ensuring djConfig.conflict works in both cases
• May 07, 2009

  issue 7 (config do using(var djConfig ={conflict:true}) not works!) reported by qxodr...@gmail.com   -   using djConfig ="conflict:true" it's work.

  using djConfig ="conflict:true" it's work.
• May 04, 2009

  issue 5 (Neither show() nor toggle() shows elements that were "hidden...) commented on by phiggins   -   the test case can just be a regular .html file which includes the plugd/base.js and dojo.js relative from the plugd/tests/ folder. I can convert it to unit tests with little effort (or you can add the test to the existing base.html unit test page. it's pretty simple, run the test then t.is("block", node.style.display) etc) ... It gets into murky water considering the inline/block/"" properties, and I am totally open to suggestions here. I like the idea of passing an additional arg, but to fall in line with other dojo conventions, perhaps the "speed" arg (another convoluted implementation) should be converted to an object hash and use "magic args". eg: dojo.show("nodeId") just shows. dojo.show("nodeId", { use:"block" }) would force display:block (or use:"visibility" and default to display:block/none for hiding/showing) ...

  the test case can just be a regular .html file which includes the plugd/base.js and dojo.js relative from the plugd/tests/ folder. I can convert it to unit tests with little effort (or you can add the test to the existing base.html unit test page. it's pretty simple, run the test then t.is("block", node.style.display) etc) ... It gets into murky water considering the inline/block/"" properties, and I am totally open to suggestions here. I like the idea of passing an additional arg, but to fall in line with other dojo conventions, perhaps the "speed" arg (another convoluted implementation) should be converted to an object hash and use "magic args". eg: dojo.show("nodeId") just shows. dojo.show("nodeId", { use:"block" }) would force display:block (or use:"visibility" and default to display:block/none for hiding/showing) ...
• May 04, 2009

  issue 5 (Neither show() nor toggle() shows elements that were "hidden...) commented on by romanrmr   -   If the test case can be a regular case a user would use as opposed to something special dojo developers may require (I don't know requirements for test cases), I could provide one. However, I think that before changes are made, it should be decided if only block elements are going to be handled or inline ones too. If it's the latter, then it should be taken into consideration that inline elements can be displayed as block elements, and the library should be able to support this. One way to support this that I can see is to pass an optional argument that would specify which type of "display" to use.

  If the test case can be a regular case a user would use as opposed to something special dojo developers may require (I don't know requirements for test cases), I could provide one. However, I think that before changes are made, it should be decided if only block elements are going to be handled or inline ones too. If it's the latter, then it should be taken into consideration that inline elements can be displayed as block elements, and the library should be able to support this. One way to support this that I can see is to pass an optional argument that would specify which type of "display" to use.
• May 04, 2009

  issue 5 (Neither show() nor toggle() shows elements that were "hidden...) commented on by phiggins   -   wow sorry -- I apparently don't get notificiations when new issues are filed. So the solution here is to fix "show". The implementation is somewhat convoluted, as it spawned out of a "joke" about how easy it is to just set .style("display", "none") or "block" manually, and that a generic function like this is hard to do. I would like to get rid of entirely the djconfig.useBlock / displayStyle (which switches visbility:hidden to visibility:visible). It seems some calculated styles are going to have to take place to determine the visibile state of an element and go from there. would you mind to attach a simple testcase I can drop in plugd/tests/ to use for checking this?

  wow sorry -- I apparently don't get notificiations when new issues are filed. So the solution here is to fix "show". The implementation is somewhat convoluted, as it spawned out of a "joke" about how easy it is to just set .style("display", "none") or "block" manually, and that a generic function like this is hard to do. I would like to get rid of entirely the djconfig.useBlock / displayStyle (which switches visbility:hidden to visibility:visible). It seems some calculated styles are going to have to take place to determine the visibile state of an element and go from there. would you mind to attach a simple testcase I can drop in plugd/tests/ to use for checking this?