While creating Backbone Models and Collections for a web page, I feel the data can be segregated as models and collections in multiple ways.
Consider an example where I have a web page and ideally I should create one backbone view and there by one backbone model for that view. However, the data has to go in to two different data base tables at server side. In these kind of situations, I get confused whether I should just consider the front end scenario while defining view/models or should I just create them based up on the server side POJO classes structure.
I mean, If I just think from front end perspective, I just need to create one backbone view and one model. However, if I think from server side Object's perspective, I need to create two backbone views and two models.
Could someone please tell me what are the things to be considered while dividing a page as different backbone views and models and kindly provide any references
This depends on your REST API.
Backbone does not directly interact with backend tables, it usually uses a REST API that interacts with the tables (or whatever data storage).
If the API has endpoints for performing CRUD operations directly on a table, then you should create a backbone model client side representing it, and use it's built in methods such as save(), destroy() etc to interact with the REST API.
If your rest API returns data which is the result of joins of multiple tables, has single end points that updates multiple tables on backend, then it makes sense to have a model containing data from all those tables, and interact with the REST API using built in methods which updates all these tables accordingly.
So in short, you should create the frontend models according to the REST API, not directly according to the database structure.
Related
I am coming from models and controller paradigm, where models deals with DB and controllers have the business logic to serve the REST api's.
Now, i am looking into a Loopback(framework based on Node JS) to do new project with it. But, it only have model to do all kind of stuff. I am not able to understand how i can merge service layer and controller layer into models. That sounds me a bit confusing.
If any one can provide the right direction for designing a system with Loopback. That would be very helpful.
When you create a new model, say Profile, you get 2 new files:
profile.js
profile.json
Consider profile.json as your model, actually just a declaration of your model. And consider profile.js as your controller. All RESTful APIs you need are dynamically generated by loopback, if you need to add additional logic to the regular APIs or create new ones, your starting point is profile.js.
Now, you can structure your application code as you like. I usually put all the application business logic into a service layer, having the module profile_service.js and referencing it from profile.js.
I'm still trying to wrap my head around frontend state. Is there a common best practice for setting up stores for a resource? For example, my web api has:
GET /bikes
GET /bikes/:id
I started off with just a BikeStore and bikes: []. Now I'm working on the ShowBike component and not sure if I should use the BikeStore (not exactly sure how) or make a second store for single items.
The store concept in Flux is rather simple abstraction on the client how you get access to the data. Separate stores should be used for different kinds of data. In your case the resource is the same, there is not any good reason to keep separate stores for bikes. Even more: stores for single items is not an intended usage and should be avoided.
From the flux docs:
Stores contain the application state and logic. Their role is somewhat similar to a model in a traditional MVC, but they manage the state of many objects — they do not represent a single record of data like ORM models do. Nor are they the same as Backbone's collections. More than simply managing a collection of ORM-style objects, stores manage the application state for a particular domain within the application.
at first I've to say that I'm not a frontend guy. ;) But in my leisure time I'm working with JS. Currently I'm working on a single page app which uses require.js and Backbone.js. I really like this both libraries!
To my problem:
I've a backbone collection which gets its information from the backend via the fetch() function. This collection only holds data which will not change. The information will be needed to describe a game unit which is defined in the backend. I need the collection for two backbone views, but it's not necessary to fetch the data again. It would be enough to fetch it once, but since I'm using require.js I've to create a new instance of this object. What is the "right" way to solve this problem? Singleton, global object? And I'll have more collections which only holds data which will not change during over the runtime.
If the collection will never change (i.e. the data on the cleitn won't be changed after being received form the server), simply provide the same collection instance to your various views.
I want to call two web services from one store and want to bind them with a listview in sencha touch.
For example, I have two web services which are as follows:
1. Company
comp_id
comp_name
emp_id
2. Employee
emp_id
emp_name
Both of the services have different urls and I have to use these services separately as I don't have control over a customer's database.
So now I want to create one or two models & one store for these two webservices, so that I can simply bind it with the lisview and show it in sencha touch.
But the issue is that store has a proxy which can fire only one request at a time. How can I aggregate it in a model and display it in a list view ?
Disclaimer: You shouldn't do it this way. It just doesn't make sense. Models, stores, and dataviews are meant to operate a certain way. By breaking this concept too often you will only be kicking yourself later on when things get more complex.
With that said, I still understand the reasoning and here are some ideas I recommend:
-Normalize the model and dataview templates (use only one model with generic field names). Don't use the store proxies to call the API, instead just do independent Ajax/JsonP requests asynchronously, map the results to the normalized model fields, and add model records to the store. This allows you to add the data from one or more sources as needed, independent of each other.
-Add logic to the proxy on beforerequest. When loading the store, pass custom arguments and handle them in this logic to switch URLs. Then handle results on requestcomplete to set them to the relevant models. You still are faced with the issue though that really one model = one store.
-Consider doing something like the above, except use store associations. One model can be the associated model and you can use the provided relations functions for templating.
Background
I have this structure from a restful api:
/channels/
/channel/{channelId}/
/channel/{channelId}/programs
In my backbone.js I have a collection Channels and two models, Channel and Program.
Problem
How can I easily fetch a nested model structure, and call a render function in my ProgramGuideView when all content is loaded?
What I have so far
So far I'm able to fetch the channels, but I don't come up with any good way to fetch the programs for each channel.
Take a look into this:
http://documentcloud.github.com/backbone/#FAQ-nested
This is a very simple approach for having nested models and collections, but can be tuned to support any of your needs. If you need more sophisticated relational management then you should consider using a plugin like this:
https://github.com/PaulUithol/Backbone-relational