Comments on: Mucking Dijit http://dojocampus.org/content/2008/02/25/mucking-dijit/ The definitive resource for all things Dojo: past, present, future. Tue, 06 Jan 2009 22:00:31 +0000 http://wordpress.org/?v=2.5.1 By: Hack Your Life » Blog Archive » Memorati revamp live! (and dijit.Dialog update) http://dojocampus.org/content/2008/02/25/mucking-dijit/#comment-13 Hack Your Life » Blog Archive » Memorati revamp live! (and dijit.Dialog update) Tue, 04 Mar 2008 00:49:38 +0000 http://dojocampus.org/content/?p=50#comment-13 [...] follow-up on my dijit.Dialog comments (and here!), I ended-up abandoning my fork. I decided that the original positioning algorithm was acceptable, [...] [...] follow-up on my dijit.Dialog comments (and here!), I ended-up abandoning my fork. I decided that the original positioning algorithm was acceptable, [...]

]]> By: dsnopek http://dojocampus.org/content/2008/02/25/mucking-dijit/#comment-4 dsnopek Mon, 25 Feb 2008 20:00:18 +0000 http://dojocampus.org/content/?p=50#comment-4 Great article! This sort of extension should be a part of any JavaScript developers personal tool set. However, doing this sort of extension on someone else's library (ie. dijit), worries me when it deals with internal implementation details. After all, "titleNode" used in your examples (as far as I know) is not a documented part of dijit.Dialog. You can only know about this by reading the code. When a new version of dijit comes out, it is not guaranteed to be there. I recently wrote about this topic in my blog (coincidentally also concerning dijit.Dialog): http://www.hackyourlife.org/?p=28 (FYI: I did end up abandoning my "forked" version of dijit.Dialog and ended up using dojo.extend() and other mucking about with internals). The particular issue with dijit.Dialog isn't the point. Its that I seem to end up extending all dijit's I use in little ways and its starting to worry me the amount of things that will likely break when updating to newer versions. If this is going to be the "officially sanctioned" method of customizing dijit's, then users really need to have their internals officially documented and some kind of promise with regard to when and how these APIs can be broken. Cheers! David Snopek. http://www.hackyourlife.org/ Great article! This sort of extension should be a part of any JavaScript developers personal tool set.

However, doing this sort of extension on someone else’s library (ie. dijit), worries me when it deals with internal implementation details. After all, “titleNode” used in your examples (as far as I know) is not a documented part of dijit.Dialog. You can only know about this by reading the code. When a new version of dijit comes out, it is not guaranteed to be there.

I recently wrote about this topic in my blog (coincidentally also concerning dijit.Dialog):

http://www.hackyourlife.org/?p=28

(FYI: I did end up abandoning my “forked” version of dijit.Dialog and ended up using dojo.extend() and other mucking about with internals).

The particular issue with dijit.Dialog isn’t the point. Its that I seem to end up extending all dijit’s I use in little ways and its starting to worry me the amount of things that will likely break when updating to newer versions.

If this is going to be the “officially sanctioned” method of customizing dijit’s, then users really need to have their internals officially documented and some kind of promise with regard to when and how these APIs can be broken.

Cheers!
David Snopek.

http://www.hackyourlife.org/

]]>