Random thoughts
Here are some tips I have found for building Sproutcore applications.
Just because you can make your data source REST doesn’t mean it’s a good idea. I usually send more than just basic information to my data sources. So I usually make the data source accept only post requests and simply send the information in the payload. Since get and some other verbs do not accept payloads, I find that it’s easiest just to make post request so that I can rely on consistant information accessed in in a consistant way.
The documentation states that remote queries are rare. Don’t feel that you should avoid them. While it is true that you can make “toMany” attributes on a model, and they are very useful, it is sometimes more beneficial to make a computed property that performs a remote query. This is particularly true if the attribute will not be used 100% of the time.
When deciding which attributes belong in a model and what types (toMany/remote query) they should be, keep in mind that you may want to reuse your models and in administration application. It is a good idea to create a framework that can be shared between your main application and your administration application. This framework would contain your data models, the base data source, and any custom views. Since my applications are strongly tied to a login, I put a base login controller in the shared framework as well.
My typical pattern when making a remote query is to simply return a list of IDs. The objects will be requested from the data source if they are not already available. While the retrieveRecords method of a store/dataSource is supposed to allow you to request multiple records at one time, it is usually only called with one ID at a time. I create a hash containing a store/model pairs that contain a list of IDs to request. When a request is made for a record, I add that ID to the hash and set a timer for a very short time (10 ms). The timer is reset if another record is requested. When the timer elapses, the actual request is made to the data source for all the records at one time. This cuts down on the amount of roundtrips to the server. And while it is true that a request for a single record will be slower, in the average case, where you are requesting more than one record, it should be faster.
Keep your database normalized, but feel free to de-normalize your models. Suppose for instance that you have a code table, that contains an ID at text name and possibly other data. If you normalize your model, you will begin to find timing errors in your application. The name will not show up in lists when you think it should. And you’ll wind up chasing your tail trying to get everything to load correctly when it is far simpler to simply create redundant name attributes in the models that would use your code table and supply them from the data source using a join.
