I would like to use ember-data in a project I am building, but the API I am working with does not follow REST conventions.
For example, all the HTTP requests are POST and the naming conventions of the endpoints are unique to the actions they perform. e.g. /api/thing/retrieve would require me to post a JSON object with some parameters, and would return a 'thing' to me.
Do I use the Restful adapter and reopen the class and redefine the various find functions?
OR
Do I have to make a new adapter?
OR
Should I just abandon ember-data and and use ajax in my models(or maybe even controllers)?
I'm not sure how I would handle any of those options. Any guidance would be appreciated.
The only information which I have seen on this subject has been an article by the Discourse folks linked below.
http://eviltrout.com/2013/03/23/ember-without-data.html
I personally have toyed around with the reopenClass method in the article, and would probably drop it into a mixin or something to that effect if I had a consistent but non-REST API which I was calling regularly.
I would say that, if your API is consistent (reliable) then you should create/extend the DS.Adapter (not DS.RESTAdapter) to implement to your specification.
All the hooks are there, you will just end up defining it once which all models can use.
I would also read through the Basic Adapter code - (https://github.com/emberjs/data/blob/master/packages/ember-data/lib/adapters/basic_adapter.js) it might be a better staring point for you then DS.Adapter.
If your API is not reliable, then you are probably better off with just using the $.ajax() calls as necessary. But, in my opinion, that does not scale well.
A link worth reading when looking at Basic Adapter: http://emberjs.com/blog/2013/03/22/stabilizing-ember-data.html
One last note, building an ORM or even a something more simple then an ORM is not a trivial task, that for me, makes using ember-data worth the effort, and yes sometimes pain.
Related
In my recent project I'd like to try out an Aurelia-frontend with a Django-backend.
I did some projects with Django and want to use Django REST API for my backend.
I'm new to Aurelia and read the documentation several times.
Now I'm wondering if it would be good practice to explicitly define models (eg. User with nickname, email, mobile, address etc.) in the Aurelia-frontend because in Django I already defined my models in the models.py for the database. Since I fetch/ the data via api to my Django application I could maybe omit it.
In the Aurelia "getting started"-section of the documentation they defined the ToDo-model in a separate file, but the data wasn't attached to a database. Doing this seems to me like doing it twice (in back- and frontend) and violates the DRY principle.
What would you think is good practice? Thanks for your recommendations!
Defining classes on the client side has its advantages. First, you can map the response data into a class instance, and work with the data that way. Though, working with a JSON object isn’t tough.
Second, serializing a class into JSON is easy. Plus, some backend frameworks expect a very specifically formatted JSON object; sometimes a class is the only practical way of doing that.
Third, one thing you can do with a class that you cannot do with a JSON object (as far as I know) is add methods/functions. That extensibility alone can be worth the effort.
It certainly isn’t unusual to have classes defined on the back and front end. I have worked with Aurelia, and Angular, they both work nicely with them. I have done an Aurelia app without client side classes. What I really missed there was no Intellisense (a fourth advantage) in the IDE since nothing was exported/imported. BTW, I use VS Code.
DRY is nice. But, showing intent can go a long way, especially if someone else picks up the code when you are done with it. Classes can help there. Fifth advantage, helps to show intent.
Finally, I am sure there are many more advantages.
Conclusion: I would recommend using client side classes. You will not regret it.
Hope this helps!
I'm new to web development, but have recently been getting going with it pretty fast, using Django (which I'm falling in love with). However, while Django is easy to get going with and pick up quite fast, I'm afraid there are concepts I don't know much about, particularly REST and RESTful web services. I hear those terms thrown around a lot, and I'm assuming are important to modern web apps, and I want to know basically what they mean, when I should use them, and how I should use them (package, plugin, etc.).
My web app consists of the following functionality:
Discussion Board which I've implemented so far only using the model layer
Messaging which I've implemented so far only using the model layer
Payments (not yet implemented)
Calendar (not yet implemented)
And that's about it for now. When should I be thinking about REST within these functionalities?
You could get really in depth with the subject, but when I think of it, I think of the URLs your site will be providing. That, for me at least, is the simple way to think of a RESTful service. I also think it's a good way to get to grips with Django & it's generic views.
Taken your example there of a calendar. A RESTful approach to a calendar app, with django's generic views, might implement URLs like;
# ListView
/calendar
# DetailView for a given item in the calendar
/calendar/<id>
# UpdateView for an item
/calendar/<id>/update
# DeleteView for an item
/calendar/<id>/delete
Beyond that, REST requires you consider the HTTP methods in use, so you should then define what methods your URLs will accept in order to better control the interaction. Furthermore, if you were enforcing the HTTP method on each action, you could write a more generic view which didn't expose the /update or /delete URLs. But I'd consider that a more advanced approach & you may wish to start from a more explicit design.
Once you start to write a consistent structure for your apps then you can easily make generic functions, and expand.
There is a whole load of things you could read on this subject, depending on where you see it going.
If you're thinking of building something that can provide an API then there's already a Django framework for this; http://www.django-rest-framework.org/
But if you're getting started & just want to know more about the concepts, Wikipedia is always a good place to look, and finally this looks like a great example for this subject using Django which should hopefully help you on your way.
To understand the idea of a resource, take a look at this answer
This is more of an exploration question.
We have been using breeze.js in our projects for a while and have been quite satisfied with it; it ties nicely into concepts we already know and use (change tracking, metadata, backend agnostic...)
Now we are evaluating the possibility to move our front-end from backbone/marionette/knockout stack to ember.js (which seems to be more of a complete framework than a "pick-only-what-you-need" approach in backbone). We are exploring to possibility to keep using breeze.js as our data management layer on the client-front.
But how can the integration of models returned from the server (server stack: node.js + mongoDB) be done with models defined by ember.js?
A typical ember model definition could be:
var Person = Ember.Object.extend({
Property1: 'foo',
Property2: 'bar'
});
where you can see the extension "Ember.Object.extend"
Breeze.js upon receiving data from server attach a AspectEntity to them (and if Knockout is defined, wrap properties in observables ). How could returned objects somehow be "transformed" into ember.js objects?
Maybe the way we approach this problem and the way we think about this integration is totally wrong or that we should entirely reject this "ember-breeze" combo. From google search we have not found cases where breeze is used with ember.js or some guidance. That is why we come to the stackoverflow community: is it possible? what are the possible pitfalls to look ahead?
There does not seem to be much in the way of existing solutions. The Breeze.js User Voice has some 2-year-old issues that never got much traction; support from that library does not seem to be imminent.
I would recommend exploring Ember-Data as your data management layer. It supports many (if not all) of the concepts you mentioned, and it's the default recommended data library for Ember applications.
That said, as far as trying to make Breeze.js work, you could probably take the objects returned from Breeze and turn them into Ember.Objects using Ember.Object.create, but you'd have to build a layer between Breeze and Ember that essentially serializes between Breeze objects and Ember objects in both directions.
The Django orbit integration methods I've seen in quick google searches don't seem to carry Django abstractions, like "request.user" with them. "request.user" is particularly important, since I am not going to (potentially incorrectly) re-implement session handling (this sounds like it could cause bad security bugs).
Alternatively, should I use a different server? I'd prefer to use stable, mature, popular software, that will be maintained and improved. Orbit and Django seem to be qualified.
If you're looking to "integrate Django and Orbited", you might have a look here: http://github.com/clemesha/hotdot which is a very complete (but not yet polished) example of what I think you are looking for.
In particular, the example includes Authentication using Django models from the Orbited process (more specifically, Twisted Cred + Django models), as well as filtering and modifying of in-transit Orbited messages. In the example you'll find that you basically get the "request.user" object because the "request.user" object can be accessed by the cookie that Django sets + database calls using django.contrib.sessions.models.Session model object.
Do you fire ajax requests through the MVC framework of choice, or directly to the CFC?
I'm leaning towards bypassing the MVC, since I need no 'View' from the ajax request.
What are the pro's of routing ajax calls through MVC framework, like Coldbox?
update: found this page http://ortus.svnrepository.com/coldbox/trac.cgi/wiki/cbAjaxHints but I am still trying the wrap my mind around what benefits it brings over the complexity it introduces...
Henry, I make my Ajax requests to proxy objects of my model. Typically, I am outside of a 'framework' when doing so. That being said, it may be (very) necessary to utilize your framework, such as working within a set security model.
I can't really see any benefit of bypassing the MVC framework - in combination, those three elements are your application.
Your ajax elements are really part of the view. As Luca says, the view outputs the results of the model and controller.
Look at it this way - if you made an iPhone-friendly web interface (that is, a new View), would you bypass the model and controller?
Luis Majano, creator of ColdBox said:
These are the two schools of ajax
interaction henry.
I prefer the proxy approach because it
adds the following:
Debugging
Tracing in the debugger
AOP interception points
Security
Setting availability
The proxy will relay to the event model, so I can use local interception
points, local AOP, plugins, etc.
In other words, it can be a highly
monitored call instead of a simple
service cfc call, which you can still
do.
I, for one, love to have my execution
profiler running (part of the coldbox
debugger), so I can see when ajax
requests come in and when they come
out. I can see the data requested and
the data sent back. I don't have to
look in log files, or try to imagine
results or problems. It really helps
out in debugging.
However, it would be a developer
choice in which way you decide to go.
My personal preference is to always
use my proxy to event delegation
because it gives me much more
flexibility, debugging and peace of
mind.
The purpose of the "view" in MVC frameworks is to show the data after the "model" and "controller" have generated it. If you don't need the "view", then what's the point of using such a design pattern?
I agree with Luca. It also bypasses any kind of sanitization and filtering logic you have in your MC stack. It basically negates any kind of query processing that you may or may not have in place.
Yeah, I wouldn't bypass your framework, figure out what's causing you grief and hunt down the offending pieces, adding logic to exclude common components such as headers or footers, and looking for methods injecting whitespace that while fine for html is annoying or down right problematic when parsing json.
Adding output="false" especially in your application.cfc and it's methods would be the first thing I cleaned up.
I am a strong believer in NEVER directly accessing the CFC's directly, I find it creates long term problems when a major refactor might want to consolidate or eliminate components, the direct accesses potentially make this harder than it should be, especially if a third party is hitting your ajax from another domain(e.g. flash remoting).
+1 to Steve's answer.