Declarative record loading/saving

[Dave Porter]

Tyler just closed a ticket about changing SC.Store behavior to make something more convenient. I agree with the closure in this case, but it touched tangentially on a design problem I've run into before: SC.Record provides plenty of declarative ways to specify interactions between your app and your store, but there isn't really a corresponding way to declaratively describe the interactions between your store and your server. The (developer-unfriendly) expectation is that all such behavior will be hand-coded in your data source.

A really badly basic example is resource URL patterns. If we could specify this on a record class, we could build a default (opinionated but) fully functional data source. Another example is information about the hash that comes back from the server, letting us streamline the process of turning a server response into a bunch of hashes in the store.

Putting that kind of declarative information on SC.Record may be semantically incorrect, but is very convenient and is the approach taken by everybody everywhere else always.

I've been struggling to put this thought into words for a while, so without any particular provocation, here it is. Thoughts?

[Maurits Lamers]

One of the things I did in my Thoth server/client approach and SC is (indeed) declare a basic resource on the model.

While there are many different patterns in server/client traffic, there are a few patterns which are used the most. I am not sure I would like to rig the SC.Record class by default, but I do think it might help if we have a few guides/tutorials/ready-to-use examples which show our opinionated view on how to deal with that pattern with regards to SC.Record and SC.Store. 

Even in case of a different pattern, they could serve as a guide line on how to implement your own, without having to completely reinvent the wheel.

This pattern could (and perhaps even should) include the dependency model (which side is master and which is slave).

--
You received this message because you are subscribed to the Google Groups "SproutCore Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sproutcore-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Dave Porter]

Dependency model should be discussed elsewhere. Briefly: agreed that it's important to actually decide on, and I think we're all pretty much in agreement that the client should behave as the slave (which it currently does not do very well) (yay 2.0).

There aren't many common specific patterns, but I think there are common steps. For example, I could build a decently generic data source given the following components for each record class:

- URL scheme for single record, usable for retrieve/create/update/delete

- optional method for unpacking single-record server response

- optional method for repacking 

- URL scheme for multiple records

- (probably not very) optional method for unpacking multiple-record server responses

Each item is easy to understand, document and demonstrate. Put them together and it wouldn't cover everything by a long shot, but I bet it would cover more cases than you'd expect. (Poke holes! RESTful and REST-ish APIs only plz.)

If I were king of designing that system, I would put those things on the record class, because of how tremendously convenient it is, semantics be damned. Assuming this kind of system, is there a better place to put this record-specific information than on the record class?