(Sencha 1.1, MVC)
Assume there are 4 primary operations in my REST API and I want to provide that functionality in my application:
GetList [View a list]
GetByID [View details about a list item]
DeleteByID [Remove an item]
Upsert [Save new or edit].
Assume GetList only returns a small subset of fields (summary) for each item and there needs to be a call to retrieve the rest of the data when the details view is requested.
What is the right way to structure the model, proxy, and store to accomplish this?
Should there be two models?
Should the store only deal with retrieving the list of items?
Should the model have one proxy (for Upsert, Delete, and Get) and the store have another (for GetList)? Isn't that a little anti-MVC?
If I were building this in a server-side MVC framework, I'd accomplish this by:
* Create 1 model for the detail/edit views, and an array of that model for list view
* Create a controller method for index that would ask the API for a list of data, map the data to the model, and pass that data to the view
* Create a controller method for details that would accept the item ID, then, make an API request & map the response to get the entire model
* Delete would be a link created on the detail (or list) view side by templating a URL with the item's ID
* Controller method to handle that delete, then redirect to the list page.
* Controller method to handle saving, which would package the data from the UI and send it to the upsert API method and then redirect.
The server-side approach effectively doesn't need a 'store' concept, unless you wanted to abstract the API interaction from the controller. But at that point, it's just a wrapper around the API, which I feel is what the proxy is in Sencha.