We've been working on web solutions for over past 9+ years and just like many of you, we've migrated from the legacy ASP to ASP.Net, MVC, knockoutjs and so on. jQuery played a keyrole and now it seems its the age of MVVM libraries like KO with declarative data binding based approach.
I'll stop here and ask for expert opinions on our two requirements -
An editable grid with inbuilt sorting, paging and basic search. And if possible a grid capable of handling its own editable dialog (i.e. like datatables.net - but its paid)
Is there a way to take the declarative binding to the next level and auto-generate forms backed with knockoutjs like data-binding technology.
I believe no need to mention that we're working in ASP.Net v4.0+ and MVC. Most of our forms are backed by one or more table(s) and we can easily manage the backend CRUD operations once the correct actions are triggered from front end and we can have requests serving JSON as and when requested.
PS: We don't need the old school approachs like the #Html.EditorFor in MVC.
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...)
We've an ASP.Net MVC2 web app (SQL 2008 in backend). We use Data Annotations at model level for all sprt of validations (hope its one of the best practices). So, our validations are performed on server side and errors (if any) are returned. Works fine.
Next, we've AJAX based postback jQuery plugin. In combination with MVC partial views, we've 'AJAXified' certain forms. I hope this is pretty much like a basic stuff with a little AJAX & jQuery.
Now, we want to bring the validation on client side as well (and still
persist the server side validation). We've found some simple &
basic way to have basic validations like required, format,
range, etc... using bassistance jQuery. But what about certain server
side validations, like duplication check, etc.. what are the best
practices?
Note that we've simplified our web app by not including the default Microsoft AJAX libraries. We prefer simplified jQuery plugins. Also Microsoft js files weight several KB. Though it might lesson the effort but it requires several files.(Data Annotations Validation + jQuery.Ajax Post)
For example, jquery forms plugin looks simpler then the default MicrosoftAjax.
jQuery plugins are abstract & self contained thats one reason we're away from the Microsoft scripts. Here're some options -
SOLUTION #1:
Using ASP.Net Data Annotations validations using pure jQuery, AJAX,
JSON & Partial views
SOLUTION #2:
ASP.NET MVC Client-Side Validation Summary with jQuery Validation Plugin
We need to keep things simple, clean and optimal. For example, this looks complex -
ASP.Net MVC: Can you use Data Annotations / Validation with an AJAX / jQuery call?
If possible we'd prefer to keep the validation in one place instead of having to replicate it in data annotations as well as in jQuery.
Thank you.
But what about certain server side validations, like duplication
check, etc.. what are the best practices?
In ASP.NET MVC 3 you could use the [Remote] data annotation.
In ASP.NET MVC 2 it doesn't exist but you could implement it using jQuery.validate remote rule. This assumes that you use the jQuery validate plugin of course instead of the built-in Microsoft client side validation framework.
Microsoft scripts are now obsolete. If you want to ease the migration towards ASP.NET MVC 3 and even 4 you should forget about those and use jQuery and jQuery validate which are the default client side frameworks now in ASP.NET MVC.
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'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.