Open timoxley opened 11 years ago
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.
+1
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"
@visionmedia I'm suggesting having no persistence strategy baked in. Model logic/validation and persistence are entirely separate concerns.
i.e.
Core components:
Amalgam, Convenience 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.
also possible I'm just building my apps wrong
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/component/model/issues/19#issuecomment-10649696.
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
Cool. So I'm thinking the model stuff would work well as a mixin… somewhat similarly to configurable agree?
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
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());
+1, that would be cool for a local storage implementation we have
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?
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
@ianstormtaylor +1
@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
Anyone sharing these models server side? A mongo adapter could be fun...
@yields thanks for the heads up, look awesome! Is API compatibility with component/model a goal of the project? Are plugins interchangable?
slug and timestamps seem useful client and server.
the api's are similiar, there are still some gotchas we are working on, like .on('change:name')
in modella is .on('change name')
in this project.
you also have stuff like.
User.configure('server', function(){});
User.configure('browser', function(){});
IMO, backend connectivity is a separate concern to the 'reactive data model' stuff like
get
,set
andvalidate
&change
events. Discuss.