Suggestion for Ember.View.create() + {{view}}

[adyates]

Based on my response to this: http://stackoverflow.com/questions/9094811/ember-nested-applications-and-widgets

Fiddle of the example on the homepage: http://jsfiddle.net/PastryExplosion/LTRt2/

In order to illustrate view hierarchy, the following example is given. Most of the JSFiddles on SO also use this paradigm. But using extend() like this doesn't make sense from an OO standpoint as the description of the View is being intertwined with the data itself. Moreover, the only way to render this is by directly calling the extended class. Why would one render a description directly?

It also seems to conflict with the examples of Ember.ViewState I've seen floating around, which do use Ember.View.create().

The second line in the JSFiddle (and the natural result of designing my models according to the SO post above) is the way I'd prefer to solve this problem. This would be particularly important for times when I have a CollectionView of heterogenous items (e.g. I'm making a dynamic web form and I don't know the input classes until I get the template from an AJAX call), especially when each individual view has a templateName specifically defined.

[guilhermeaiolfi]

I think it should work using an instance too. That would make it easier for debugging, see #366

Currently it's not possible because of this: https://github.com/emberjs/ember.js/blob/master/packages/ember-handlebars/lib/helpers/view.js#L88

And in the viewClassFromHTMLOptions function at the end it would be changed to something like:

if (viewClass.isInstance)
    {
        viewClass.setProperties(options);
        viewClass.setProperties(extensions);
        return viewClass;
    }
    return viewClass.extend(options, extensions);

Those changes are not enough tho.

[adyates]

I appreciate the support, but Issue #366 has no real relation with this at face value. Also, debugging Ember is no different (and at times, way nicer actually) than debugging something built on top of Dojo that is trying to do the same thing.

My issue is that (in my mind) the notion of an instantiated View isn't completely consistent as presented in the documentation and the use cases I find. It could be a misunderstanding on my part of how Ember's MVC framework is structured after coming from a primarily Java background. It could be that what I want to do is embroiled somewhere in the source code and not on the homepage (such as things like Ember.Select, etc.) But then again, it might actually be an inconsistency.

Personally, an instantiated Ember.View makes more sense from the perspective of "I have an Ember View with internal Ember Views to draw". That doesn't seem like a use case where extend() is the natural choice, especially because you can't appendTo()/remove() the internal views since they are not instantiated.

[wagenet]

I don't think we want to support view instances in the {{view}} helper. If you want to insert custom views, you should consider using a ContainerView and setting childViews.

[adyates]

It's less about custom view objects and more about using Handlebars and the associated HTML layout when you're trying to place individually declared childViews to particular divs in the Handlebars template for the root view, since appendTo() isn't immediate.

Like if I were making an image gallery, I would probably have an Ember.View with part of a Handlebars template that looked like:

{{view imageCollection}}
<div id="controls">
   {{view previousImage}}
   {{view nextImage}}
</div>

... with imageCollection being an instance of ContainerView and previousImage and nextImage being an instance of Ember.View, all three having Handlebars templates defined elsewhere.

It seems like I'm thinking about Ember in the wrong way in trying to minimize the amount of global variable binding in my views (I was using Ember.Objects to handle JSON serialization and business logic and view-related handlers to handle jQuery and evented tasks). So I'll dig into the Contacts example a bit more as it's halfway to what I want to do.

[wagenet]

It shouldn't be necessary to use view instances unless you're doing something very unusual. If you'd like to put some stuff together in a jsfiddle maybe I can suggest a better approach.

[adyates]

Alright, I spent some time thinking about it and came up with a better idea of what I wanted to do (By better I mean Ember actually renders it in 0.9.4). I'm mostly trying to figure out what a good way to organize code is for something at production scale. My first pass at this was trying to solve the following scenario:

• I have an object that will be a base model used just about everywhere
• That object knows what it looks like (i.e. the Ember.View to use)
• Handlebars needs to pass responsibility of using the views to the object (ideally without custom helpers), so that way someone versed in HTML but not Ember doesn't need to get too into the models used

My first attempt was instantiating the object, wrapping that object in an instantiation of a view, then trying to place that view directly (That's how I ended up here). Then I decided to invert the wrapping and use the View class as is right in the world.

At the moment, I have this: http://jsfiddle.net/PastryExplosion/99CMD/

It looks okay for what I need to do now. This would probably start to break when the Objects render themselves differently in different Applications/pages, since replacing the view class in the model isn't as fluid as I'd like. Syntactically, that the only thing I don't like is having to specify "content.*" and "displayView" everywhere to get this to work. I'd prefer

       {{view content.info.displayView contentBinding="content.info"}}

to look more like:

       {{view info}}

[guilhermeaiolfi]

For the "content.info" part you can do that:

http://jsfiddle.net/99CMD/4/