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.
Related
I have multiple UI elements on the same page. Each of these elements I divided into Model/View/Controller. They act as modules and most of the functionality is independent to the rest of the page. Controllers deals with user interactions for that specific UI element. Model contains the data and Notifier to update the View if any data changes. Some user actions might require to collect the data from another Model and then I need to trigger another Models View. How can I connect those MVC elements with another MVC elements in the single page?
At the moment, I thought of couple solutions.
Create a big model, instead of having small models and pass it around as a dependency to each Controller. Then notify that specific view.
Create some kind of model to model relationship between two elements, so that state change on one model would affect the other model (Through dependencies, notifications).
Create Controller to Controller relationship between two elements. Maybe something like explained here: https://www.youtube.com/watch?v=w7a79cx3UaY&t=678
I would like to avoid big models and somehow retain independent modules. I am not sure how you can connect multiple MVCs in that matter.
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.
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.
I am fairly new to ExtJS so I was wondering which approach is best for displaying different views of information using one grid. This is what I'm thinking about doing. I have three different data stores that are each utilizing the proxy and returning JSON. Let's call them STORE1, STORE2 and STORE3. I'm using different stores because each one has different parameters that are being executed to be retrieved from the server. Now, I want to include three buttons, each triggering a store to be used to populate the Grid. How exactly do I specify a new store for the Grid to use after it's been instantiated? I don't see a setStore() in the Grid object so I'm not sure how to go about solving my problem. If someone could provide me some insight, that would be much appreciated.
Grid has method bindStore. If you need to also assign different set of columns - check reconfigure method
There are several ways to go about this problem.
The first thing I would do is really think through your use case. Are you sure this is the way you want to handle your user interface? Would it make more sense to filter the data (either by default or by the user interaction). There are several examples of this out there. One that comes to mind is the simple task widget (not that simple) http://docs.sencha.com/ext-js/4-1/#!/example/simple-tasks/index.html - the top right button filter the store based on user selection. It uses one grid + one store .. but filters the data based on user selection.
If you are set on loading data from different stores you can utilize one store to manage the view and other stores to fetch data. On load of the stores that fetch data you use loadData (or loadRecords) method to update the store that controls the view. Makes sense? Watch out for corner cases here though ..what happens if you load the same data twice? Should you use "append" option on the loadData method?
good luck.
I'm currently building an application using Backbone.js with a number of different models that all relate to each other in various ways. I'm currently experimenting with various architectural approaches.
In a nutshell the model relationships looks something like this:
Workspace > Projects > Tasks
There are a few other models, such as lists and categories, that are attached to a project.
On a page with a task list, I'm dumping the JSON of the tasks onto the page and filling up the collection. This works ok, but at the moment all tasks are pulling in their own project data.
task.project.id
task.project.name
The projects are also being pulled in various other locations on the page for various lists. Tasks can also be part of a List which is assigned to a Project. This means I'm also making requests to pull in the lists for a project in various places as well.
The main problem with this is that when updating a model in place I need to find some way to 'sync' them. Which is crazy. They should all be using the same model instance so that each view is using the same model and is updated accordingly without having to do anything.
I've been researching various Backbone.js architectural designs to try and find the answer. Chaplin (https://github.com/moviepilot/chaplin), for example, uses a mediator object to pass data between views. Using this approach, I could have a Projects collection on the mediator and pass this around to the various views via the mediator object.
Each project would include all of it's lists, categories, assigned users etc. Then I could request for a project model like so:
App.Projects.get(12)
Then the task would just need the project ID and a getter and setter method. Views could get access to available projects, project lists, project users easily as well without relying on digging into the model or making further AJAX calls. Additionally, the task models wouldn't require any of the project data on them.
However, dumping all this data in a global object seems bad.
I would possibly end up with something like this:
App.Workspaces
App.Workspaces.get(1)
App.Projects
App.Projects.get(12).get('lists')[0]
App.Projects.get(12).get('users')
To use like this:
var projectId = model.get('project')
var project = App.Projects.get(projectId)
Or with a getter method:
var project = model.getProject()
And add the mediator as a dependency at the model level instead.
Adding a large global object like this adds a fairly large dependency that could make testing difficult. It also seems wrong to assume that the mediator will even have the project available. Maybe it could make the model, fetch it and return it if it doesn't exist.
Any help here would be great! I'd love to know how other people have solved this problem.
I recommend to have a common Collection for all your Task Models. Kind of cache.
Something like: App.Store.Tasks.
Any time you need to feed the Poject.Tasks look first in the App.Store.Tasks and then:
A. If you found the Task there then take it and add it to your Project.Tasks.
B. If not found there then create, fetch and add it to both: App.Store.Tasks and your Project.Tasks.
This way other Project that tries to fetch a Task that already exits will do the same and they both will share the same Model.
Any time you modify one of your Task models in a Project you'll be modifying this Task in every other Project.