Relation between ExtJS Direct and DirectJNgine - javascript

Am new to ExtJS Direct and DirectJNgine. The relation between them confuses me. I cannot get the overview picture.
What I know is:
ExtJS is a JavaScript framework focusing on UI design. It supplies plethora APIs for programmers. I can call these APIs without bitter.
From the official site:
Ext Direct is a platform and language agnostic technology to remote server-side methods to the client-side. Ext Direct allows for seamless communication between the client-side of an Ext JS application and all popular server platforms.
My think is: ExtJS Direct is also a subset of the APIs supplied the ExtJS team for us to use. These APIs can facilitate our work on calling server side method. But I want to dig into a little bit.
Server side method can be any language method, like JAVA C++ PHP etc. Direct APIs handle all possibilities to support different server side language methods?
From the official site:
DirectJNgine (or DJN, for short), is a Java based implementation of the Ext Direct API for ExtJs.
ExtJs is probably one of the most powerful and attractive UIs for web-based applications, as can be seen here, as well as in many other examples. DirectJNgine makes it much easier to use the full power of Java business classes with such a powerful front-end, making Java methods directly callable from the client.
Since ExtJS Direct is already implemented the APIs for seamless remote method invoking. Why DirectJNgine need to implement these ExtJS Direct APIs? What does "a java based implementation of the Ext Direct API for ExtJs" mean?

I'd add server-side to the definition DirectJNgine:
DirectJNgine is an Open Source library that provides a Java-based implementation of the server-side Ext Direct API.
Ext Direct is a javascript framework and resides on client and let's you call any server API. The call is made via HTTP - that's why it's not dependent on the server language. You formulate a HTTP request, not a Java/PHP/any other request.
Server API handles the HTTP request and can be implemented in Java, C++, PHP, .Net etc. One of the Java implementations is DirectJNgine. It runs on server and responses to Ext Direct calls.
In your project you can use both Ext Direct and DirectJNgine for communication between client and server. They don't overlap, they cooperate with each other on the opposite sides of the network.
And you'd use some framework for the presentation layer (ExtJS maybe) and some framework for server business/storage/other layers (to make use of DirectJNgine it would be a Java framework).

Extjs needs to know the URL, the methods and the parameter count for the possible actions and this is provided by for example DirectJNgine.
The API also takes care of messaging between ExtJS and JAVA , i.e. converting incoming JSON objects to JAVA methods (Json with method names and parameters is passed to JAVA methods, their can be multiple actions in one call). And passing back the result from the JAVA methods in JSON format.

I did a bit of digging into extdirectspring when I realised some strange stuff was going on and wanted to know why. Effectively what extdirect does is provide a description of the server side methods to the client in the form of json (+ possibly through other mediums).
On the client side you end up with objects built from this json that know how to call the server code. In the java (extdirectspring) implementation this creates a static variable in your program's namespace for each of the java classes decorated with the 'ExtDirectMethod' attribute. This variable seems to always be the class name with the first letter lowercased. I had a bit of a dig and this appears to be by coincidence - the name comes from the bean name in spring and is not defined by extdirectspring.
In extdirectspring the setup works through the ether (through the servlet + spring) (have yet to bottom out exactly how this works) and it is predefined to respond to requests for api.js (among other things). This then returns the configuration object which is assigned to a static variable in the ext namespace. By default this variable is called REMOTING_API.
To get the client side stuff to know about what the server has to offer you need to put in a call like:
Ext.direct.Manager.addProvider(Ext.app.REMOTING_API);
after extjs has fired up.

Related

Server side javascript/java - javascript communication

A) Are there any resources of how to use server-side javascript without Node.js?
B) Can a java-based server communicate with a javascript-based client?
Both options are okay (I would be more happy with the B though).
My goal is a simple client-server communication, and I think, that websocket still doesn't stand on two legs.
I appreciate your answer.
Probably the best part of the REST services that they are language-agnostic. You can write serverside REST services in any language you want, then consume them from a completely different language. The most basic example (what you mentioned in option B) is combining Java and JavaScript. There are plenty of tutorials showing how to do that, maybe this one:
JAX-RS + JQuery
is the best as a starter, because it highlights the important part. Later on you may want to go for some more advanced JS library to produce production-ready code faster.
B is definitely possibly with Jersey JAX-RS and JSON encoded responses. It can automatically parse incoming JSON-formatted query (typically GET/PUT/DELETE) params or body (typically POST) parameters into POJOs and can transform returned POJOs into JSON for the response.
More than possible we do it in production with a Marionette.js and Backbone.js based front-end.
WebSocket requires a bit of custom protocol work on your part and loses caching and other client optimizations. It is s best suited to realtime message-oriented or incremental binary upload/download workloads.

How does Node.JS work as opposed to PHP?

I'm thinking of switching from PHP to using Node.js for developing my website. However, after researching Node.js for a little while, I can't seem to find exactly how to write a webpage with Node. I see that you use response.write() in Node to write html to your webpage, but that seems like a tedious thing to do, having your entire webpage as a string literal in your node file. How does web development work in Node as opposed to PHP's method of embedding the script into the HTML file?
You don't necessarily need to use response.write for each line of the view, you can use template engines as well. Search for "node.js template engines". At first impression it could seem tedious, but a similar approach prevents you from writing bad code.
PHP is a scripting language, node is a platform built on javascript.
To start web development using node.js, at first you have to understand what makes node different. Node gives you a way to make async calls to your database (which is a very simplified explanation), which you can then wrap in nice html and send (route) it to the browser. Alternatively, you can use something like angular.js in the frontend and use node.js to make db requests and response which is picked up by angular.js which updates the front html. If you like the idea of Single page app with async calls to fetch data, use node with angular. The tutorial that I like is https://scotch.io/tutorials/creating-a-single-page-todo-app-with-node-and-angular Hope this helps!
As others have answered, there exist templating engines for Node. With the current trends in web development, most modern web frameworks encourage the separation of code from the view (or the HTML you deliver to the client). For instance, Ruby's ERB templates, Jinja2 in Python, Handlebars/Jade for Node, and now a lot of modern PHP frameworks support this as well (Zend/Slim).
Another main difference is in how they work and how the languages are designed. PHP is an object oriented language supporting classes, inheritance, member visibility, interfaces, etc. Node.js is Javascript, so using prototypical inheritance.
The communities and ecosystems are different as well. Modern PHP tends to embrace the use of the Composer package manager, and that came after PEAR. However, npm is the official node package manager and it is deeply integrated with the platform. It is trivial to search for new packages and then use them in your projects.
The main architectural difference is that Node is also asynchronous by design, meaning it runs in a single thread and can potentially handle much more connections than PHP on systems with limited memory. When a request comes in to a PHP application, all the services/controllers and everything you defined have to be reinstatiated, you define PHP files and let Apache/Nginx process them. In Node you have a node process which you can proxy outside requests to.
Node.js Provides so many modules to do these things there is framework called express for node.js http://expressjs.com/ You can use a templating engine and create views. some examples are like ejs or jade. It doesnt have to be a string.
PHP is very strongly orientated towards creating web pages from a template, while Node.js is lower-level and broader in scope. A very rough overview of the differences between PHP and Node.js:
In PHP, you'd start a web server (almost certainly Apache), and then put a PHP file in a directory where you want to serve something from. You might use some fancy .htaccess directives to make URLs nicer, etc.
In Node.js you create a script, in which you use the http module to start a web server, and then you supply a callback for whenever a request is made to your server. Deciding which page to respond to the request with, etc, is all your work to do.
In PHP, things like routing a request to a particular PHP file, compression, decoding POST and GET variables, are all done by using Apache - your PHP files are sort of just like templates which Apache runs whenever a request is received. In Node.js, everything, from starting the server to sending HTML, is all done within your Node.js script - you have to do everything.
HTML isn't the first class citizen in Node.js that it is PHP. Generally, in Node.js you are just sending strings to the client. There are plenty of third party templating tools for Node.js - but they will be dependencies, not builtin functions.

HTTP requests from Sling ESP scripts (Server side JavaScript based on Rhino)

How can I make an HTTP request from a Sling ESP page? Is there something like JQuery or Node's http module that I can use? Or do I have to fall back to Java code?
(Sling ESP Pages are server side JavaScript pages running in the Rhino JavaScript engine)
When sling implements a script language it provides a limited set of bindings to commonly used objects. These are defined here:
http://sling.apache.org/apidocs/sling5/org/apache/sling/api/scripting/SlingBindings.html
In addition, Rhino implements several features to provide integration with java. Such as the Packages variable which contains all the top level java packages, such as java and com.This provides you with a way to interact with java directly from the esp, an example being.
Packages.java.util.Calendar.getInstance()
The details of this java interaction can be found here:
https://developer.mozilla.org/en-US/docs/Rhino/Scripting_Java?redirectlocale=en-US&redirectslug=Scripting_Java
So to answer your question.
No, there isn't a supplied http module for you to use.
Your options are:
Forgo the esp and write a java servlet.
Use the Rhino/Java integration to write the HTTP call in the esp file using the relevant java objects.
Encode the HTTP code into a re-usable OSGi service and use the java integration to access the service
My recommendation would be option 3 as it provides the best code portability, and is the closest to what I would consider the "sling" way of doing things. To access the service you would just use:
var service = sling.getService(Packages.foo.bar.HttpClient.class);
There's no out-of-the box service that you can use to make HTTP requests from a Sling script, but if an HTTP client bundle (such as those from http://hc.apache.org/) makes its classes available you can use them in any Sling script.
As JE Bailey says, that wouldn't be the most convenient thing so you could write an OSGi wrapper service to make this easier. And maybe contribute that to Sling (hint, hint ;-)
If you want to make requests to Sling itself you can use the SlingRequestProcessor service which bypasses HTTP and makes internal requests to Sling directly.

RESTful API communciation from Ruby on Rails (4.0)

We are working on a RoR project implementing an LMS. We need to send data to an external REST service provided by an external server. The data is sent when certain events are accomplished, it is possible that some of those are not triggered by the client (clicks, etc.).
Also, we need to keep consistency in our rails models, because we need to keep record of the user activities.
There is a library provided to work with the API, written in JavaScript. It makes most of the work easy, so we would like to use instead of creating our own implementation for the API requests.
What are the differences between each of the following approaches? Would one be preferable to another?
Use javascripts to send the data, inserting the snippets in the
views, from the client, but having the client execute this might have
some serious implications (scores changed, false success, etc).
Use a NodeJS server to execute the Javascript but we don't really know how to communicate with our main server (Rails)
And finally, use a HTTP client from the Rails app to send the requests to the service. However we don't know exactly how to do it, also there is the question of where this code goes in the MVC pattern.
Option #1, as you've likely realized, is out of the question. For the client to make API calls on your behalf, you would need to send them your secret key/token/whatever you need to authenticate with the API. But once they have that, they could just use a script console to make whatever API calls they want "as you". This would be pretty disastrous.
Option #2 might be prohibitively complex -- I'm personally not sure how you'd go about it. It is possible, using a library like therubyracer, to execute JavaScript code from Ruby code, but there is some degree of sandboxing and this may break code that requires network access.
That leaves you with Option #3, writing your own Ruby library to interact with the API. This could be easy or difficult, depending on how hairy the API is, but you already have a JavaScript version on hand (and hopefully docs for the REST service itself), so combined with something like RestClient or HTTParty the path forward should be clear.
As for where the API calls would fit in your Rails code: If you have models that are basically mirroring the resources you're interacting with through the REST service, it might make sense to add the relevant API calls as methods or callbacks on those models. Otherwise it might be fine to put them in the relevant controller actions, but keep an eye on your code complexity and extract to a separate class or module if things are getting ugly.
(In cases where you don't need to wait for the response from the API before sending something back to the user, you may want to use DelayedJob or similar to queue your API calls in the background.)

Is it good practice for a web browser to interact with a RESTful API?

I've been using a couple RESTful APIs for server to server interactions recently and am now thinking about communicating directly with a RESTful API via javascript from within a web browser in my web application.
This would mean using ajax within a web page to talk to my web server using GET, POST, PUT and DELETE requests and the server responding with appropriate http status codes and non-html data (probably json)
Is this generally considered good practice for a web application and why?
It doesn't matter if you are consuming an RPC API or RESTful API from the ajax standpoint, but generally, you can think of a RESTful API as a well-organized, well-namespaced set of remote procedural calls.
Is this generally considered good practice for a web application and
why?
It is useful to do things this way because you don't need to duplicate code in order to have regular CRUD operations across multiple data objects.
Another thing to consider is that if you have a uniform naming convention of API calls that you can write AJAX functions to interact with, you will write and maintain much less code over time in your javascript side of the application, assuming you don't do anything weird in your code.
An example of when / how this would be a good practice would be if you had written a base method designed to automatically determine your AJAX url depending on what you're doing and where you are, and it automatically determines what POST method to use depending on the type of operation... then you literally write one ajax function, and apply it to things rather than write fully separate ajax methods per action item.

Categories