I need to integrate AJAX functionality into a Struts 2 web application. I was looking at some tutorials and was going to try using the Dojo Plugin but quickly realized it has been deprecated as of Struts 2.1.
The AJAX documentation for Struts 2 gives a lot of potential solutions and I'm trying to narrow it down a little.
I realize this question is a little general and there are some existing Questions here about specific alternatives, but I'd like to get a feel from the community as to what is the most commonly used approach.
I'm also interested in whether it is more common to use one of the AJAX taglib plugins (ie. struts2-jquery) or straight AJAX widgets independent of Struts.
I understand the basic concepts of AJAX but don't have much hands-on experience with any of the libraries. I don't mind putting in some time getting up to speed on something if necessary.
Thanks much for any suggestions!
I'd recommend doing it manually via some JS library and them moving to a taglib plugin once you understand exactly what the plugin is abstracting away for you. I think that getting that hands-on experience with the libraries is a better educational / training investment. That way when you move on to another web framework you'll have a better understanding of the javascript API side of things.
jQuery is probably your best choice so you could move on to the struts2-jquery plugin if you decide it's worth it. The Struts 2 jQuery plugin is actively maintained (albeit a few versions behind on jquery/jquery-ui) and I have friends that are using it quite happily. Still, I personally tend to stick with direct jQuery ajax calls to Struts 2 actions that return JSON or FreeMarker snippets for autocompletion, updating search results, etc.
Use whatever JS framework(s) you want to and don't bother with a plugin unless it offers you a compelling reason to use it.
If you haven't used a JS framework before and are looking for suggestions, I'd recommend jQuery.
I was reading about JSF that it's a UI framework and provides some UI components. But how is it better or different from number of components that are available from jQueryUI, AngularJS, React, Vue.js, Svelte, ExtJS, or even plain HTML, CSS and JavaScript.
Why should someone learn JSF?
JSF to plain JSP/Servlet/HTML/CSS/JS is like as jQuery to plain JS: do more with less code. To take PrimeFaces (jQuery + jQuery UI based) as an example, browse through its showcase to see complete code examples. BootsFaces (jQuery + Bootstrap UI based) has also a showcase with complete code examples. If you study those examples closely, then you'll see that you basically need a simple Javabean class as model and a XHTML file as view.
Note that you should not see JSF as replacement of alone HTML/CSS/JS, you should also take the server side part into account (specifically: JSP/Servlet). JSF removes the need of all the boilerplate of gathering HTTP request parameters, converting/validating them, updating the model values, executing the right Java method to do the business stuff and generating the HTML/CSS/JS boilerplate code. With JSF you basically end up with a XHTML page as view definition and a Javabean class as model definition. This greatly speeds up development.
As with every component based web MVC framework, you have in JSF less fine-grained control over the rendered HTML/CSS/JS. Adding custom JS code isn't that easy as you have to take the JSF view state in the server side into account as well (e.g. enabling a disabled button in JS side won't enable the button in JSF side, which is in turn a huge security advantage). If that is however a major showstopper, then rather look for an action based web MVC framework like Spring MVC. You'll only take into account that you have to write all that HTML/CSS/JS code (and prevention against XSS, CSRF and DOM-manipulation!) yourself. Also if you fall back from Facelets to JSP, you'll miss advanced templating capabilities as well.
On the other hand, if you have a big JSP/Servlet/HTML/CSS/JS/jQuery based website and you'd like to refactor the repeated JSP/Servlet/HTML/CSS/JS/jQuery boilerplate code into reusable components, then one of the solutions would be JSF. Custom templates, tagfiles and components can aid in this. In that perspective, JSF stands above JSP/Servlet/HTML/CSS/JS/jQuery (and that's also why it's pretty important to understand those basics before diving into JSF).
You can find a real world kickoff JSF based project here: Java EE Kickoff App. You'll see that it contains next to JSF as good HTML5, CSS3 and jQuery.
See also:
Difference between Request MVC and Component MVC
Difference between JSP, Servlet and JSF
What are the main disadvantages of JSF 2.0?
Is it possible to use JSF+Facelets with HTML 4/5?
When to use <ui:include>, tag files, composite components and/or custom components?
JSF was created to make it so that java shops didn't have to learn stuff like jQuery and build complex JS but instead focus on a purely Java stack. In a world where time is money and lots of places already focusing on Java development, one less language/piece in the stack makes training and maintaining faster and thus cheaper.
I'll add that JavaScript is easy to become a maintenance nightmare on large teams, especially if some of the developers on the project are not highly web savvy.
With Javascript and frameworks such as jQuery you have full flexibility and full control . With ext's etc you lose much control and must adapt to the framework. With JSF you totally lose control and must totally adapt to the framework. You're invoked in lifecycles etc. and finally you have no control when the call to the server can be made and where not. If you are to do something considered 'special', you're in very hard position. And in JSF world even such basic things as multicolumn table sort or fields where you can type only limited set of characters (such as number field) are considered 'special'.
However, the more flexibility you have, the more errors or bad practices you can made. High flexibility works only with highly intelligent programmers, others will turn the project into unmanagable nightmare.
But, with JSF and its limited flexibility, there's always only a few (or even only one) correct way to do something. You are very limited, you can't make shortcuts, you must write more XML etc. - but when adapting to standard, there's better control on the code the unexperienced or low-skilled programmers will produce. As a result, big corporations love JSF because it is 'safer' for them.
When I moved from GWT to JSF, I was shocked, how many things, that was natural to me, was considered highly untypical and how much simple things were so hard to achieve. What's more, even making the smallest changes, such as adding ':' sign after label, which in GWT/jQuery powered app would be changing one function generating label, required changing dozens of files with localized properties, which wasn't even considered by anyone except me strange...
The benefits of using JSF are not only in generating xhtml + css + js. Sometimes JSF imposes a restriction on the markup you can generate, like any component based framework. But JSF is not just for that, its lifecyle helps greately. After validating the input it can update the model and sync your server side beans without any effort. you just say "whatever the user types here, check if it's a number, if yes then store it in the property YY in object XX" and JSF will do all that.
So yes, you can still use JQuery, JS, etc. But JSF provides many benefits when it comes to writing server side code and saves you from a lot of boiler plate.
I strongly disagree that jsf adds anything. It only adds overhead. Doing ui stuff on the server is the most ridiculous thing ive ever heard. And javascript on large teams works great - its called reusing code.
Just wrap the jquery in some jsp tags, thats all you need and youre done, and dont endure the.shackles and scalability issues with.jsf and richfaces.
Having worked with JSF, Spring MVC, Struts, Grails, JQuery, and ExtJS my opinion is that Grails + ExtJS is one powerful combination.
I would pick Grails over JSF any day. I like the completeness of ExtJS as the client side framework and library, but it comes with a steeper learning curve than JQuery.
Here are the biggest differences between jQuery & JSF:
no MVC architecture
no state control (store date in session or conversation, auto-clean up, etc.)
no (default) validation library
no templating library
no advanced navigation/routing
client side
jQuery was never intended to be used as a full stack webframework. It was more intended for replacing low-level JS code so that writing JS becomes easier and more powerfull in less lines of code.
And it should thus mostly be used to add behaviour on HTML elements.
Having used ExtJS framework for a large web application, I know how easy it is to use. The ExtJS (Schena) is best suited for (Oracle 11g) database interactions in MVC architecture. The View was for the visual / user interactions. The controller specified the 'processing' and the triggers that needed to be used form the PLSQL packages (the API for the CRUD, SQL select queries etc.). The Model and the store files were used to 'map' the data items to the Viewer / inputs.
ExtJS is not suitable for non database intensive web interfaces - where Angular JS may be a better fit.
Is there a significant difference in performance between the two for relatively small post-backs? I'm taking in user input on a website, calculating some values from it and the returning it. Adding AJAX with update panel was really really quick obviously, but I'm wondering if I should just use jQuery instead.
Also, how to the two methods compare in their ability to degrade gracefully?
Thanks.
Not to sound like a salesman, but I recently picked up a copy of Ajax Security (http://www.amazon.com/Ajax-Security-Billy-Hoffman/dp/0321491939/ref=sr_1_1?ie=UTF8&s=books&qid=1278874728&sr=8-1) and it had a good one chapter explanation and comparison of various Ajax libraries and frameworks in terms of not only security but also speed. If you don't find your answer, I would recommend that book.
I personally would use jQuery because you have a finer control over what is actually loaded. The Update Panel, as I understand, updates all of its contents. You can't pick and choose what is updated inside it, whereas with jQuery, you have absolute control.
As for degrading gracefully: The only reason I can think of why the Update Panel or jQuery AJAX wouldn't work (assuming the server is configured correctly and there are no errors in the JS) is that the browser doesn't support Ajax. If this is the case, neither methods will work. So, I wouldn't worry about the differences between the two in that regard.
I want to capture the responseXML that i have built in my jsp.
What should I do.
after that i will transform it in html.
I know this is annoying and we could do it with a framework or a library like jquery but i realize it with ajax.
Also i have problems with jquery and jsp\servlet since i must use a JSON SERVICE.
Why it seems to me that is so complicated.
It doesn't need to be that complicated. You maybe just need to align all the technologies out one by one yourself. JSP, Servlet, JavaScript, HTML DOM, HTML and Ajax are all separate technologies which needs to be learnt and understood separately. Trying everything together at once without understanding them separately will indeed likely lead to more confusion, complication and frustation as you encountered. Follow the given links to learn about them separately. Learn walking before running or cycling.
The jQuery library just removes the need to write/duplicate all the code to keep it all crossbrowser compatible. Only executing an Ajax request the crossbrowser way is already far over 10 lines of (well-writen/indented) code. jQuery brings it to an minimum, an oneliner is possible.
To learn more about the wall between JavaScript/Ajax and Java/JSP/Servlet, you may find this article useful. I've posted several answers before how to get JSP/Servlet/Ajax to work together (although in combination with JSON and jQuery, but almost everyone will agree that JSON and jQuery are the way to go; JSON is easy to generate/parse in Java using Google Gson and is easy to build/access/process in JavaScript as it is the language's own nature; jQuery is actually a revolution in the way you use JavaScript). Here's a good starting point to find code examples I posted before.
Hope this helps.
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.