Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <p>I actually have a root app that takes care of starting up sub-applications, and it passes in the region in which they should display. I also use a custom component based off of <code>Backbone.SubRoute</code> that enables relative routing for sub-applications.</p> <p>check out this gist: <a href="https://gist.github.com/4185418" rel="nofollow">https://gist.github.com/4185418</a></p> <p>You could easily adapt it to send a "config" object for addRegions that defines multiple regions, instead of the <code>region</code> value I'm sending to the sub-applications' <code>start</code> method</p> <p>Keep in mind that whenever you call <code>someRegion.show(view)</code> in Marionette, it's going to first close whatever view is currently being shown in it. If you have two different regions, each defined in its own app, but both of which bind to the same DOM element, the only thing that matters is which region had <code>show</code> called most recently. That's messy, though, because you're not getting the advantages of closing the previous view - unbinding Event Binders, for example.</p> <p>That's why, if I have a sub-app that "inherits" a region from some kind of root app, I usually just pass in the actual region instance from that root app to the sub-app, and save a reference to that region as a property of the sub-app. That way I can still call <code>subApp.regionName.show(view)</code> and it works perfectly - the only thing that might screw up is your event chain if you're trying to bubble events up from your region to your application (as the region will belong to the root app, rather than the sub-app). I get around this issue by almost always using a separate instance of <code>Marionette.EventAggregator</code> to manage events, rather than relying on the built-in capabilities of regions/views/controllers/etc.</p> <p>That said, you can get the best of both worlds - you can pass the region instance into your sub-app, save a reference to it just so you can call "close", then use its <code>regionInstance.el</code> property to define your own region instance pointing to the same element. </p> <pre><code>for(var reg in regions) if regions.hasOwnProperty(reg) { var regionManager = Marionette.Region.buildRegion(regions[reg].el, Marionette.Region); thisApp[reg] = regionManager; } </code></pre> <p>It all depends on what your priorities are.</p>
    singulars
    1. This table or related slice is empty.
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. VO
      singulars
      1. This table or related slice is empty.
    2. VO
      singulars
      1. This table or related slice is empty.
    3. VO
      singulars
      1. This table or related slice is empty.
    1. COlsochronous, darn fine answer. I have a few questions on your gist. 1) Line 43 of Application.root.js: what would that abstraction look like? 2) Line 73 of the same, what is in the initialize:ui method? This is enough of a departure from how I was doing things that part throws me off. 3) In main.js, I assume the array which begins on line 18 is where I'd add further subApps to the entire application? 4) vent.super.js: Line 7 you say it should only be used by the root app. All other apps should use 'EchoVent'. What is EchoVent? Is it anything special or is a standard EventAggregator?
      singulars
    2. COQuick answers first: 3) Yes 4) `EchoVent` is my term for a supervent that is instantiated with a namespace and at least one existing vent instance as parameters. Its initializer binds to the special "all" event and simply "echoes" it out across any vents that have been registered with the echovent, with the provided namespace prepended to the event name. So for example if I had done `var ev = new EchoVent("appName", rootVent)` and then triggered "app:started" on echoVent, it would trigger that event as expected, but also trigger `appName:app:started` on rootVent.
      singulars
    3. CO1) I just created another gist with the answer to this question, because it's a bit long for the comments section here. Here's that link: https://gist.github.com/4439430. Oh, and I forgot to mention that I added the echovent code to the original gist, so if you want to see it, read the gist in my original answer. It's ugly, way over-engineered code though, so please don't judge me ;P
      singulars
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload