decouple url/backend stuff

[timoxley]

IMO, backend connectivity is a separate concern to the 'reactive data model' stuff like get, set and validate & change events. Discuss.

[timoxley]

Use Case: my data models are built up from multiple end points, and the backend is not flexible. Assuming the model data is backed by a single restful endpoint is a big pain point for me with Backbone and its ilk… I'm commonly retrofitting a JS frontend onto a backend that wasn't designed for this purpose and is too cumbersome/coupled to other services to change.

Restful persistence could be baked into a "restful-models" plugin so it's easy to swap out for something else such as LocalStorage or a lib that abstracts away the horrible details of the backend API.

[weepy]

+1

[tj]

there's #12, same request. rest should be default without a doubt IMO otherwise it just destroys any conveniences, might as well just use superagent and custom protos at that point, but it would be simple to introduce a function that does all the "routing"

[timoxley]

@visionmedia I'm suggesting having no persistence strategy baked in. Model logic/validation and persistence are entirely separate concerns.

i.e.

Core components:

• Model logic/validation
• Restful Persistence strategy

Amalgam, Convenience Component:

• Model+Restful Persistence = current Model component.

Mainly so you can easily swap out either piece depending on your requirements.

I only mention this as I've never benefit from the 'convenience' of Model+Restful Persistence, simply because my persistence layer is always more complex than a simple 1 rest endpoint per model (this only happens on the most simplest of apps (todo) in my experience), and employs clientside caching etc.

[timoxley]

also possible I'm just building my apps wrong

[weepy]

I agree, the core is about data encapsulation. Persistance is something
else entirely.

On Fri, Nov 23, 2012 at 4:36 AM, Tim Oxley notifications@github.com wrote:

also possible I'm just building my apps wrong

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/19#issuecomment-10649696.

[tj]

sure im not disagreeing that they're separate, I'm just saying this module (even if comprised of others) should be useful, otherwise I wouldn't want to use it haha. This one would be analogous to component/dom, more of an aggregate

[timoxley]

Cool. So I'm thinking the model stuff would work well as a mixin… somewhat similarly to configurable agree?

[weepy]

I think there might be a bit too much to mixin ? - i.e prototype and class methods. Better to mixin the other way around. ..

Maybe it's as simple as having a plugin

[yields]

I agree, the core is about data encapsulation. Persistance is something
else entirely.

+1, i'm building indexeddb component, and i want to create a plugin for model that will handle persistance.
Hopefully if TJ removes all superagent stuff, we can simply do:

var db = require('model-indexeddb')
  , agent = require('model-superagent')
  , model = require('model');

model('User')
  .use(db());

model('Post')
  .use(agent());

[ianstormtaylor]

+1, that would be cool for a local storage implementation we have

[scttnlsn]

How are folks achieving pluggable persistence right now? Are there other, more decoupled model implementations you'd recommend? Or are you just using this module and re-defining the persistence methods?

[ianstormtaylor]

slightly unrelated, ran into an issue with having a url attribute of my person and integration models. would be a nice bonus if the adapter layer removed the url method so that it could be used as an attr, since it's a fairly common one

[yields]

@ianstormtaylor +1

[tj]

@ianstormtaylor yeah we could definitely make that a less common name. I had started moving this to an adapter but I forget what the issue was