基礎上的從直觀的像素轉向我想出了以下解決方案。
我構建了以下網址: http://somedomain.com/#/searchresults/?lastname=king&firstname=stephen&city=somecity
如何網址是池莉構建在此不再贅述的方式。在我的情況下,我用表單和一些事件處理程序使用我自己的視圖。
把我弄得工作看起來像這樣的代碼:
App.Router.map(function() {
this.resource("searchresults", { path: '/searchresults/:dynamic' });
});
App.SearchresultsRoute = Ember.Route.extend((function() {
var deserializeQueryString = function (queryString) {
if(queryString.charAt(0) === "?")
queryString = queryString.substr(1);
var vars = queryString.split('&'),
i = 0, length = vars.length,
outputObj = {};
for (; i < length; i++) {
var pair = vars[i].split('=');
outputObj[decodeURIComponent(pair[0])] = decodeURIComponent(pair[1]);
}
return outputObj;
};
return {
model: function(param) {
var paramObj = deserializeQueryString(param.dynamic);
return App.Searchresult.find(paramObj);
}
};
})()
);
App.Store = DS.Store.extend({
revision: 12,
adapter: DS.RESTAdapter.create({
namespace: 'api'
})
});
App.Searchresult = DS.Model.extend({
lastname: DS.attr('string'),
firstname: DS.attr('string'),
street: DS.attr('string'),
hno: DS.attr('string'),
zip: DS.attr('string'),
city: DS.attr('string'),
country: DS.attr('string'),
birthdate: DS.attr('string')
});
這產生一個HTTP GET請求,我的REST API:
{"searchresults":
[{"id":"2367507","lastname":"King","firstname":"Stephen","street":"Mainstreet.","hno":"21" ...},
{"id":"3222409","lastname":"King","firstname":"Stephen","street":"Broadway","hno":"35" ...}
]}
:
http://somedomain.com/api/searchresults?lastname=king&firstname=stephen&city=somecity
我的REST API與響應
然後用這個模板將其顯示出來:
<h2>Searchresults</h2>
<table>
<thead>
<tr>
<th>Name</th>
<th>Street/Hno</th>
<th>City</th>
<th>Birthyear</th>
</tr>
</thead>
<tbody>
{{#each item in controller}}
<tr>
<td>{{item.firstname}} {{item.lastname}}</td>
<td>{{item.street}} {{item.hno}}</td>
<td>{{item.zip}} {{item.city}}</td>
<td>{{item.birthdate}}</td>
</tr>
{{/each}}
</tbody>
</table>
如果有人發現更優雅的方式,那不需要使用自定義的解串器,我會很樂意更新解決方案。 (另一個)丹尼爾提供的答案暗示http://somedomain.com/#/searchresults/king/stephen/somecity不適合我的情況,因爲在我需要的解決方案中,我有超過10個不同的搜索標準/過濾器。用戶通常只選擇填寫其中的一些。
這個例子上燼數據修訂的基礎:12和灰燼1.0.0-RC.3
這可能會實現。但是,我的實際模型和我的搜索表單比較複雜。用戶可以選擇10個以上的字段(名字,姓名,街道,住宅號碼,出生日期,...)。爲了進行搜索,用戶通常僅爲這些字段中的幾個提供內容。如果我要這樣構造URL,他們總是必須明確地包含所有的標準,即使這些字段中的大部分都是空的:即http:// localhost /#/ searchresults/king/stephen //////// somecity。我不喜歡,這個網址不能「顯示」某個位置代表什麼。即它不可見,那個位置3代表街道。 – Daniel 2013-05-12 11:37:28