2013-03-28 13 views
0

我已经定义了以下Ember.View模板传递到Ember.View:如何从属性

App.ControlGroup = Ember.View.extend 
    classNames: ['control-group'] 
    layoutName: 'controlGroup' 

对于其布局模板(controlGroup.handlebars)看起来是这样的:

<label class="control-label">{{ view.label }}</label> 
<div class="controls"> 
    {{ yield }} 
</div> 

下面是一个使用上述定义的视图的示例:

{{#view App.ControlGroup label="Property code"}} 
    {{#if isNew}} 
     {{view Em.TextField valueBinding="code"}} 
    {{else}} 
     <p>{{code}}</p> 
    {{/if}} 
    {{/view}} 

这将产生下面的HTML:

<div id="ember10170" class="ember-view control-group"> 
    <label class="control-label">Property code</label> 
    <div class="controls"> 
    <input id="ember10172" class="ember-view ember-text-field" type="text"> 
    </div> 
</div> 

这正是我想要的。但是,我了解到,在模板中使用视图的属性(请参见上面的{{ view.label }},在controlGroup.handlebars中}})是一种反模式,并且该属性查找应该来自视图的控制器。所以我想知道如何去做。在这种情况下,该属性与视图(html片段)本身有关,所以我的实现似乎对我来说合法,但我很好奇看到其他方法。

回答

1

我不认为使用视图属性本身就是一个坏习惯,只是人们倾向于过度使用Ember的这种能力。作为模型,控制器,观点有不同的生命周期,“做什么去哪里”的问题可以分解为如下:

  • 模式可持久数据,将生存页面刷新。
  • 控制器非持久数据,将无法存活页面刷新,但无视视图重新呈现。
  • 观看次数不时被破坏,例如。在{{#if}}助手内。

我认为这3个组件的行为意味着在哪里放置任何给定的属性。
(另外,我觉得你的例子是完全有组织的,我很乐意听到的理由,如果我错了):)

编辑:在label财产的情况下,这几乎是如何,例如,value属性在类似Ember.TextField的核心类中实现。使用{{view}}帮助程序时可以给它一个值:{{view Ember.TextField value="foo"}}),也可以通过声明它为绑定:{{view Ember.TextField valueBinding="foo"}}来将其转发给控制器。后者将使用控制器上名为foo的属性。

+0

很好的方式来看待关注的分离。关于在模板中使用视图属性的问题,我没有看到它如何被滥用或被认为是滥用。如您所说,它也用于内置的Ember视图,例如Ember.Select模板包含{{view.prompt}}。 – 2013-03-28 10:49:07

+0

其中一种过度使用是在视图上声明一个'fullName'计算属性,该属性连接模型的'firstName'和'lastName'属性。它肯定应该在控制器上声明。这很好地符合问题的分离:它是与模型相关的属性,但不应该被持久化。是的,在视图上定义'fullName'在技术上是可行的,但它确实不属于此处。我认为强调保持视图不含模型相关的东西也是因为视图曾经是财产查询和行为的默认目标。 – zeppelin 2013-03-28 11:13:01

+0

这使得总体感觉。有趣的是,你提到fullName应该在控制器上声明,因为这是[指南中给出的计算模型属性的典型示例](http://emberjs.com/guides/object-model/computed-properties/)。重要的是,我现在很确定我在模板中正确使用了view属性,并没有引入反模式。谢谢。 – 2013-03-28 14:17:47

相关问题