Marionette.Application.prototype.stop

[Jason Strimpel]

I am new to Marionette, so maybe there is a reason this function does not already exist, or maybe it does and I am just overlooking it. Maybe it is not even necessary or does not jive with the Marionette design philosophy?

Why is there not a corresponding Marionette.Application.prototype.stop for Marionette.Application.prototype.start? It seems simple to implement:

1. iterate over the application instance properties

2. check for instances of views and regions; if so close

3. check for 'regions' property; iterate over regions; if instance of region then close

4. check for onStop function; if it exists execute function; special application cleanup like onClose for views and regions

5. kill event aggregation and listeners??? (I just delete the application instance in my case)

I created my own stop function because we have a parent application that is composed of many child applications. There are n types of child applications with n instances of child types running. A user can add or remove child applications at their discretion. Having a stop/destroy function is useful for my scenario, so I was wondering if others had the need for such functionality as well.

[Robert Levy]

Is there a reason your child applications are applications instead of modules? https://github.com/derickbailey/backbone.marionette/blob/master/docs/marionette.application.module.md#stopping-modules

--
You received this message because you are subscribed to the Google Groups "Backbone.Marionette" group.
To post to this group, send email to backbone-...@googlegroups.com.
To unsubscribe from this group, send email to backbone-marion...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jason Strimpel]

I am using require.js for modules and dependency management, so I did not think using Marionette modules was really a good approach because of the following sentence in the documentation, "This is useful for creating modular, encapsulated applications that are be split apart in to multiple files.".

Is my assumption incorrect? Are others using  Marionette modules with require.js to create parent, child type applications?

[Jarek Gilewski]

Hi Jason,

I have a discussion about using Marionette.Application.Modules together with RequireJS here:
https://groups.google.com/forum/#!msg/backbone-marionette/we6AWP3uXnY/-nh-1fJFKGMJ

In spite of Derick sentence:

"The purpose of this module definition is to provide a simple alternative to RequireJS / AMD modules, and it is not recommended that you combine AMD and Marionette's modules. This would honestly not provide any value. If you're using AMD / RequireJS, stick with AMD / RequireJS. "

I have not fully agreed with Derick and mixed the Marionette modules with RequireJS modules. The Marionette.Application.Modules has strict connection with Marionette.Application which I want and see no sense to move this functionality to RequireJs modules.

I have committed the full example application here: https://github.com/jagin/todos

Regards

Jarek


W dniu 2012-08-22 23:01, Jason Strimpel pisze:

[Ruben Vreeken]

I suppose one reasoning not to use Marionette's modules might be that AMD / RequireJS tries to encourage a loosely coupled architecture for your application.
Creating modules attached to the application seems tightly coupled to me, while there isn't an explicit need for such a tightly coupled system.

The EventAggregator on the Marionette.Application makes for a perfect Mediator. Essentially, that's all you really need to make individual modules talk to the rest of the system right?

[Derick Bailey]

loosely coupled has nothing to do with namespaces vs independent modules. .NET and Java are all namespaced, but we write decoupled systems in those languages. With JavaScript, it's easy to fall in to the trap of "Oh, I can just call Foo.Bar.baz() directly from this Foo.Quux.Widget code." but that's obviously what we don't want to do. That is definitely tight coupling - not because namespaces exist, but because of how those namespaces are used.

RequireJS forces you to decouple the pieces of your application, to a degree that I'm not comfortable with. Namespacing allows you to shoot yourself in the foot if you want to, but a good design is a good design, and namespaced modules still allow decoupling components correctly.

-- Derick

[Ruben Vreeken]

True, namespacing isn't the same as tight coupling. However, being forced to decouple things, while initially frustrating did eventually change how I thought of designing an application. Probably these ways of thinking about good design aren't anything new for a more seasoned veteran such as yourself, but for me being forced to decouple helped me grow I think.

[Jason Strimpel]

Thanks for the responses. It sounds like my approach is correct for my situation. The modules/child applications are independent pieces that should not have knowledge of the parent. However, based on the responses it seems like my situation is unique and my solution would not benefit the community as whole. Although, it still does not feel right that there is not a corresponding stop method for the start method. It is like having a show method without a hide, an open without a close, etc. While it may not be needed it make the API feel unbalanced.

[Ruben Vreeken]

I'm actually still curious to see what your stop method looks like, if you don't mind. It might be interesting.

[Jason Strimpel]

Completely untested, http://jsfiddle.net/H5w8j/1/

[Ruben Vreeken]

Looks pretty clean to me.

I'm wondering would it be useful to make something where the isClosable method simply checks if the object has a 'close' method.
That way you could close things by convention rather then by checking if they're an instance of a known class.

I say this because I sometimes extend various view classes with extra functionality to create a FormView or a FullCalendarView for instance.
It would seem cleaner to me to close them by convention rather then overloading the stop function on the application.
Then again, maybe triggering a stop event on the application's EventAggregator would be even better for that. (I'm kind of thinking out loud here)

Also, in your multiple decoupled applications situation, how do you handle routing for multiple decoupled applications? Doesn't it cause problems with things like routing or permissions? (should I open a new thread for this?)

-- 

Ruben

[Jason Strimpel]

Good call on just checking for the close method. That is much cleaner and less prone to failure. 

In my app we are not using a router because the application it is portal with porlets. The individual portlets contain their own custom non URL based router. Basically a view triggers a route event and the application handles the routing/rendering. Permissions are handle by the back end.

[Ruben Vreeken]

So you have no way to get your application in a certain state based on say, a url fragment?

[Jason Strimpel]

Correct. SEO is not a concern.