I would like to use StrongLoop Loopback as a Node.js backend API for a backbone.js app.
Is there a way to define models attributes and methods (for example, for validation) that can be used both on the client side, in the backbone model, and on the server, in Loopback models definitions ? (Dont Repeat Yourself philosophy)
Loopback uses model definitions to initialize objects
Maybe I can extend Backbone.Model to be able to load the Loopback model definition syntax ?
Do you think it's a good idea / easy task ?
disclosure: I do front-end work for StrongLoop.
It is a good idea since the model definitions are stored as simple json. You can also use the API explorer output to pick up the url path properties as well.
We are just wrapping up a similar thing for AngularJS to auto-gen a model factory you can drop into your client modules and it's pretty slick so hopefully a Backbone version won't be too far behind.
Related
I am coming from models and controller paradigm, where models deals with DB and controllers have the business logic to serve the REST api's.
Now, i am looking into a Loopback(framework based on Node JS) to do new project with it. But, it only have model to do all kind of stuff. I am not able to understand how i can merge service layer and controller layer into models. That sounds me a bit confusing.
If any one can provide the right direction for designing a system with Loopback. That would be very helpful.
When you create a new model, say Profile, you get 2 new files:
profile.js
profile.json
Consider profile.json as your model, actually just a declaration of your model. And consider profile.js as your controller. All RESTful APIs you need are dynamically generated by loopback, if you need to add additional logic to the regular APIs or create new ones, your starting point is profile.js.
Now, you can structure your application code as you like. I usually put all the application business logic into a service layer, having the module profile_service.js and referencing it from profile.js.
at first I've to say that I'm not a frontend guy. ;) But in my leisure time I'm working with JS. Currently I'm working on a single page app which uses require.js and Backbone.js. I really like this both libraries!
To my problem:
I've a backbone collection which gets its information from the backend via the fetch() function. This collection only holds data which will not change. The information will be needed to describe a game unit which is defined in the backend. I need the collection for two backbone views, but it's not necessary to fetch the data again. It would be enough to fetch it once, but since I'm using require.js I've to create a new instance of this object. What is the "right" way to solve this problem? Singleton, global object? And I'll have more collections which only holds data which will not change during over the runtime.
If the collection will never change (i.e. the data on the cleitn won't be changed after being received form the server), simply provide the same collection instance to your various views.
There is a new MVC mechanism built in Enyo 2.3pre but there is absolutely now docs on it.
The question is how can I bind specific controller to my view?
I have a new kind based on enyo.Control e.g. and I have a controller based on kind: 'enyo.ViewController',
In my controller I have handlers object with a function that should handle event.
If I put view prop into controller with a name of my view that doesn't work since
my handler in controller is not invoked
Can you post some examples on this?
So, the enyo.ViewController, by default, wants to renderInto document.body and we use it to define the enyo.Application kind as the "starting point" for your application.
The Enyo implementation is not necessarily "pure" MVC in the sense that you don't necessarily have to have a proper controller for every view (or enyo.Control) that you are dealing with. Enyo has always had a sort of hybrid view/controller system baked into the controls themselves.
With that being said, recent changes to the implementation removed bubbling of events to a "controller" that owned your "view" as it resulted in a lot of unnecessary overhead. In fact, we're removing the "controllers" block from the enyo.Application kind as an app-global reference to various controllers, and instead you will place them in a components block as typical of "traditional" Enyo development.
So, the current thinking is that your view will handle events as before, but you can bind to properties of various "controllers" and models.
Now, you can still create an MVC architecture if you really want to, but the system is flexible enough to support any of the "separation of concerns" methodologies (MVC, MVP, MVVM, etc.)
My current way of going about things is to create a "controller" for doing some things (like make Web service requests) and then build out models from the data I get back, add them to a collection, and then my views probably have a data-aware control (such as enyo.DataRepeater or enyo.DataList) that will automatically generate some rows for each model.
Take a look at this simple example: http://github.com/clinuz/college-football but, be advised it may not be up-to-date with the switch from app-wide controllers to components. And also, we're removing the "controller" property of the DataRepeater/List and it will change to "collection."
Let me know if you need some more hints. We're aware the lack of documentation is making this difficult while we finalize our implementation. Please bear with us!
You could see my example of to checkout enyo MVC structure.
https://github.com/prajnavantha/enyo-internetradio
Basically we have a model, view and controller.
models: In my case is a simple enyo.Model kind. U can have enyo.collections etc...
Controller: i've used enyo.ModelController.
Views: have the kinds:
The application is not totally MVC. Since my logic is still in views. However you can understand, how to set model and use the componenets.
I'm currently building an application using Backbone.js with a number of different models that all relate to each other in various ways. I'm currently experimenting with various architectural approaches.
In a nutshell the model relationships looks something like this:
Workspace > Projects > Tasks
There are a few other models, such as lists and categories, that are attached to a project.
On a page with a task list, I'm dumping the JSON of the tasks onto the page and filling up the collection. This works ok, but at the moment all tasks are pulling in their own project data.
task.project.id
task.project.name
The projects are also being pulled in various other locations on the page for various lists. Tasks can also be part of a List which is assigned to a Project. This means I'm also making requests to pull in the lists for a project in various places as well.
The main problem with this is that when updating a model in place I need to find some way to 'sync' them. Which is crazy. They should all be using the same model instance so that each view is using the same model and is updated accordingly without having to do anything.
I've been researching various Backbone.js architectural designs to try and find the answer. Chaplin (https://github.com/moviepilot/chaplin), for example, uses a mediator object to pass data between views. Using this approach, I could have a Projects collection on the mediator and pass this around to the various views via the mediator object.
Each project would include all of it's lists, categories, assigned users etc. Then I could request for a project model like so:
App.Projects.get(12)
Then the task would just need the project ID and a getter and setter method. Views could get access to available projects, project lists, project users easily as well without relying on digging into the model or making further AJAX calls. Additionally, the task models wouldn't require any of the project data on them.
However, dumping all this data in a global object seems bad.
I would possibly end up with something like this:
App.Workspaces
App.Workspaces.get(1)
App.Projects
App.Projects.get(12).get('lists')[0]
App.Projects.get(12).get('users')
To use like this:
var projectId = model.get('project')
var project = App.Projects.get(projectId)
Or with a getter method:
var project = model.getProject()
And add the mediator as a dependency at the model level instead.
Adding a large global object like this adds a fairly large dependency that could make testing difficult. It also seems wrong to assume that the mediator will even have the project available. Maybe it could make the model, fetch it and return it if it doesn't exist.
Any help here would be great! I'd love to know how other people have solved this problem.
I recommend to have a common Collection for all your Task Models. Kind of cache.
Something like: App.Store.Tasks.
Any time you need to feed the Poject.Tasks look first in the App.Store.Tasks and then:
A. If you found the Task there then take it and add it to your Project.Tasks.
B. If not found there then create, fetch and add it to both: App.Store.Tasks and your Project.Tasks.
This way other Project that tries to fetch a Task that already exits will do the same and they both will share the same Model.
Any time you modify one of your Task models in a Project you'll be modifying this Task in every other Project.
I am performing a lot of JavaScript work in the browser and would like to have some of that backend functionality in the front-end. Specifically, it would be nice to have the functions get(), save(), all() and count() available to the client. Additionally, it would be great to have the field list of the model already available in the generated JavaScript object.
Whether the current user can read or write the records is a separate issue I will deal with using Django's authentication. For the time being, retrieval would be a start.
In short, is there code that would generate a JavaScript model from a Django model?
Thanks.
It sounds like you're looking for a complete JavaScript interface to the model and queryset APIs. I can't imagine that this would have ever been done or even be a simple task. Not only would you need to somehow generate JavaScript instances of models (much more than JSON serialisation provides, since you also want the methods) but you'd need to expose a web service that can handle every kind of DB-API call. I can't even begin to imagine where to start and the security issues may be too numerous to easily overcome.
The alternative (and much simpler) approach would be to use one of the various Django REST modules and JSON serialization. You could perform an AJAX GET request on a resource, which can be identified by a series of query parameters that would be equivalent to chained queryset filters. This would return the JSON representation of the model's values. You can then modify the JavaScript object and use an overloaded AJAX POST request to persist the changes back to the server. You wouldn't have access to the model's methods, so that functionality would have to be reimplemented but making any changes to a model should be straightforward enough - This is basically the JavaScript equivalent of using an HTML form to modify data.
You need a data serializer. You can do it with django built in serializers. It is documented on official django site. djangoproject_topics-serialization
I've started a project that I think does exactly what you're looking for. You can find it at
github_bumby_jslib. It currently only supports get(), but I'm hoping to extend this soon. Feel free to contribute patches :)
jslib is a Django application aiming to simplify AJAX integration with your Django projects.
It sounds like you want to JSON encode your object data. See JSON.org for more on the data format.
So it's been a while since I posted the original question and since then there has been a number of developments in Djangoland. Not least of which is a great little library called Django REST Framework. I will be using it on a new project and it's looking pretty kewl.
http://www.django-rest-framework.org