Asked by:
BUG: WinJS.Namespace.define() treats input and button element objects as descriptors

Question
-
WinJS.Namespace.define() treats any member with a value property as a descriptor. This isn't that big of a deal, especially for custom objects, but it does require a work around for some HTML element objects. Examples:
// assuming element with submitID is an input or button element
// work around 1 WinJS.Namespace.define("ui", { submit : null }); ui.submit = document.getElementById("submitID"); // work around 2 WinJS.Namespace.define("ui", { dom : { submit : document.getElementById("submitID") } });
These approaches work, but they're not ideal.
- Edited by jmcpeak Sunday, January 27, 2013 7:50 PM
Sunday, January 27, 2013 7:41 PM
All replies
-
Hi jmcpeak,The WinJS.Namespace.define helps us expose some custom object(with properties) to global scope so that we can access it from multiple js files and pages (used in the same windows store js app). As for the issue you mentioned, would you also provide some code to repro the problem you mentioned (the code you provided only show the two cases which it work).
BTW, for including html DOM element or control instance as custom object member, the "building custom WinJS" example has demonstrated how we can define a custom WinJS control through WinJS.Class.define. And we generally use the constructor of the custom WinJS class to associate the HTML DOM element (on page or created dynamically) with the custom object properties.
#Building a custom control using the Windows Library for JavaScript (WinJS)
http://blogs.msdn.com/b/windowsappdev/archive/2012/10/11/building-a-custom-control-using-the-windows-library-for-javascript-winjs.aspxPlease remember to mark the replies as answers if they help and unmark them if they provide no help.
Wednesday, January 30, 2013 10:29 AMModerator -
Howdy, Steven. Aye, I can provide code to reproduce the issue. My apologies for not doing so in the original post:
// assuming element with submitID is an input or button element WinJS.Namespace.define("ui", { submit : document.getElementById("submitID") });
typeof ui.submit === "string"; // true, but incorrect
The issue is caused by initializeProperties() in base.js. It checks if the provided member, submit in the example above, has any of the object descriptor properties (value, get, set), and if so, assumes the member is a property descriptor object. From base.js:
if (member.value !== undefined || typeof member.get === 'function' || typeof member.set === 'function') {
Ideally, it should take known object types into account. For example (base.js):
// add check for HTMLElement if (member && typeof member === 'object' && !(member instanceof HTMLElement)) { if (member.value !== undefined || typeof member.get === 'function' || typeof member.set === 'function') { } }
Note: I haven't tested this code, and it more than likely doesn't cover all known objects (although elements would be covered).
- Edited by jmcpeak Saturday, February 2, 2013 10:30 PM
Saturday, February 2, 2013 10:29 PM -
Resurrecting this thread after poking around WinJS 2.0 in the Visual Studio 2013 preview. WinJS 2.0 still exhibits this behavior.Tuesday, July 9, 2013 8:28 PM