-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Geppetto and Marionette.AppRouter #5
Comments
|
I asked this questions on stackoverflow: http://stackoverflow.com/questions/13731124/understanding-backbone-geppetto |
What is mediator in your model ? |
@zerkalica : Thanks for the questions and sorry about the delay in my response. I'll respond to your questions individually as best I can.
Geppetto doesn't have anything to do with routing, so you should be able to use AppRouter any way you like. Were you having a specific issue?
If the view and sub-view (layout and view) are part of the same logical area, then I prefer them to actually share the same context. Just pass the context object in the options map of your view's constructor function. Then set it from the options to the view instance in the view's In your layout: onRender: function()
Backbone.Marionette.Geppetto.bindContext( {
view: this,
context: MyContext
} );
this.context.listen(this, "someImportantEvent", this.handleSomeImportantEvent);
var mySubView = new SubView({
context: this.context
});
this.someRegion.show(mySubView);
},
handleSomeImportantEvent: function() {
// do something
} In your view: initialize: function() {
this.context = this.options.context;
},
handleSomeAction: function() {
this.context.dispatch("someImportantEvent", {foo: "bar", abc: "123"});
} Now the sub-view can dispatch events to its own context, and the parent listens for them, without either the layout or the view directly talking to each other. Now if your sub-view needs to listen to events on the shared context, this was previously problematic. If your view was destroyed, the event binding it created would still live on, and create memory leaks and zombie views. I fixed this in Geppetto v0.3 by requiring calls to
The above example kind of covers that, and v0.3 of Geppetto allows you to share one Context to many views, without introducing memory leaks. Generally, if several views are all part of one piece of UI functionality (especially something that would be reused in a few places as one cohesive unit) then it makes sense to have one Context shared between them all.
To tell the truth, I am starting to think I introduced them to support the notion of having one global "shell" view in your app, with its own context. And this shell would handle application-wide events like navigation, alerts, etc. Every child-view would get passed a reference to I think the above example is better served by using a global namespace for your app (or faking one using RequireJS's "paths" configuration) and storing the reference to the global shell context there. dispatchGlobally doesn't really serve much of a purpose besides the contrived example in the widget app. So I think I may get rid of these.
You are absolutely right. You don't need Geppetto or the Context object to have event-driven communication. What Geppetto gives you is the ability to have those events automatically cleaned up when the view that
The context should not contain any logic. It should only contain command mappings. Your backbone view should contain only logic for manipulating that view, and listening for interaction events like clicks from the user. If the view needs to communicate with another part of the app (like requesting some data, or being notified when something happens somewhere else) then the view would listen or dispatch events on its context (or perhaps a context on a global namespace like I described above).
The mediator is a part of the "View". I prefer to make the distinction between the "True View" (the HTML and the DOM) and the "View Mediator" which is the Backbone JS code which is sort of "glued" to your View, listening for DOM events, manipulating the DOM, etc. It's a small distinction but I think it's important because it's confusing to have a JS component called the "View" when the DOM is really the true view. It's just semantics. I also describe the mediator in the docs. I hope this helps! Please let me know what your experience is like using Geppetto and if there's anything else that could be improved. |
@zerkalica : Sorry for the delay in responding. Yes, the docs and examples need more updates. I'm currently working on a port of TodoMVC to Geppetto which I hope will show some more real-world use cases. Like most open source authors, I'm working on this in my spare time, of which there isn't much. :) Anyway, I'm not sure if you still need these answers now that it's a month later, but I'll respond just in case.
You're right; it's weird that the command knows about the view. Ideally, the parent view would create the child view, not the command. This is a bad example that I wrote early on in the development of Geppetto.
Good catch. See my answer in #7 where I address this very same question. Bottom line is that the Context is a great place to store data that is shared between views.
Models should be initialized in the Context. Child views should be initialized in their parent views/layouts. These are great questions, and I thank you for asking. Sorry again for the late response. On my list of things to do is also to add a FAQ to the docs, and your questions will be great for that. I'm going to close this for now, since it's not really an "issue" per-se. I think it would be good to move this discussion to the mailing list if there's anything else to follow up on. |
Ok, models shared in context, child views in parent views, event bus per context, but what about command? Why do you need the command, if domain logic incapsulated in backend and our views only process events from user and other views ? Most common scenario: user click to UserSearchView (parent widget), each row in search table renders UserSearchItemView, enter search criteria, find user, click them and go to UserView (child widget) and UserEditForm We have user model and collection, UserSearchView and UserSearchItemView in same context. UserSearchItemView listen click event and redispatch user:selected event to context, sends to parent view. UserSearchView listens user:selected event and pass selected UserModel to UserView options. Why we do not need the command in this scenario ? |
How to use them together ? I can't find it in your example.
The text was updated successfully, but these errors were encountered: