Currently I use php + ajax to create dynamic web applications. As I realized, sometimes I need to write much more javascript to achieve dynamic appearance than I would need to write just php for 'static' page.
After small research I found websockets / sockets.io. Can I use it instead client-side javascript to achieve the same dynamics (some pagination, reloading website parts without reloading whole page...)?
Another thing is server-side programming language (and framework) for that task. Languages I've been working with:
Python (I would prefer that one)
Javascript / CoffeeScript
Java
Do you know any web framework written in one of those languages that fits my needs?
Non blocking environments/frameworks you might want to take a look at.
JavaScript: node.js
Python: Twisted
Ruby: EventMachine
If your requirement is to reduce javascript ajax thus propose using websockets, it will not help u much. Maintaining socket is beneficial to avoid long polling ajax/rest requests, in your case it doesnt look like much if only to render json for dynamic contents.
Also im not sure where does stateful exist in your requirements.
So stick with your architecure as is
Related
I have a question about the concept:
I was out of the web development practices for ~3-4 years, and now, when I try to return to it and to adopt the last technologies, I am very confused.
In the past, I was used to use JSP/PHP/Java Servlets, or some other technology that processes the page in the server and then sends it to the client. For example (JSP):
<% for (String s : names) { %>
<% =s %>
</br>
<% } %>
If I understand correctly, nowadays, AngularJS should perform the loop on the client, instead of Java on the server, and the data should be achieved by the client in JSON format, using an AJAX call to the server.
Is my understanding correct?
If so - I think that all I need is a server that will enable me to define the AJAX functions - I don't need to mix server code with client code anymore (I.e. I don't need JSP / PHP / Java Servlets / etc.). So are there new simple server technologies that are designated to enables these AJAX calls? Which server technologies are recommended and commonly used for these targets in Java and in Python nowadays?
Yes, your understanding is correct. AngularJS is one option, there are other JavaScript frameworks that work in a similar manner - Angular seems to be the most popular at the moment.
As for the server, you can use pretty much any technology there, the standard is to provide JSON data through RESTful web services.
Node.js with Express is popular (and easy to use), if you want to use JavaScript on the server as well.
If you want to use Java, you can use something like JBoss or Jetty as a server and then expose your services using something like Resteasy as RESTful services. It's fairly easy to add to an existing application.
I recommend that you start with the Angular tutorial, which will go through many of these concepts in great detail. It's a good starting point.
As has been suggested, your back-end server will send a JSON to the client. The client can then render the HTML on the page dynamically using a front-end framework like AngularJS.
It doesn't matter what the back-end language is. However, for best performance, some people recommend that you put an additional back-end layer between your server and the browser where you render your HTML before sending it to the browser. They say this results in better performance and search engine optimization. Node.js works well as a rendering layer, so you might as well simplify your technology stack and use use Node.js for your entire back-end.
Also, server-side rendering is easier to achieve with some front-end frameworks than others. This is one of the reasons React has been trending lately. It's easier to achieve server-side rendering with it.
I am trying to find the optimal architecture for an ajax-heavy Django application I'm currently building. I'd like to keep a consistent way of doing forms, validation, fetching data, JSON message format but find it exceedingly hard to find a solution that can be used consistently.
Can someone point me in the right direction or share their view on best practice?
I make everything as normal views which display normally in the browser. That includes all the replies to AJAX requests (sub pages).
When I want to make bits of the site more dynamic I then use jQuery to do the AJAX, or in this case AJAH and just load the contents of one of the divs in the sub page into the requesting page.
This technique works really well - it is very easy to debug the sub pages as they are just normal pages, and jQuery makes your life very easy using these as part of an AJA[XH]ed page.
For all the answers to this, I can't believe no one's mentioned django-piston yet. It's mainly promoted for use in building REST APIs, but it can output JSON (which jQuery, among others, can consume) and works just like views in that you can do anything with a request, making it a great option for implementing AJAX interactions (or AJAJ [JSON], AJAH, etc whatever). It also supports form validation.
I can't think of any standard way to insert ajax into a Django application, but you can have a look to this tutorial.
You will also find more details on django's page about Ajax
Two weeks ago I made a write up how I implement sub-templates to use them in "normal" and "ajax" request (for Django it is the same). Maybe it is helpful for you.
+1 to Nick for pages displaying normally in the browser. That seems to be the best starting point.
The problem with the simplest AJAX approaches, such as Nick and vikingosegundo propose, is that you'll have to rely on the innerHTML property in your Javascript. This is the only way to dump the new HTML sent in the JSON. Some would consider this a Bad Thing.
Unfortunately I'm not aware of a standard way to replicate the display of forms using Javascript that matches the Django rendering. My approach (that I'm still working on) is to subclass the Django Form class so it outputs bits of Javascript along with the HTML from as_p() etc. These then replicate the form my manipulating the DOM.
From experience I know that managing an application where you generate the HTML on the server side and just "insert" it into your pages, becomes a nightmare. It is also impossible to test using the Django test framework. If you're using Selenium or a similar tool, it's ok, but you need to wait for the ajax request to go return so you need tons of sleeps in your test script, which may slow down your test suite.
If the purpose of using the Ajax technique is to create a good user interface, I would recommend going all in, like the GMail interface, and doing everything in the browser with JavaScript. I have written several apps like this using nothing but jQuery, state machines for managing UI state and JSON with ReST on the backend. Django, IMHO, is a perfect match for the backend in this case. There are even third party software for generating a ReST-interface to your models, which I've never used myself, but as far as I know they are great at the simple things, but you of course still need to do your own business logic.
With this approach, you do run into the problem of duplicating code in the JS and in your backend, such as form handling, validation, etc. I have been thinking about solving this with generating structured information about the forms and validation logic which I can use in JS. This could be compiled at deploy-time and be loaded as any other JS file.
Also, avoid XML. The browsers are slow at parsing it, it is a pain to generate and a pain to work with in the browser. Use JSON.
Im currently testing:
jQuery & backbone.js client-side
django-piston (intermediate layer)
Will write later my findings on my blog http://blog.sserrano.com
I am writing a webapp in Clojure.
I almost want to use Google Web Toolkit for the frontend -- since I can just write Clojure/Java code, and have the library automatically generate the Javascript/AJAX.
However, for some reason, GWT does not sem to be used much in the real world.
Is there something that is similarly tied into Java (like GWT is) but more popular?
Thanks!
There is JWT.
GWT is used in the real world!!! A lot! And google is doing some pretty huge things with it so I don't think popularity is a valid concern.
I don't want to start a flame war so I won't elaborate any more on this.
Also, remember that GWT is a java - javascript compiler. No bytecode will run on the client. Hence, you can only use java, not clojure code when writing client-side code.
GWT is not particularly useful with Clojure, because it (GWT) uses a custom compiler that reads Java source code (not bytecode). Unless you want to write all your user-interface code in Java, GWT will not help you.
Now ClojurescriptOne is a good way on an alternative to GWT. The things I found missing so far are full source optimization, and of course some customized libraries.
Also for instance clojurescriptone does only compile javascript to one file, does not yet create cached html-files to further speed up load times like GWT does.
The support for Google Closure is not fully wrapped yet so you have to use interops. That said, I still think this is an equivalently good alternative compared to java-programming in GWT.
You might also want to check out my micro-framework supporting development of AJAX apps with Clojure/Ring/Compojure/lib-noir stack:
http://ganelon.tomeklipski.com
It does not copy execution model of GWT, but rather works like Vaadin or Weblocks (but without session-statefulness or complicated UI components): it simply lets your XHR handlers return side effects to be applied to a page client-side through thin (and extendable) JavaScript layer.
For example: response from XHR handler can update part of a page by #id or display Bootstrap's Modal or redirect browser to a new url - but you can really easy add own operations.
I realise this question was asked long ago, but there is now a direct answer - ClojureScript. It allows you to directly compile clojure code into javascript, and supports most of the common clojure idioms.
The context is that I don't want to use Zend MVC - controllers, helpers, decorators etc - that's overkill for what I am writing.
I've scoured the jQuery site plugins section and these issues bother me most:
I have to search a lot for plugins - it is tedious.
I have to check dependencies with jQuery versions. Thankfully I decided to stick with only jQuery or noConflict() would have driven me crazy.
I have to hook-up all the id's and names of form elements across HTML+CSS+JQuery through Controllers, Views etc.
And all this because there is no other simpler PHP wrapper over jQuery plugins than ZendX_JQuery - and plugins is where the attractive scripts and effects are.
Writing a in-house replacement to ZendX_JQuery will be a huge task in itself. But if you have to wrap third party jQuery plugins in PHP and maintain the thing it is full time job in itself.
So I want to know if Zend_Dojo is much easier than ZendX_JQuery. I'm asking before trying out because I'd have to spend a couple more days installing, configuring and testing all the standard Dojo controls and then I can decide. All that's tedious for a rather simple app which may grow later on.
The alternative would be a "jQuery-inside" PHP widget library that is stable and will work for a year without being broken or upgraded.
Something like GWT or ZK or ASP.Net where you don't have to do low-level HTML+jQuery coding and hand-tweaking for every page with all the ajax controls and form elements.
Or should I just drop an MVC framework altogether and replace it with a custom set of scripts only using Zend components where necessary - like Zend_Validate, Zend_Form etc.
I've been working on desktop apps for some time and the switch to AJAX + MVC + Zend is proving a bit too unwieldy, especially given the abundance of design patterns in Zend MVC.
My recommendation would be to use neither ZendX_JQuery or Zend_Dojo. By the sounds of it, that's overkill for you as well. My thoughts may be coloured by the fact that I don't like to mix PHP and JavaScript code except where absolutely necessary - yes, it may be easier to let a component write your JavaScript for you, but it's never going to be as clean as you could write it yourself.
That way, you also maintain separation between behaviour and presentation - always a good thing, as it makes it easier to use the concepts of progressive enhancement.
I agree with Stephen Orr- I use neither jquery nor dojo (after trying both). I use Zend_Form filters / decorators heavily because client side validation has to be redone on the server side anyway. With some custom decorators, you can do it all in html/php.
I try and avoid ajax where possible, and use prototype / scriptaculous where it cannot be avoided. They are lightweight and provide handy shortcuts to use in other JS code.
Our team is experienced in web development (tomcat/Oracle) but not with AJAX on our existing projects. This is new technology for us, so I want to introduce this carefully and correctly.
What should I look at in terms of frameworks or best practice or common pitfalls?
read this:
progressive enhancement
and use a library such as jQuery, mootools, or YUI it'll save you many headaches with cross-browser implementation. this will show you why you want to use a library.
My first recommendation would be to explore the different frameworks available and see what your team prefers in terms of coding style. Most of the frameworks have the same basic features so a lot of it comes down to preference. I prefer jQuery, so that is my first recommendation, but I worked with YUI, MooTools, Prototype and EXT JS before making my decision.
Secondly, I would recommend working AJAX functionality as a progressive enhancement, allowing your apps to work with and without JavaScript. I find that this approach also ensures a solid, working application before worrying about adding the bells and whistles.
Head First Ajax is a good book IMO for getting started with the basic concepts behind working with Ajax. It would probably be a good place to start for your team to gain some knowledge of what is happening behind the scenes in whatever framework you choose.
One thing we struggled with when starting to use ajax was how often to use it.
We had no exact requirement as to where we were supposed to use ajax and not, and initially we erred to the side of using it too much. This affected application complexity quite a lot.
If you think of your inter-page-structure as a state-machine, ajax introduces nested state-machines within each page-state. The moment your sub-state machine ends up with a number of distinct states (I'd say anything over 2), you should think really hard about using a traditional approach.
The best starting point is to try to get a mix og full page reloads and ajax, and be conservative until you're sure you're getting really good at it.
Don't use it where you don't need it.
Long running operations that need to send the client some status updates? Use AJAX.
Markup for major UI elements (menus, ect)? Use plain old HTML.
Basically, use AJAX for transmitting data only. If you try do fancy things like dynamically pulling in UI elements on the client side with AJAX, you are in for a world of hurt when you get a client who wants to use ie5 (they exist), or a non-pc based browser.
first, look at the user interface you already have, and consider where it might make sense for its elements to be able to change/react independently. This is where your ajax enhancements might make sense
second, look at libraries as noted in the other answers (I like AJAXPRO for its simplicity, but it has been discontinued)
if you find that all of your page elements tie together and cannot change independently, then there is really no need for ajax
otherwise, consider how you will access the page state from your ajax enhancement points - depending on which ajax framework you use, you may or may not have access to the entire page object, session state, original request parms, etc. Consider these issues up front to avoid coding yourself into a hole and/or having to make messy workarounds.
If you were on .Net or Mono I would encourage you to use Ra-Ajax which abstracts away JavaScript completely. Though I work for Ra-Ajax (inventor) so I am biased...