Comments on: Mucking Dijit

By: Sanmao的幸福(?)生活 » Blog Archive » 扩展标准的 Dijit 控件

Sanmao的幸福(?)生活 » Blog Archive » 扩展标准的 Dijit 控件 — Mon, 01 Feb 2010 21:28:46 +0000

[...] 参考资料：Mucking Dijit [...]

By: pegli

pegli — Tue, 10 Feb 2009 00:56:22 +0000

Great article! This was just what I needed to solve my problem, which I’ll describe here in case anyone else runs into the same issue. I am working on an app that pulls JSON data from a server and puts it into a form for editing. The dijit.form.Form class has a handy method that does exactly this called setValues(obj) which iterates over the properties of obj and calls setValue on the form widget whose name matches the name of the object property. This worked great for string and numeric properties of my object, but some of the fields in the object to be edited are dates. JSON doesn’t specify a notation for date objects — all dates are encoded as strings in some (hopefully) parsable format. I wanted to put the dates into dijit.form.DateTextBox form widgets, naturally, but when Form.setValues(obj) called DateTextBox.setValue() with a string, I got an error.

The solution was to subclass DateTextBox as follows:

dojo.require(”dijit.form.DateTextBox”);
dojo.declare(”my.dijit.form.DateTextBox”, dijit.form.DateTextBox, {
setValue: function(value, /*Boolean?*/ priorityChange, /*String?*/ formattedValue) {
value = new Date(value);
this.inherited(arguments);
}
});

What isn’t mentioned in your article is that it is possible to change argument values before calling this.inherited(arguments). I can’t say that I looked into this in detail, but resetting “value” to a Date object worked fine and the proper date was displayed in the form.

Thanks again!

By: Hack Your Life » Blog Archive » Memorati revamp live! (and dijit.Dialog update)

Tue, 04 Mar 2008 00:49:38 +0000

[...] 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

dsnopek — Mon, 25 Feb 2008 20:00:18 +0000

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/