I'm mean seriously, are you guys really up for having to assign to every text field in your form whenever a user posts back? I'm still waiting for someone to tell me that I've gotten it wrong and that in fact this does still happen automatically.
In MVC you are not supposed to do postbacks, the from's action attribute should point to a different URI that handles the form action. If form validation is the issue and you may want to send the user back to change details you can implement the validation
in javascript without a postback
the from's action attribute should point to a different URI that handles the form action
This isn't necessarily always true. For example, consider the paths /Blog/Post and /Blog/View/{id}. To create a new post for your blog, you navigate to the Post action and are presented with the standard text entry items.
If when you submit the entry the form posts to /Blog/Post and there happens to be an error with the submission (e.g. no title supplied, invalid entry date, etc.), you can output the error message to the page
and also have access to an automated mechanism which repopulates the form values for you. Additionally, if the user reloads the page, the same post will take place and you'll get the same error and repopulation, so
no data is lost.
If the site redirects to /Blog/View/{id} only when the post is successfully submitted, you don't have to worry about the user hitting refresh and losing his data or double-posting the blog entry, since refreshing now hits the
View action rather than the Post action.
I'm rather curious, from the looks of it, the majority have not tried developing websites using other languages?
Perl,PHP,Ruby,Python,JSP,ASP(Classic) -- they all do it the way you're not required to do it in the MVC.
Having major experience in several of the named languages, I don't see what the fuzz is about.
And ofcource you're still surposed to do postbacks, You may need to develope websites that work without javascript one day *cough*.
Yes, that case is valid, and it happends. But even with form submission, you can just alter the view based on the form data.
Again, same way as you would do it 'in the old days' of classical ASP (or the other languages).
This isn't necessarily always true. For example, consider the paths /Blog/Post and /Blog/View/{id}. To create a new post for your blog, you navigate to the Post action and are presented with the standard text entry items.
If when you submit the entry the form posts to /Blog/Post and there happens to be an error with the submission (e.g. no title supplied, invalid entry date, etc.), you can output the error message to the page
and also have access to an automated mechanism which repopulates the form values for you. Additionally, if the user reloads the page, the same post will take place and you'll get the same error and repopulation, so
no data is lost.
That is incorrect. The scenario you give is clearly consisted of two separate actions. A "GET" and a "POST". And in REST fashion, it will be translated to /Blogs/New and /Blogs/Create. Failure on "create" (fails validation) will redirect you back to the
"new" action (as result, maintains the clean url). In MVC, you should never have to test for these same page (action) PostBacks, if you do it correctly. Page.IsPostBack should be a thing of the past.
Again, same way as you would do it 'in the old days' of classical ASP (or the other languages)
For me the fuzz is about the old way being inferior to asp.net with viewstate and automatic control re-hydration. Its not that the old way is obscure or that I haven't done it before, its that its not as good.
In MVC, you should never have to test for these same page (action) PostBacks, if you do it correctly.
-- And even if we did, it would just be to check the HttpContext rather than a IsPostBack boolean :-)
There is a few cases where checking is valid, but it's so rare one can live with the check.
srulyt
Participant
1073 Points
230 Posts
Re: Why not support post-backs?
Mar 26, 2008 02:25 PM|LINK
In MVC you are not supposed to do postbacks, the from's action attribute should point to a different URI that handles the form action. If form validation is the issue and you may want to send the user back to change details you can implement the validation in javascript without a postback
WhatThe12
Contributor
3416 Points
984 Posts
Re: Why not support post-backs?
Mar 26, 2008 03:19 PM|LINK
Ok, I meant a form submission.
Is this a public website? If so, does a person without javascript get some kind of warning?
craigvn
Member
24 Points
9 Posts
Re: Why not support post-backs?
Mar 26, 2008 09:38 PM|LINK
I warn them to stay away from the internet or they might get scared of the boogie monster.
levib
Star
7702 Points
1099 Posts
Microsoft
Re: Why not support post-backs?
Mar 27, 2008 05:37 AM|LINK
This isn't necessarily always true. For example, consider the paths /Blog/Post and /Blog/View/{id}. To create a new post for your blog, you navigate to the Post action and are presented with the standard text entry items. If when you submit the entry the form posts to /Blog/Post and there happens to be an error with the submission (e.g. no title supplied, invalid entry date, etc.), you can output the error message to the page and also have access to an automated mechanism which repopulates the form values for you. Additionally, if the user reloads the page, the same post will take place and you'll get the same error and repopulation, so no data is lost.
If the site redirects to /Blog/View/{id} only when the post is successfully submitted, you don't have to worry about the user hitting refresh and losing his data or double-posting the blog entry, since refreshing now hits the View action rather than the Post action.
TheDeathArt
Member
123 Points
50 Posts
Re: Why not support post-backs?
Mar 27, 2008 10:18 AM|LINK
I'm rather curious, from the looks of it, the majority have not tried developing websites using other languages?
Perl,PHP,Ruby,Python,JSP,ASP(Classic) -- they all do it the way you're not required to do it in the MVC.
Having major experience in several of the named languages, I don't see what the fuzz is about.
And ofcource you're still surposed to do postbacks, You may need to develope websites that work without javascript one day *cough*.
Yes, that case is valid, and it happends. But even with form submission, you can just alter the view based on the form data.
Again, same way as you would do it 'in the old days' of classical ASP (or the other languages).
shinakuma
Member
378 Points
92 Posts
Re: Why not support post-backs?
Mar 27, 2008 03:55 PM|LINK
That is incorrect. The scenario you give is clearly consisted of two separate actions. A "GET" and a "POST". And in REST fashion, it will be translated to /Blogs/New and /Blogs/Create. Failure on "create" (fails validation) will redirect you back to the "new" action (as result, maintains the clean url). In MVC, you should never have to test for these same page (action) PostBacks, if you do it correctly. Page.IsPostBack should be a thing of the past.
WhatThe12
Contributor
3416 Points
984 Posts
Re: Why not support post-backs?
Mar 27, 2008 04:20 PM|LINK
For me the fuzz is about the old way being inferior to asp.net with viewstate and automatic control re-hydration. Its not that the old way is obscure or that I haven't done it before, its that its not as good.
TheDeathArt
Member
123 Points
50 Posts
Re: Why not support post-backs?
Mar 27, 2008 04:22 PM|LINK
In MVC, you should never have to test for these same page (action) PostBacks, if you do it correctly.
-- And even if we did, it would just be to check the HttpContext rather than a IsPostBack boolean :-)
There is a few cases where checking is valid, but it's so rare one can live with the check.
hankbeasley
Member
3 Points
2 Posts
Re: Why not support post-backs?
Apr 03, 2008 08:54 PM|LINK
On an related topic: What patterns/tools are you guys using for form validation?
paul.vencill
Contributor
6716 Points
1358 Posts
Re: Why not support post-backs?
Apr 04, 2008 03:31 AM|LINK
You know that ASP.Net postbacks rely on javascript too, right?