I am working on a web app, where a EXTJS makes an ajax call to a JSP, the JSP in turn calls a java class and then returns the value and updates something in the database.
now the question is, I somehow do not feel this is an effective way, I discovered about servets working and was wondering if should just make a Ajax call to the servlet instead of JSP. Are there any other ways which are better and optimized. Please explain.
Thanks,
SixthString
You're right - a Servlet is better suited for situations like there where all you really need is data from a web end point. The purpose of JSP technology is presentation, there really shouldn't be any business logic in a JSP if you can help it. JSPs are usually employed as the V in MVC (Model-View-Controller) - a design pattern that advocates separating the presentation from the control and business logic. So in theory, if you did everything just right, you would be able to swap out one view for another with minimal work since the view just presents the information.
Do note that JSPs are eventually compiled into Servlets themselves so the issue isn't one of a technical limitation but more of a good design/programming practice.
It depends on what you want returned form your Ajax call. JSP is used for generating formatted HTML. If that's what you're looking to get from the Ajax call, then JSP could be the right choice.
If you're looking for some raw data, then you might as well skip the JSP template and go straight to the servlet. I recommend using JSON in this case, because it's easy to work with in JavaScript.
Related
I'm using MySQL/PHP/Jquery and a custom MVC structure because my app is fairly small. My question is (and this could be in any language): When using a MVC programming structure where do the files you hit via ajax go?
For example I use long polling to show the status (progress bar) of background processing. In my non-MVC version of this tool I just have a php file that is only hit by the ajax call, it makes an object and calls a method to return the percentage done. Ajax returns my number and updates a progress bar.
How does this ajax loading fit into a MVC structure?
Thank you!
MVC is just a pattern. JavaScript code itself can implement this pattern, so I don't think of it as fitting into some other portion of your server side framework's pattern. Check out Backbone for a good example of using MVC in JavaScript code.
You can model your JavaScript code off of similar concepts that you model your server side code with. The JavaScript code itself will get served up through the view of your server side application, but unless you're only adding eye candy with JavaScript code (which you're not) then the JavaScript code is really its own entity and doesn't necessarily fit into your server side MVC paradigm.
Try to separate the JavaScript code from anything server side. Just consider it an 'add on' that, if disabled in the browser, won't break your application from running. I just add some niceties to allow for better interaction, etc. How you actually model the JavaScript code is up to you, (but I do highly recommend Backbone)
One could also do a Rich frontend in javascript backed only by a data source. In this case, once again, javascript will be responsible for maintaining models, views and controllers.
Domain model generally just refers to the business logic of your application. The brains so to speak of what should actually happen in your app. It's kind of an abstract concept encapsulating all the business logic of an app.
im using codeigniter, im using an dedicated controller for ajax and checking $_SERVER['HTTP_X_REQUESTED_WITH'] to determine if its an ajax request.
you can use same approach, and you can keep all of your structure(use your models in ajax controller etc...)
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.
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'm currently diving into web development after ten years of desktop development and I'm trying to get a high level grasp on the many concepts I'm learning. The two most recent concepts I've been reading up on are MVC (specifically ASP.NET MVC) and AJAX. I understand MVC is a pattern used to separate logic and data and AJAX is a combination of various web technologies for creating asynchronous and dynamic web pages.
How are the two related?
Can or should the two be used together?
If so, can you give some simple examples?
I apologize if these are strange questions and I'm comparing apples to oranges, forgive me as I'm still a huge gigantic noob.
Ajax is just of way of requesting data : generally, with Ajax, instead of requesting a full HTML webpage, you just request :
either a part of the page (say, the HTML code of one part of the screen you want to refresh without reloading the whole page)
or some data ; using JSON or XML as data-exchange format, for instance
MVC describes the stacks used to :
Access the data and do actions / calculations / whatever on it (M)
Present it (V)
Going through the Controller, which determine which Model and View should be used to serve the data you requested.
When you use an Ajax request, you do exactly as you'd do serving a full page :
get a request
determine which Model and method should be called
call them (maybe they'll do something with a Database, or whatever they have to)
pass the data to the View, which will render it
The two differences are :
The "View", in one case, renders a full HTML page : in the other case, only a part of it, or some JSON / XML format
In one case, the request is generally done in asynchronous mode
Ajax or not, you are free to use MVC... or not !
If you are using MVC for non-Ajax request, then, why not do so for Ajax requests too ?
Sorry, I won't give any example of code - I'm not a .NET developer, so won't be able to help with that (but the concept is the same in other languages ;-) )
I'll bite...
They're not related in any way other than they're both web concepts. Ajax is a method of performing an HTTP request and handling the result. MVC is an architectural pattern for building your web application.
Yes. No matter what architecture you use for your web apps, you should use Ajax where it makes sense. Ajax can increase the performance of your app, and improve the user experience and UI by eliminating bloated data transfer and screen flickering/refresh.
You can use Ajax easily through a number of javascript frameworks such as JQuery. Simply download and include the framework .js files in your application, reference it from your html, and read the documentation on how to make Ajax requests.
How are they related?
I'm assuming you're taking this from the POV of an ASP.NET dev.
It's really just because plain Ajax (+JSON) works much better with ASP.NET MVC than ASP.NET Webforms. Because of the way ASP.NET Webforms muddled together the view and the controller (and not to mention having Postback & Viewstate -- its crutch to allow pre-Ajax pages to overcome web statelessness), this was initially very difficult.
The way ASP.NET server controls cannot be directly (or at least easily) accessed from Javascript practically made it impossible to use conventional Ajax until ASP.NET Ajax UpdatePanels came along (which was, IMHO, another crutch).
With the advent of ASP.NET MVC it's now much easier to use straight Ajax libraries and JSON for ASP.NET web applications.
For a relatively simple application, can Webflow be employed to reduce the need to create form controllers? Well, certainly it can, but I guess what I'm asking is: can and should I write an entire application using Webflow for all of the controller / view logic if my goal for doing so is to reduce the amount of code that I write?
I'm struggling my way through the (poor) Webflow documentation and am wondering if it's worth it, or if I should just stick to regular MVC.
The use case for Web Flow is to solve the problem involved with controller logic that spans multiple-page navigation (a pageflow, or wizard). If you don't have to have a form split across multiple pages (or need several small forms to participate in a single transaction), you probably don't need a Pageflow.
Most applications do need this, however. Anything more than simple CRUD stands to benefit.
Pageflows provide a natural cache for the data and can solve problems involved otherwise when using back button navigation and multiple frames/tabs.
If you are thinking about how to store data that needs to live longer than a single request (the common but misguided view is to store in the HttpSession) then you will definitely get something out of Web Flow. If you're not doing anything like that and processing everything at the request-scope then odds are you don't need Web Flow.
Update:
Web Flow can eliminate the need for specialized controller classes to accomplish following a path of page transitions/form updates along a predefined workflow. If you don't need to do this, you can save yourself a lot of configuration/complexity just by using MVC.
SpringMVC and Spring WebFlow can be used together where appropriate - there is nothing odd about that.
If you have a use-case which is simple crud and you think you could easily implement this using SpringMVC then that's probably the right choice.
Note: You could also achieve this in WebFlow too and that neither better or worst.
If you have complicated wizard logic and state management requirements then WebFlow is great plus you get many other features for free like transactions and persistence support (Version-2).