sproutcore如何实现多态?
我正在开发一个涉及类型层次结构的应用程序,并首先通过继承为每种类型定义模型。当谈到编写相应的控制器时,我不确定如何以干净的方式处理整个事情。我应该只为能够处理派生模型的基本类型编写一个控制器,还是应该为每个子类型编写一个控制器?应该如何设置视图控制器绑定才能与不同的控制器一起工作?
I am developing an application that involves a type hierarchy and started by defining the models for each type via inheritance. When it comes to writing the corresponding controllers I am not sure how to approach the whole thing in a clean way. Should I write only one controller for the base type that is able to handle derived models or should there be one controller for each subtype? How should the view-controller bindings be set up to work with the different controllers?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(4)
您可能想查看 SproutCore 新的实验性多态性支持:http://groups .google.com/group/sproutcore-dev/browse_thread/thread/b63483ab66333d15
You might want to check out SproutCore's new experimental polymorphism support: http://groups.google.com/group/sproutcore-dev/browse_thread/thread/b63483ab66333d15
以下是有关定义子类以及重写属性和方法的一些信息:
http://wiki.sproutcore.com/w/page/12412971/Runtime-Objects 。
从我对 Sproutcore 的(有限)使用来看,我只能将 1 个视图绑定到 1 个控制器。
因此,如果您计划使用单个视图(例如 ListView)来显示数据,那么我认为您只能将该视图绑定到 1 个控制器。这意味着能够处理派生模型的 1 基本类型似乎是正确的选择。
Here's some information on defining sub-classes and overriding properties and methods:
http://wiki.sproutcore.com/w/page/12412971/Runtime-Objects.
From my (limited) use of Sproutcore, I've only been able to bind 1 view to 1 controller.
As such, if you are planning to use a single view (e.g. ListView) to display your data, then I think you will only be able to bind that view to 1 controller. This means the 1 base type that is able to handle derived models seems to be the way to go.
通常,您使用 App.store.find 调用的结果填充 ArrayController 实例的内容。 SC.Store#find 可以采用 SC.Query 实例,通常如下所示:
这应该返回 MyApp.MyModel 的所有实例,包括 MyApp.MyModel 子类的任何实例。
SC.Query.local 的第一个参数可以是 SC.Record 子类或引用该子类的字符串。因此,如果您有一些中间 SC.Record 子类,您可能想尝试在那里使用它们。
Typically you populate the content of ArrayController instances with the results of App.store.find calls. SC.Store#find can take an SC.Query instance, which typically looks like:
This should return all instances of MyApp.MyModel, including any instances of MyApp.MyModel's subclasses.
The first argument to SC.Query.local can either be an SC.Record subclass or a string referring to the subclass. So if you've got some intermediary SC.Record subclasses, you might want to try using them there.
在处理模型的单个实例时,控制器应该只是对象的代理。换句话说,ObjectController 可以代理任何东西。这就是我在代码中的意思:
您有两个对象:Person 和 Student。
然后,您需要定义控制器:
请注意,只有当人/学生是选择的结果或绑定触发的其他流程时,您才会将控制器的内容绑定到某些内容。换句话说,如果您手动设置人员(例如从状态图中,作为交互的结果),您仍然可以定义控制器,但会
根据人员是否是“顶级”来以不同的方式设置控制器应用程序中的对象,或某些被选择的中间对象。另外,您可能只需要一个控制器,如果您同时对一个人和一个学生进行操作,则只会有一个 StudentController 和一个 personController。两者都只是对象控制器,并且它们可以代理任何东西。
您将相关的视图元素绑定到控制器:
……
最后,在您的视图中,
请注意,单向绑定是如果视图上的名称不会更改,如果视图可以更改名称,那么只需进行正常绑定即可。还要注意这里的路径。我没有绑定到
因为 personController 代理对象,所以您绑定到
如果您在控制器中放入大量业务逻辑,那么您就做错了。控制器应该只用于代理对象(至少 ObjectController 应该是)。业务逻辑应该在模型本身上,决策逻辑应该在状态图中。
Controllers should just be proxies for objects, when dealing with single instances of your model. In other words, ObjectController can proxy anything. Here is what I mean in code:
You have two objects, Person and Student.
You then want to define controllers:
note that you would only bind the controller's content to something if the person/student is a result of a selection, or some other flow where bindings fire. In other words, if you set the person manually (say from a statechart, as the result of an interaction), you would still define the controller but would do
You set up the controller differently depending on whether the Person is a 'top level' object in your app, or some intermediate object that gets selected. Also, you might only need one controller, you would only have a studentController and a personController if you were acting on a person and a student at the same time. Both are just ObjectControllers, and those can proxy anything.
Finally, in your view you would bind the relevant view element to the controller:
...
...
note that the oneway binding is if the name is not going to be changed on the view, if the view can change the name, then just do a normal binding. Also note the path here. I am not binding to
Since the personController proxies the object, you bind to the
If you are putting a lot of business logic in your controller, you are doing it wrong. Controllers should just be for proxying objects (at least ObjectControllers should be). Business logic should be on the models themselves, and decision making logic should be in statecharts.