Views

[creynders]

So, I've been using v0.7 pretty intensely now and I have some issues with how views are set up. Everything works, but ... yeah, there's some stuff I don't like:

1/ I tend to create one context (per module) and bind several views to it. This means I need to call bindContext manually for each of these views.

2/ Since views are injected as "classes", not instances, I have a bunch of these: var loginView = new this.LoginView(). It makes my :eyes: bleed.

3/ The above mentioned breaking of API symmetry really makes me a sad :panda_face:

So now I'm trying to come up with a different approach. Maybe we should add a getViewFactory method and auto-inject viewNameFactory wirings. E.g.:

//wiring it together
resolver.wireView('LoginView', LoginView);

//usage in SomeView
wiring : ['loginViewFactory']
render : function(){
  var loginView = this.loginViewFactory({
    foo : "bar"
  });
}

The injected factory method would simply create an instance of the view (passing along some options) and bind the context to it.

Personally I'd drop allowing the retrieval of a view class through getObject entirely.

What do you think?

[creynders]

Hmmm, I've been staring at the bindContext method some more and notice a few things:

• I shouldn't use it if I want to have one context with multiple views, since when the view gets closed the context gets destroyed (no idea why that hasn't bitten me in the ass yet!!)
• The only reason for me to use bindContext is to have the contextEvents parsed. I think it needs to be moved out of that method. It's beneficial to be called for all resolved objects, no?

[geekdave]

Hey @creynders : I haven't had a chance to fully wrap my head around all this yet, but some initial thoughts:

• I intended bindContext to be called on a single parent view.
• If multiple sibling views need to share the same context, I'll often just create a parent container view to use for context binding.
• views are injected as "classes", not instances : That's by design, admittedly with MarionetteJS in mind. Marionette has the notion of "Layout" views which act as containers that can swap out child views in certain regions of the page. Marionette handles the instantiation, however, so you need to pass a constructor and not an instance. I'd be open to breaking this into different behaviors to support both injection as a view instance & injection as a view constructor.

Will try to review this in more detail soon... just wanted to get these thoughts down, and see if I'm thinking in the right direction :)

[creynders]

Probably we have quite a different approach to views. Anyway, there's two things here:

1/ contextEvents parsing seems to me it should happen for all wirings. Here's an example where I use bindContext on a controller simply to get the contextEvents parsed.

(BTW: The project I'm referring to is an OSS project I'm currently working on and it uses Geppetto. It's nowhere near completion and thus in heavy flux, but some day you can use it as a real world example on how to use Geppetto if you want.)

I'll extract this into its own issue #57 .

2/ Here's an example on how I use views and how they were setup

I didn't know this:

Marionette handles the instantiation, however, so you need to pass a constructor and not an instance.

And don't seem to find any documentation on it. All examples I've seen manually construct the view instance.

Anyway, I think it's best that I simply sketch out what I have in mind and turn this issue into a PR, so we can discuss the benefits, pitfalls, etc in more concrete detail.

[geekdave]

Marionette handles the instantiation

And don't seem to find any documentation on it.

Here's one example: http://marionettejs.com/docs/marionette.collectionview.html#collectionview's-getchildview

In this case, a Marionette CollectionView needs to create multiple instances of a child ItemView so we pass the view constructor function. But even without Marionette, you can imagine a case where a parent view needs to render multiple instances of a child view, and therefore we want to control the instantiation logic ourselves within the parent view.

Perhaps there are cases where we know that we only need a single instance of a child view within a parent view, and therefore we could have a different syntax for telling Geppetto to handle the instantiation? But having a mixture of both could be confusing. If you can think of an elegant way around this, which still handles the multiple children within a parent view, I'm all ears!

I'll take a look at #57 for the other issue.

[creynders]

a Marionette CollectionView needs to create multiple instances of a child ItemView so we pass the view constructor function.

Ah yes, collection views do need the constructor functions. Ok, anything else I can come up with is just jumping through hoops to avoid a minor ugliness. Closing this.

[creynders]

@geekdave I realized there is a way to solve this. Auto-instantiation. I.e. we add the auto instantiation code to a view's constructor (which we're wrapping anyway) and it allows the injected views to be used both as a factory AND as a constructor function. E.g. var subview = new this.SubView() and var subview = this.subView()

[geekdave]

Looks promising, @creynders . Sorry for being incommunicado for a while. Busy week. Will get to this and the other PRs soon.

[creynders]

@geekdave no probs. I've got some time this evening, will try this out and fix the double line mmikeyy mentioned.