It’s been 3 months since you last replied, is there any update on this? What’s the Github issue #?

Thanks,
Henry

The combination of the “show” event/method and “DOMRefresh” event/method were supposed to be the “silver bullet” for this… I probably broke something when doing some of the code cleanup that I’ve done in the last few releases.

What version of Marionette are you using? I’ll copy all of this text in to an issue on the Github project page and dig in to it as soon as I can. I’m travelling today, so I won’t be able to get to this right away, though.

Thanks for digging in to this further and for building that fiddle!

On first read, this article (and the marionette doco) seems to imply that onShow() is the sliver bullet callback that tells you when your view has been inserted into the DOM.

Unfortunately this is only true if the parent view is in the DOM at the time it calls region.show(childview). To be fair, after re-read armed with what I now know, Derick does hint at this in the section “Context Is Still King”.

The problem manifests when the parent isn’t in the dom, as would be the case when rendering multiply nested views, and as this fiddle illustrates:

http://jsfiddle.net/h8436/7/

The only solution I can come up with is to manually have whatever the root view is, trigger a custom ‘now-in-dom’ event on its children, that each in turn propegates to each of their children, eventually reaching the final child view so that it can go do it’s DOM-dependent thing.

However this still doesn’t work for arbitrary levels of nesting. If a re-render occured not on the root node, but at say 2 levels down with the child view at another 3 levels down, a separate and different event would have to be triggered by the re-rendered view, and to which the child view would have to also listen for.

I can’t (yet) see a way for this to happen with arbitrary nesting levels and views being agnostic to the requirements of others higher up or lower down the chain. Any ideas?

Marionette’s onShow() method doesn’t seem to be smart enough to cater for deeply nested views. I’m dealing with a situation, where the view that needs to do dom-dependent work is contained within a layout, contained within other views (including another layout).

Attempting to do dom-dependent work in the view’s onShow runs into same problem as if I did it in the view’s onRender.

Reviewing the call stack, I can see that the view’s onShow is being called from the parent layout’s onRender. This suggests that onShow doesn’t necessarily guarantee the view is in the dom if the parent layout is not at the root of the view tree.

Is that right, or am I doing something bonkers? Is there a way I can acheive what I need within marionette without having to implement my own “really-on-show” mechanism for deep nesting?

Appreciate your work with Marionette – so much better than working with Backbone alone! Cheers.

This post is the closest thing I have to a Backbone + Kendo post, so far. I’m using the two together pretty regularly at this point, though. The ideas that I talk about in this post apply to Kendo pretty well, which is why I included Kendo in some of the examples here.

I’ve only briefly read a little bit about Kendo’s MVVM… I’m not sure what to think, yet. I have a lot of reservations about things that I don’t know enough about yet. I’m “cautiously optimistic” would be the best answer at this point. :)

Love your stuff on Backbone. I’m looking at doing a mobile app with Backbone and jQuery Mobile or Kendo UI Mobile. Have you (or will you) posted any samples of Kendo and Backbone together?

Also, any thoughts about Backbone vs Kendo’s MMVM support?

Thanks,
Eric

nearly every modal dialog system takes the DOM element that you hand it, removes it from the DOM and places it somewhere else – either in memory, or in a special holding area of the DOM that’s been hidden from the user.

when this happens – when the view’s “el” is removed from the DOM, you lose all of your declared events on the view, and things don’t work anymore.

the solution is not to call the dialog directly against the view. use an intermediate object (similar to the RegionManager I talk about) that represents the dialog, and then have it show the view’s content in that.

var Dialog = {
  el: “#dialogDiv”,
  show: function(view){
    view.render();
    var $el = $(el);
    $el.html(view.el);    
    $el.dialog();
  }
}

by doing this, it’s the “#dialogDiv” that gets moved around in the DOM when you call the $.dialog method instead of the view’s “el”, so you don’t lose your view’s declared events.