Develop Reference

Using constant integers in front and back-end

Say I have the following constants defined in my back-end API:
User::USER_ROLE_NORMAL; // Equal to 0
User::USER_ROLE_ADMIN; // Equal to 1
In my back-end I can now make the following comparisons:
if($user->role == User::USER_ROLE_NORMAL)
What is the best practice for when I have to apply logic in my front-end? (where these constants are unknown)
It doesn't feel right to hard code the numbers in the front-end, like so:
if(ajaxData.role == 0)
For context: I need to apply logic in the front-end based to change layouts

As frontend and backend logics do not have to be necessarily (and should not be) coupled, the best approach here I think is to define those same constants in the frontend code. Bear in mind that the frontend code should always be in consonance with the API specifications.
The way you do it is up to you (many good alternatives can be found).
An (easy) approach could be with some global variables or using some kind of service if you're using some framework.
Something like:
const role {
USER_ROLE_NORMAL: 0,
USER_ROLE_ADMIN: 1,
};
Then you can use them as follow:
if(ajaxData.role == role.USER_ROLE_NORMAL) {}
Another option (not very used) is that you could create a service in the backend API which provides those values for the frontend to use it. So before the frontend code could use any value regarding to roles (for instance), a request must be made to the backend in order to get those constant values and save it in the frontend in order to use it in future operations.

You could also generate the content of the JS file with all constants using backend. In this way you manage those data in one place, which may be the benefit.

A first solution would be to create another file, for the frontend javascript to use, defining the constants. But this has a big disadvantage: you will have to make sure both files (frontend constants and backend constants) are the same. If you change one, you'll have to remember to change the other.
But firstly, note that this disadvantage also exists if you just hard-code the constants in the first place (this is terrible, and absolutely not an option).
The solution is to have an automated process (the so-called build step of development), that auto-generates the frontend constants file based on the backend constants file.
In javascript development, it's very common to have a build step: Webpack, Grunt, Gulp, etc... If you already have one of those, add to the build step a script that auto-generates the frontend constants file.
If you don't have a build step in your development process, this is a great time to start.

Getting user agent value. Server side vs Client side?

I need to pass user agent value into front end.
I can get this value using $_SERVER['HTTP_USER_AGENT'] and write it into front end.
(Actually I will be using Mage::helper('core/http')->getHttpUserAgent(), but I think it's just a magento helper to call above mentioned function.)
Or I can use get navigator.userAgent with js on client side.
Which better and why? My primary concern is speed.
p.s. I understand that UA can be easily manipulated. We are not basing any serious functionality on the value, it's used as a secondary parameter.

I would personally use navigator.userAgent. Mainly, because passing values from PHP to JavaScript is pretty ugly in my opinion. Also, the value will be exactly the same for both. Even if someone decides to edit their useragent.
I think simplicity takes the cake here.

Performance will depend on the purpose. If you need this inside php, then use the server variable with helper getter you mentioned above. For js use navigator object.
In general both navigator.userAgent and HTTP_USER_AGENT are variables of Request Header and are both already present in memory (of server or users browser in case of js). So no measurable performance difference is possible.

Isn't it dangerous to have query information in javascript using breezejs?

Just starting to play with breeze.js because of the obvious gains in coding time, i.e. managing to access model data from the server direct within Javascript (I am a newbie here, so obviously bare with!).
In the past I have used the stock ajax calls to get/post data to the server, and I have used a few different client tools in the past to provide some help in querying local data, such as jLinq.
My question is this. Isn't it dangerous to have essentially full model query access in Javascript? I must be missing something because it looks like a really well thought through tool. In the past I have at least controlled what can be sent to the client via the backend query process, and again using something like jLinq etc I could filter the data etc. I can also understand the trade-off perhaps with gaining the direct query/none-duplicating local model problem, so just if anyone could provide some insight to this?
Thanks!
EDIT
Obviously I am not the only one, however I am guessing there is a reasonable response - maybe limiting the data being requested using DTO methods or something? The other question posted is here

It can be dangerous to expose the full business model. It can be dangerous to allow unrestrained querying of even that part of the model that you want to expose to the client. This is true whether you offer an easy-to-query API or one that is difficult to query.
That's why our teams are careful about how we construct our services.
You should only expose types that your client app needs. If you want to limit access to authorized instances of a type, you can write carefully prescribed non-queryable service methods. Breeze can call them just fine. You don't have to use the Breeze query facilities for every request. You'll still benefit from the caching, related-entity-navigation, change-tracking, validation, save-bundling, cache-querying, offline support.
Repeat: your service methods don't have to return IQueryable. Even when they do return IQueryable, you can easily write the service method to constrain the query results to just those entities the user is authorized to see.
Fortunately, you can blend the two approaches in the same service or in collaborating services.
Breeze gives you choices. It's up to you to exercise those choices wisely. Go out there and design your services to fit your requirements.

Breeze isn't meant to be your business logic in that sense. Keeping in mind the rule of thumb that if you do something in Javascript, anyone can do it, you ought to be restricting the visibility of your own service data as needed.
In other words, it's useful for you if you meant to make the data publicly visible anyway. But only expose the entities that you're happy exposing and allowing anyone to query; another way to look at it is that your API becomes a public API for your website (but not one you advertise and tell everyone to use).
I am personally not a fan of doing things this way as there is a dependency created on the schema of the backend implementation. If I want to make changes to my database tables, I now have to take my Javascript into consideration. I also lack in terms of integration and unit testing.
However, it can have its uses if you want to quickly build a website feature on non-sensitive data without having to build the service methods and various layers of implementation of it.

What about when you expose the Metadata? Isn't that considered dangerous. IMHO is not safe to expose metadata from the DbContext. I know you can construct metadata on the client, but the point is to do things as quickly as possible(if safe).

Is there a REST based ORM?

I've been looking at JavaScriptMVC, and I'm pretty interested in the idea. I'm wondering, though, if there are any ORM solutions for such an architecture. It seems like you will end up having to write two data access layers, one server side to fetch items from the database and one on the client side to retrieve items via AJAX.
My question is, are there any existing (preferably open source) solutions that would let me define a model (XML or class definition) and generate a REST api for me to access my data. I've been looking at DataMapper while I'm thinking about this, and it would be great if create a model, and instead of calling Person.all(:age.gt => 30) like I would in ruby I could just query /Person/All/?filter="age>30" (properly escaped of course) and get back an object serialized to XML without having to write the controller myself.
Is there anything out there like this? Does this seem like an intelligent way to go about framing a javascript based app?

After some more research, I think I've found my answer. Using CouchDB I can have all of the application logic running in the clients browser and use the built in REST api to persist the data to the server. This way, I could even manage the model in the client side javascript.

Generate JavaScript objects out of Django Models

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