Context for WinJS.UI.processAll()


  • Hello,

    I was wondering why WinJS.UI.processAll() does not accept a context parameter, like WinJS.Binding.processAll() does. It would be very helpful if I could pass a context object that would be used to look up identifiers in data-win-option attributes, so that I do not have to put them into global scope in order to use them for declarative binding.


    Lets say I have a list view that uses a custom item renderer function:

    <div data-win-control="WinJS.UI.ListView" data-win-options="itemTemplate: customItemRenderer"></div>

    Now I'd like to do something like this in my code:

    var createFragment = function () {

    var customItemRenderer = function (itemPromise) { /* ... */ }; var target = document.createElement('div'); WinJS.UI.Fragments.renderCopy('markup.html', target).then(function (element) { WinJS.UI.processAll(element, { customItemRenderer: customItemRenderer }); });


    Unfortunately, I cannot do that. Instead, I have to put customItemRenderer into global scope for WinJS.UI.processAll() to find it.

    Is this a design decision, am I overlooking another way to do it, or is it a missing feature? The interesting things is that when you step into WinJS.UI.processAll() you can see that the WinJS.UI.optionsParser() that is used internally does accept a context object -- it's just called with an empty object.

    // Guido

    • Edited by gdoo Friday, April 27, 2012 9:20 AM
    Friday, April 27, 2012 9:18 AM


All replies

  • Yes, this was intentional. We recommend using namespaces to isolate your control content.

    What is the scenario in which you're running into an issue?

    Friday, April 27, 2012 1:52 PM
  • If I wanted to use a different customItemRenderer function for every instantiation of the fragment, I would have to put all these specialized functions into some namespace -- but then I couldn't use them with the same markup anymore because they would all have different names.

    But I guess I can use data-win-bind and WinJS.Binding.processAll() instead, even though this is really just setting an option once.

    • Edited by gdoo Friday, April 27, 2012 3:04 PM
    Friday, April 27, 2012 3:03 PM