blocks|key|819522|text|是。您可以覆盖集合上的parse函数(我将使用javascript而不是coffeescript，因为这是我所知道的，但映射应该很简单)：|type|unstyled|depth|inlineStyleRanges|offset|length|style|CODE|entityRanges|data|819523|LogbookCollection+=+Backbone.Collection.extend({
++++model:+Logbook,
++++url:+"/api/logbooks",
++++parse:+function(response){
++++++var+self+=+this;
++++++_.each(response,+function(logbook){
++++++++++switch(logbook.type){
+++++++++++++case+"ULM":
+++++++++++++++self.add(new+UmlLogBook(logbook);
+++++++++++++++break;
+++++++++++++case+"Plane":
+++++++++++++++...
++++++++++}
++++++}
++++}
+});|code-block|syntax|javascript|819524|希望这能有所帮助。|819525|entityMap^0|B|5|0|0|0^^$0|@$1|2|3|4|5|6|7|O|8|@$9|P|A|Q|B|C]]|D|@]|E|$]]|$1|F|3|G|5|H|7|R|8|@]|D|@]|E|$I|J]]|$1|K|3|L|5|6|7|S|8|@]|D|@]|E|$]]|$1|M|3|-4|5|6|7|T|8|@]|D|@]|E|$]]]|N|$]]

Yes. You can override the <code>parse</code> function on the collection (I'm gonna use javascript instead of coffeescript, because it's what I know, but the mapping should be easy):

<pre><code>LogbookCollection = Backbone.Collection.extend({
 model: Logbook,
 url: "/api/logbooks",
 parse: function(response){
 var self = this;
 _.each(response, function(logbook){
 switch(logbook.type){
 case "ULM":
 self.add(new UmlLogBook(logbook);
 break;
 case "Plane":
 ...
 }
 }
 }
 });
</code></pre>

Hope this helps.

blocks|key|604454|text|确实有。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|604455|当你在一个集合上调用'fetch‘时，它会在将其添加到集合之前通过Backbone.Collection.parse传递响应。|604456|“parse”的默认实现只是按原样传递响应，但您可以覆盖它以返回要添加到集合中的模型列表：|604457|class+Logbooks+extends+Backbone.Collection

++model:+Logbook

++url:+'api/logbooks'

++parse:+(resp,+xhr)+->
++++_(resp).map+(attrs)+->
++++++switch+attrs.type
++++++++when+'UML'+then+new+UmlLogbook+attrs
++++++++when+'Plane'+then+new+PLaneLogbook+attrs|code-block|syntax|javascript|604458|编辑:哇，idbentley比我早到了。唯一的区别是他使用了'each‘，而我使用了'map’。这两种方法都可以工作，但不同。|604459|使用'each‘有效地打破了'fetch’调用启动的链条(通过返回'undefined‘--随后对'reset’(或'add')的调用将不做任何事情)，并在解析函数中执行所有处理。|604460|使用'map‘只是将属性列表转换为模型列表，并将其传递回已在运动的链。|604461|不同的笔划。|604462|再次编辑:刚刚意识到还有另一种方法：|604463|集合上的'+model‘属性存在只是为了让集合知道如何在'add’、'create‘或'reset’中传递属性时创建一个新模型。所以你可以这样做：|604464|class+Logbooks+extends+Backbone.Collection

++model:+(attrs,+options)+->
++++switch+attrs.type
++++++when+'UML'+then+new+UmlLogbook+attrs,+options
++++++when+'Plane'+then+new+PLaneLogbook+attrs,+options
++++++#+should+probably+add+an+'else'+here+so+there's+a+default+if,
++++++#+say,+no+attrs+are+provided+to+a+Logbooks.create+call

++url:+'api/logbooks'|604465|这样做的好处是，集合现在将知道如何为“fetch”以外的操作“转换”日志的正确子类。|604466|entityMap^0|0|0|0|0|0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|12|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|13|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|14|8|@]|9|@]|A|$]]|$1|F|3|G|5|H|7|15|8|@]|9|@]|A|$I|J]]|$1|K|3|L|5|6|7|16|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|17|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|18|8|@]|9|@]|A|$]]|$1|Q|3|R|5|6|7|19|8|@]|9|@]|A|$]]|$1|S|3|T|5|6|7|1A|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1B|8|@]|9|@]|A|$]]|$1|W|3|X|5|H|7|1C|8|@]|9|@]|A|$I|J]]|$1|Y|3|Z|5|6|7|1D|8|@]|9|@]|A|$]]|$1|10|3|-4|5|6|7|1E|8|@]|9|@]|A|$]]]|11|$]]

There is indeed.

When you call 'fetch' on a collection, it passes the response through Backbone.Collection.parse before adding it to the collection. 

The default implementation of 'parse' just passes the response through, as is, but you can override it to return a list of models to be added to the collection:

<pre><code>class Logbooks extends Backbone.Collection

 model: Logbook

 url: 'api/logbooks'

 parse: (resp, xhr) -&gt;
 _(resp).map (attrs) -&gt;
 switch attrs.type
 when 'UML' then new UmlLogbook attrs
 when 'Plane' then new PLaneLogbook attrs
</code></pre>

EDIT: whoa, idbentley got there before me. the only difference being he used 'each' and I used 'map'. Both will work, but differently.

Using 'each' effectively breaks the chain that the 'fetch' call started (by returning 'undefined' - the subsequent call to 'reset' (or 'add') therefore will do nothing) and does all the processing right there in the parse function.

Using 'map' just transforms the list of attributes into a list of models and passes it back to the chain already in motion.

Different strokes.

EDIT AGAIN: just realized there's also another way to do this:

The 'model' attribute on a collection is there only so the collection knows how to make a new model if it's passed attributes in 'add', 'create' or 'reset'. So you could do something like:

