I built a tree consisting of a set of collections. Each collection is in turn made of other sub-collections and so on.
Every collection has the same field (which is the one I want to update).
Is there a way to update every level of the tree with the same value (in order to initialize it)?
Some images of the tree's structure:
You can use batched writes to perform multiple individual writes at once, but there is no way to update a field across a collection of documents in a way similar to e.g. an UPDATE in SQL databases.
You would need to enumerate each document that needs to be updated and perform an update on each of those documents.
In flux based applications there is a concept called a store. I've been trying to determine what features a store has and how they differ from models? Does server communication happen in a store? Where does that occur? Are they always singletons?
Stores are domain models, not ORM models.
They manage application state for a logical domain. They can manage state using collections, single values or a combination of both.
But they have a number of specific features that set them apart from normal models:
They have no setters. No one changes the stores from the outside.
The only way data gets into stores is through the callback they register with the dispatcher. They receive every action that goes through the system through this callback. They define which actions they will respond to, ignoring most of them.
The only methods they publicly expose are a set of getters and methods to register/unregister listeners.
When the state they manage changes, they emit a change event. This alerts the view layer that the state of the store has changed, so the views can query for the new data they need, using the getters.
They can call for new data, but when that data is returned it should be in the form of a new action so that all the stores may respond to it. Doing this ensures the resiliency of the application -- you always have all new data throughout the entire system.
Some people prefer to call for new data in the action creators, rather than the stores, which enforces that the new data will originate with an action. This is perfectly acceptable and actually is more common, I believe. But really either style is fine.
When rendering a Backbone.View you generally pass it the current state of the model model.toJSON() and maybe a few extra properties. This is a synchronous task.
How do you deal with attributes on the model which require async tasks like an id of another model which needs to be fetched from the server (eg person_id)
Do you resolve and attach the person attributes in to the models attributes before sync and render or do you render the view and listen to the person fetch event to re-render that part of the view after?
NB. I am using Backbone.Marionette so am a little limited to changing the render method
The answer is: it depends :-)
Depending on circumstances, you either:
fetch the model from the server, then display the view
update the model that is already displayed
Usually if you're displaying "new" data (i.e. the whole model needs to be fetched), I would display a loading view while the data is being fetched, then display the new view (and data) when it has been fetched (see https://github.com/davidsulc/marionette-gentle-introduction/blob/master/assets/js/apps/contacts/show/show_controller.js)
But in other cases (e.g. the user returns to a list of "you might also like" product, such as on Amazon), you can display the data you have on hand, fetch "fresh" data, and rerender the view.
All in all, it really depends on the user experience you want to provide.
I'm a bit confused with the fetch on collections,
the way i see it now, semantically fetch would go get all available models from the server
but sometimes you need only the top 5 or you want to show the items per 10 (paging for example)
example:
Movie = Backbone.Model.extend({
idAttribute: "Id"
});
MovieList = Backbone.Collection.extend({
model: Movie,
url: "/api/movies"
});
$(function(){
movies = new MovieList();
movies.fetch(); // simplified example, i know best practice is not to fetch on document ready...
});
this show's a model called movie, in a movielist collection, calling movies.fetch(); goes to the url beeing /movies which is build in asp.net mvc3 and - simplified for this example - basicly returns all movies in the database.
now, lets say I create a dashboard view that - among other things - is supposed to show the 10 most recent movies
do i need to go do a fetch again but somehow pass in i only want the top 10?
or, do i need to work with 1 collection of all movies through the whole lifetime of my application? and just query the collection instead?
if i would to the latter, and use 1 collection trough the entire app, how do i keep it up to date? other users might have added movies in the meantime, without going so far as using sockets for real time visualisation.
the more i think about it the more idea's i get where not the full collection is used, so either querying the server and getting only the necessary or getting it all once and querying the collection would be the actuall question.
I haven't done this yet, but am considering it too. If keeping 1 collection I would probably set up a movies-changes service that returns command objects indicating new movies, modifications, and deletions. Long poll this service with a "since=<timestamp>" parameter to get the changes since the last time you checked, and use the response to update the collection. That should fire change events so views know to update.
I've been trying to learn to work with Models and Stores. But the proxy bit is confusing me a lot. So I'm going to list out my understanding here - please point out the gaps in my understanding.
My understanding
Models are used to represent domain objects.
Models can be created by ModelManager, or by simply using the constructor
Models are saved in Stores
Stores may be in memory stores, or can be server stores. This is configured using Proxy.
Proxy tells the store how to talk to a backing store - be that a JSON array, or a REST resource, or a simply configured URL via ajax.
Stores are responsible for storing models, and Proxies are responsible for controlling/helping with that task.
When a model's values are changed, its dirty flag gets set. It gets automatically cleared when the model is saved. (more in this later)
The part that confuses me
Why is there a proxy config and save method on Model? I understand that models can only be stored on to stores.
Why is the dirty flag not cleared simply when I add a model object to a store?
When I add a model object to a store, why does the model not acquire the proxy configured with that store?
proxy is a static configuration for a Model. Does that mean that we cannot use objects of a particular model with multiple data sources? By extension, does this mean having multiple stores for a single model essentially useless?
When we define a Store, are we defining a class (store-type, if we may call it that), or is it an instance of a store? Reason I ask is when we declare a grid, we simply pass it a store config as store: 'MyApp.store.MyStore' - does the grid instantiate a grid of that type, or is it simply using the store we've already instantiated?
Thanks!
PS: +50 bounty to the person who explains all this :) - will offer bounty after those 48 hours are over..
The docs say:
A Model represents some object that your application manages.
A Store is just a collection of Model instances - usually loaded from a server somewhere.
Models are saved in Stores
Not only. The Models can be used separately (f.i. for populating forms with data. Check out Ext.form.Panel.loadRecord for more info).
Why is there a proxy config and save method on Model? I understand that models can only be stored on to stores.
As I've said, not only.
Why is the dirty flag not cleared simply when I add a model object to a store?
Why should it? The Record becomes clean only when it gets synchronized with the corresponding record on the server side.
When I add a model object to a store, why does the model not acquire the proxy configured with that store?
This is, again, because model can be used without store.
proxy is a static configuration for a Model. Does that mean that we cannot use objects of a particular model with multiple data sources?
We cannot use objects of a particular model but we can use one model definition for multiple store. For example:
Ext.define('MyModel', {
// ... config
});
var store1 = Ext.create('Ext.data.Store', {
model: 'MyModel',
// ... config
proxy: {
// ...
// this proxy will be used when store1.sync() and store1.load() are called
}
// ...
});
// ...
var storeN = Ext.create('Ext.data.Store', {
model: 'MyModel',
// ... config
proxy: {
// ...
// this proxy will be used when storeN.sync() and storeN.load() are called
}
// ...
});
Since store1 and storeN use different proxies, the records, contained by these stores, may be completely different.
When we define a Store, are we defining a class (store-type, if we may call it that), or is it an instance of a store?
Yes, when we define a Store, we are defining a class.
Reason I ask is when we declare a grid, we simply pass it a store config as store: 'MyApp.store.MyStore' - does the grid instantiate a grid of that type, or is it simply using the store we've already instantiated?
There are couple of ways to set store config for grid:
store: existingStore,
store: 'someStoresId',
store: 'MyApp.store.MyStore',
In the first and the second cases existing instances of stores would be used. In the third case newly created instance of 'MyApp.store.MyStore' would be used. So, store: 'MyApp.store.MyStore', is equal to
var myStore = Ext.create('MyApp.store.MyStore', {});
// ...
// the following - is in a grid's config:
store: myStore,
UPDATE
When a model is added to store and then the store's sync() is called, why is the model's dirty flag not cleared?
It should be cleared, unless reader, writer and server response are not set up properly. Check out writer example. There is dirty flag being cleared automaticaly on store's sync().
if a model class is not given any proxy at all, why does it track its dirty status?
To let you know if the record was changed since the creation moment.
What is achieved by introducing the concept of Models syncing themselves to the server?
Let's assume you are creating a widget which contains plain set of inputs. The values for this inputs can be loaded from db (this set of inputs represents one row in db table). And when user changes the inputs' values data should be sent to the server. This data can be stored in one record.
So what would you use for this interface: one record or a store with only one record?
Standalone model - is for widgets that represent one row in db table.
Store - is for widgets that represent set of rows in db table.
I'm coming from ExtJS 2.2 [sic] to 4, and the Model behavior and terminology threw me for a loop too.
The best quick explanation I can find is from this post in the "Countdown to ExtJS 4" series on Sencha's blog. Turns out a Model acts like it does because it's "really" a Record.
The centerpiece of the data package is Ext.data.Model. A Model
represents some type of data in an application - for example an
e-commerce app might have models for Users, Products and Orders. At
its simplest a Model is just a set of fields and their data. Anyone
familiar with Ext JS 3 will have used Ext.data.Record, which was the
precursor to Ext.data.Model.
Here's the confusing part: A Model is both a model for the data you're using and a single instance of an object following that model. Let's call its two uses "Model qua model" and "Model qua Record".
This is why its load method requires a unique id (full stop). Model qua Record uses that id to create RESTful URLs for retrieving (and saving, etc) a single Record worth of data. The RESTful URL convention is described here and is linked to in this post on Sencha's blog that talks specifically about Model usage.
Here are a few RESTful URLs formed to that standard to get you familiar with the format, which it appears ExtJS' Model does use:
Operate on a Record with id of 1
GET /people/1 <<< That's what's used to retrieve a single record into Model
return the first record with id of 2
DELETE /people/2
destroy the first record with id of 7
POST /people/7?_method=DELETE
Etc etc.
This is also why Models have their own proxies, so that they can run RESTful operations via that URL modified to follow the conventions described in that link. You might pull 100s of records from one URL, which you'd use as your Store's proxy source, but when you want to save what's in the single Model (again, think "Model qua Record" here), you might perform those Record-specific operations through another URL whose backend messes with one record at a time.
So When Do I use Stores?
To store more than one instance of that Model, you'd slap them into a Store. You add lots of Models qua Records into Stores and then access those "Models" to pull data out. So if you have a grid you'll naturally want to have all that data locally, without having to re-query the server for each row's display.
From the first post:
Models are typically used with a Store, which is basically a
collection of Model instances.
And, of course, the Stores apparently pull info from Model qua Model here to know what they're carrying.
I found it in the documentation of sencha App Architecture Part 2
Use proxies for models:
It is generally good practice to do this as it allows you to load and
save instances of this model without needing a store. Also, when
multiple stores use this same model, you don’t have to redefine your
proxy on each one of them.
Use proxies for stores:
In Ext JS 4, multiple stores can use the same data model, even if the
stores will load their data from different sources. In our example,
the Station model will be used by the SearchResults and the Stations
store, both loading the data from a different location. One returns
search results, the other returns the user’s favorite stations. To
achieve this, one of our stores will need to override the proxy
defined on the model.