Quite some time i`ve learnt MVC. I have seen various techniques to post data :ajax post and form post.
Is there any other?
I`m quite confused about which technique to use and when?
Can anyone help me on this part?
Well, all ways you described above are serving to send the data from your html form to the server for processing.
You were right, you may send this data via form post or ajax post.
The difference is simple.
When you are doing form post, your browser is collecting all parameters from your form and sending it to the server.
While the browser waits for the response, it hangs any activity for the page. After that, the page is blinking and reloading its content.
All that period of time, the consumer of your site feels that he should sit and wait for some time until the window blink and reload its content.
Ajax post does the same as the form post. It collects the data from the page and then sends it to the server.
The main difference, this way does not hangs your browser window.
In this way your application works like windows application. Things are opening, closing, the data is changing, etc.
This way requires of using some script language like javascript or vbscript.
At present moment there is a lot of javascript libraries that helps you. For example, you may use jquery library
So, since there is no difference, its up to you which way to use.
I would recommend to always use firstly form post, because it does not requires any client scripting and its easier to implement.
When you be sure that your application is working in the way you want,you may add some good looking things like ajax posts, so your application will look more friendly to the consumer
A form does an HTTP Post request back to the server. I'd suggest to use 'Post, Redirect, Get' Pattern. Take a look at this article: http://www.eworldui.net/blog/post/2008/05/ASPNET-MVC---Using-Post2c-Redirect2c-Get-Pattern.aspx
The PRG pattern sounds nice but I really dislike having to put the received values in TEMPDATA.
Related
This more of an out of interest question than an urgently need an answer one, but I have been trying to find a good example of how to deal with a full postback from a partial view in asp.net MVC. The obvious example is the case where you have a small login form on every page. You can easily accomplish this through an asynchronous post back using jquery, but I am wondering if there is a way to do it without the use of javascript. I know it may be pedantic, but I don't like the idea of assuming the client has javascript enabled, particularly in this day and age where responsive design/ progressive enhacements are the big buzzwords around, so having you log in tied to javascript means that anyone on a simple mobile device won't be able to use it since their device probably won't support it.
Anyone have any ideas / examples of how to accomplish this? It's such a simple thing to implement in web forms I can't believe it's as tricky as I've heard it made out to be in MVC.
You just need a form within the view, that's all. The form will POST to its controller action method and generate a full page refresh (if that's what you mean by a full postback - I guess it is) irrespective of whether its a partial or not.
You can have multiple forms on a MVC view, and each one of them will give you a full page refresh, whereas with WebForms the pattern was one main form per page.
Isotope lets you write templates in javascript. These templates can then be rendered by either the client (using plain-old javascript) or on the server (using Johnson).
The benefit is DRYer code. When updating the DOM on an ajax or web socket update, you can don't have to write a new partial...just point it to the one you already wrote.
Has anyone used this?
Interesting, I would have to try it, however , and I know not a lot of people do it, but I actually use HAML to template .js files. Although there is still that problem the author mentions , of each request being templated on the server and sending back html, unless you are sending loads of kb, or you have really, really high load site I don't think it's such a big deal.
Also ideally you shouldn't be even sending html data back and force, just JSON objects, which are rendered on the page by your ajax request. The only legitimate use I can see for this is if you have heavily ajax website, such as where you load a page once, and the you just keeping doing ajax requests for all interaction and javascript to manipulate view.
So it would help if you would clarify the final goal. Is this for some internal app where you control user environment ( you know for sure which browsers they will use, and that they will have fast enough computers to manipulate all this javascript?) Or is it going to be an app targeted towards 3rd world, where people don't have yet resources available to use all that fancy javascript.
All that said, it's an interesting concept, and I will try it our myself, to see how well it works.
This uses Johnson, which last I checked did not work on Ruby 1.9. So that might hint at some of the immaturity of this particular solution. Eventually the community will come up with something that works really well.
One approach I have used is to make 2 completely separate templates, but try to make them as similar as possible so that it is easy to port changes from one to the other.
This seems like a bad idea. In an Ajax application, I believe that the server should be responsible for rendering all display text. This makes i18n easier, and concentrates everything in one place. The JavaScript should simply receive data from the server, with all display text already rendered, and put it in the appropriate DOM object.
In other words, I believe that in an Ajax application, the need for a JS template engine is itself a design smell.
The situation is different in exclusively client-side JS applications, of course.
In my ASP.Net MVC 2 application I am using a Json object to submit form data. I would like to take expert advice whether it is a safe and good practice to do it or not and why? Please note, this question is not about how to do it but rather about best practice. Appreciate your valuable suggestions.
Yes it is safe to send and receive JSON from/to the server. You only need to make sure to properly format and encode it. Whether it is good is subjective and will depend on your scenario. As JSON is a common format for javascript it is used along with AJAX requests.
I think it's a safe way to go.
I don't think there is much difference (for security reasons) to send the data via a regular post or a Json object submit.
In both cases the data is wrapped into a http post request which is a readable thing.
So i think both solutions are equal from a security perspective.
As said above, JSON is fine to use going both ways, provided you are still applying the same validation as you would with any form input.
Personally, I love the ability to make AJAX calls and simply do:
Return Json(myDataObject)
Then it's really easy to process that with jQuery on the client side as it's automatically transformed into javascript variables for you.
I'm after some design advice.
I'm working on an application with a fellow developer. I'm from the Webforms world and he's done a lot with jQuery and AJAX stuff. We're collaborating on a new ASP.MVC 1.0 app.
He's done some pretty amazing stuff that I'm just getting my head around, and used some 3rd party tools etc. for datagrids etc.
but...
He rarely uses Submit buttons whereas I use them most of the time. He uses a button but then attaches Javascript to it that calls an MVC action which returns a JSON object. He then parses the object to update the datagrid. I'm not sure how he deals with server-side validation - I think he adds a message property to the JSON object. A sample scenario would be to "Save" a new record that then gets added to the gridview.
The user doesn't see a postback as such, so he uses jQuery to disable the UI whilst the controller action is running.
TBH, it looks pretty cool.
However, the way I'd do it would be to use a Submit button to postback, let the ModelBinder populate a typed model class, parse that in my controller Action method, update the model (and apply any validation against the model), update it with the new record, then send it back to be rendered by the View. Unlike him, I don't return a JSON object, I let the View (and datagrid) bind to the new model data.
Both solutions "work" but we're obviously taking the application down different paths so one of us has to re-work our code... and we don't mind whose has to be done.
What I'd prefer though is that we adopt the "industry-standard" way of doing this. I'm unsure as to whether my WebForms background is influencing the fact that his way just "doesn't feel right", in that a "submit" is meant to submit data to the server.
Any advice at all please - many thanks.
The thing you need to take into consideration is how the application will work if javascript is not available. You should strive to ensure that the basic functionality works without it. This is called progressive enhancement or unobtrusive javascript and is considered a best practice.
http://en.wikipedia.org/wiki/Progressive_enhancement
The way you should do it is to use a form with a real submit button and then hijack that form to use ajax if the User Agent supports it. This is usually pretty trivial to do using the jquery forms plugin. In your action method, you can check to see if the incoming request is an ajax request by checking the Request.IsAjaxRequest property. This is set by MVC automatically on requests that have the X-Requested-With header set to XMLHttpRequest. Then you would return a full view or just some json based on that.
Here's a short screencast demonstrating this: http://www.youtube.com/watch?v=YQsFR1rkgMU&feature=player_embedded
Both solutions are viable, though using submit buttons will make your application more accessible (i.e. JavaScript will not be required in order to use it).
You could also do the both - start with a page that has all the necessary logic using postbacks, and "upgrade" it with nice AJAX-y requests and animations. This way, users with JavaScript will get the eye candy, and the page will gracefully degrade when when a user without JavaScript visits the page, falling back to the postback mechanism.
I'm working on my first Ruby on Rails aplication and it's quite big (at least for me ;) - database has about 25 tables). I'm still learning Ruby and Rails and I never wrote anything in Javascript nor Ajax.
Should I add Ajax to my application from the beginning? Or maybe it will be better to add it latter?
Or in the other words: is it (relatively) easy to add ajax to existing web application?
Jeremy Keith has written a great article on this topic, which he refers to as Hijax
In short:
Plan for Ajax from the start.
Implement Ajax at the end.
Depends on how important Ajax is for the application. Since you are probably going to use Ajax for progressive usability enhancements only, I would say it is best to start with a traditional non-Ajax software, and add Ajax features only when you have the first features working. You can do this feature by feature, or write the whole software first, and then start ajaxing it.
Adding Ajax may be easier if you familiarize yourself with unobtrusive JavaScript techniques. Use jQuery instead of Prototype.js, or LowPro in addition to Prototype.js. For the latter, see e.g. Jarkko Laine's PDF book Unobtrusive Prototype.js.
If you are planning to do AJAX, I would do it from the beginning. It will help you structure your controller actions and views, especially with respect to generating some data in partial views, correctly from the very beginning. Knowing that some actions need to be able to render just parts of the page will change your design. This isn't to say that you can't go back and retrofit the design, but I think it's easier to get the design right if you design with this in mind up-front. You should also consider how to make it work without AJAX (or javascript at all), too so that your design is as fail-safe as possible. That doesn't mean that all functionality has to be available, but that important functionality works in the absence of javascript. For example, action links that use AJAX should have a default url that will invoke the correct action via a GET request if the javascript isn't enabled. Forms that post via AJAX should also work if posted normally. Dynamic behavior (like an image gallery) should have a usable, alternative view that works, etc.