<pre><code>class Logbooks extends Backbone.Collection

 model: (attrs, options) -&gt;
 switch attrs.type
 when 'UML' then new UmlLogbook attrs, options
 when 'Plane' then new PLaneLogbook attrs, options
 # should probably add an 'else' here so there's a default if,
 # say, no attrs are provided to a Logbooks.create call

 url: 'api/logbooks'
</code></pre>

The advantage of this is that the collection will now know how to 'cast' the right subclass of Logbook for operations other than 'fetch'.

blocks|key|819651|text|也许使用eval不好，但这是更具ruby风格的方式(coffeescript)：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|819652|++parse:+(resp)->
++++_(resp).map+(attrs)+->
++++++eval("new+App.Models.#{attrs.type}(attrs)")|code-block|syntax|javascript|819653|因此您不需要编写很多switch/case，只需在JSON中设置type属性即可。它可以很好地与rails%2Bcitier或其他多表继承解决方案配合使用。您可以添加新的子体，而无需将其添加到案例中。|819654|根据你的模型类，你可以在其他你需要很多开关/案例的地方使用这样的结构。|819655|entityMap^0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|N|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|O|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|P|8|@]|9|@]|A|$]]|$1|K|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|L|$]]

Maybe it's bad to use eval, but this is much more ruby-style way (coffeescript):

<pre><code> parse: (resp)-&gt;
 _(resp).map (attrs) -&gt;
 eval("new App.Models.#{attrs.type}(attrs)")
</code></pre>

So you don't need to write a lot of switch/cases, just set type attribute in your JSON. It works very good with rails+citier or other multitable inheritance solution. You can add new descendants without adding them to your cases.

And you can use such constructions in other places where you need a lot of switch/cases depending on your model class.

blocks|key|604574|text|从backbone+0.9.1开始，我已经开始使用esa-matti+suuronen的pull-request中描述的方法：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|604575|https://github.com/documentcloud/backbone/pull/1148|offset|length|604576|应用补丁后，您的集合将如下所示：|604577|LogbookCollection+=+Backbone.Collection.extend({

++++model:+Logbook,

++++createModel:+function+(attrs,+options)+{
++++++++if+(attrs.type+===+"UML")+{+//+i'am+assuming+ULM+was+a+typo
++++++++++++return+new+UmlLogbook(attrs,+options);
++++++++}+else+if+(attrs.type+===+"Plane")+{
++++++++++++return+new+Plane(attrs,+options);
++++++++}+else+{
++++++++++++return+new+Logbook(attrs,+options);
++++++++++++//+or+throw+an+error+on+an+unrecognized+type
++++++++++++//+throw+new+Error("Bad+type:+"+%2B+attrs.type);
++++++++}
++++}

});|code-block|syntax|javascript|604578|我相信这是合适的，因为您使用的是STI+(所有型号都有唯一的i)|604579|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|1F|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|V|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|W|8|@]|9|@$D|X|E|Y|1|Z]]|A|$]]|$1|F|3|G|5|6|7|10|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|11|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|12|8|@]|9|@]|A|$]]|$1|O|3|-4|5|6|7|13|8|@]|9|@]|A|$]]]|P|$Q|$5|R|S|T|A|$U|C]]]]

as of backbone 0.9.1, i've started using the method described in esa-matti suuronen's pull-request:

<a href="https://github.com/documentcloud/backbone/pull/1148" rel="nofollow">https://github.com/documentcloud/backbone/pull/1148</a>

after applying the patch, your collection would be something like this:

<pre><code>LogbookCollection = Backbone.Collection.extend({

 model: Logbook,

 createModel: function (attrs, options) {
 if (attrs.type === "UML") { // i'am assuming ULM was a typo
 return new UmlLogbook(attrs, options);
 } else if (attrs.type === "Plane") {
 return new Plane(attrs, options);
 } else {
 return new Logbook(attrs, options);
 // or throw an error on an unrecognized type
 // throw new Error("Bad type: " + attrs.type);
 }
 }

});
</code></pre>

i believe this would fit since you're using STI (all models have unique ids)

I have a REST Json API that returns a list "logbooks". There are many types of logbooks that implement different but similar behavior. The server side implementation of this on the Database layer is a sort of Single Table Inheritance, so each JSON representation of a logbook contains its "type" :

<pre><code>[
 {"type": "ULM", "name": "My uml logbook", ... , specific_uml_logbook_attr: ...},
 {"type": "Plane", "name": "My plane logbook", ... , specific_plane_logbook_attr: ...}
]
</code></pre>

I would like to replicate this server model on the client side, so I have a base <code>Logbook</code> class and multiple logbook sub classes :

<pre><code>class Logbook extends Backbone.Model

class UmlLogbook extends Logbook

class PlaneLogbook extends Logbook

...
</code></pre>

My <code>Backbone.Collection</code> is a set of <code>Logbook</code> models that i use to query the JSON API :

<pre><code>class LogbookCollection extends Backbone.Collection
 model: Logbook
 url: "/api/logbooks"
</code></pre>

When I fetch the logbook collection, is there a way to cast each <code>Logbook</code> to its corresponding sub class (based on the JSON "type" attribute) ?

A Backbone.js Collection of multiple Model subclasses

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我有一个REST Json API，它返回一个列表“logbook”。有许多类型的日志实现了不同但相似的行为。这在数据库层的服务器端实现是一种单表继承，因此日志的每个JSON表示都包含它的“类型”：[  {"type": "ULM", "name": "My uml logbook", ... , specific_u...

问多个模型子类的Backbone.js集合
EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问多个模型子类的Backbone.js集合EN

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问多个模型子类的Backbone.js集合
EN