As ShaneBauer pointed out ASP.Net MVC is not a replacement for WebForms its only an alternative.... just another option in ASP.Net Development.... Options are a good thing!!! And most importantly its a MSFT supported framework. For those of us who have
ever been employed by companies where that is a requirement.... having a Supported proper MVC framework is a good thing
Why not have the option to have controls that persist their state across post backs with the MVC pattern?
you can do this manualy using session, application or profile variables
if you really like viewstate that much you can create your own implementation using a Dictionary<string, Object> and serializing it to a Base64 string and store it in a hidden field on your page.
this is very simple and would allow you to hae view state in the pages you want without having the whole post back mechanism
Yes but the point is that I don't want to have to do it manually. And when I pick up someone else's work, I don't want to have to work out their scheme that they've come up with for manually doing it either.
If you don't like viewstate or controls automatically loading their state from the forms collection and the feature was there, then it would be even more simple if you just didn't use it or turned it off.
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.
you can do this manualy using session, application or profile variables
Yes but the point is that I don't want to have to do it manually. And when I pick up someone else's work, I don't want to have to work out their scheme that they've come up with for manually doing it either.
Part of the point of MVC is to move to a more Convention over Configuration style. MVC makes things easy, so long as you give things sensable names and have reasonable object layouts and such. So yes you run the risk of inheriting bad code but at the same
time the framework makes it much easier to do things the right way.
If you don't like viewstate or controls automatically loading their state from the forms collection and the feature was there, then it would be even more simple if you just didn't use it or turned it off.
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.
Well here's how the flow goes:
1) You get your instance's id in action's parameter list.
2) You load your model from the database
3) You call BindingHelperExtensions.UpdateFrom(instance, Request.Form);
-- so long as you named your form fields sane things like say the property names this will just work.
4) save your instance
5) call render view
you can do this manualy using session, application or profile variables
Yeah, nice encapsulation there.
If the answer I provided is useful or informative please check the "answer" button.
Warning: Code is often uncompiled and possibly started life written on the back of a napkin. Beware typos.
Frameworks such as the MVC and Ruby On Rails in combination with Ajax are what is going to lead into the web 3.0 standard. I don't think it will be that long before full page post backs across a server are a thing of the past. If I'm right and that is the
way of the future, then a system that is built upon the concept separating data, presentation, and logic will prevail.
On one hand you have a system that needs a code behind file for each page, a system where full post-backs and ugly (but at the time necessary) hacks such as viewstate are built into the core of the framework. On the other you have a framework that efficiently
separates the code, data, and gui providing much needed room for growth. Just need to send a form back to the server? No problem, send the 32 characters over to a controller method and let it handle it. Need to change the content? No problem, send a request
to a controller and let it fetch the partial view for you.
The MVC (and RoR) has the potential to evolve web development into a full-scaled work flow. Critical components of the life cycle such as unit testing have been a forerunner in importance for at least the MVC from what I can tell. I don't know about you
but I've had the unfortunate displeasure of QAing for web-based applications and its... well.. its a hell of a lot worse than regular QA and thats saying a lot. Although I have no, and I mean -no-, desire to jump back into quality assurance it is nice to be
able setup unit tests and just flip a switch.
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.
The easy answer is just dont use post backs and all the form re-population type stuff is no longer an issue. For any potential postback type scenarios, ie posting a form where there may be a message coming back, I just use jQuery to do the post. Once you
have set up the application to handle it then it is literally only one line of code to do, and the user experience is much better to boot. I am in the process of developing a site and it doesn't have a single post back. Even paging lists or posting data forms
with server side validations doesn't produce postbacks. It is not overly 'Ajaxified', just enough to smooth over the rough stuff.
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.
The easy answer is just dont use post backs and all the form re-population type stuff is no longer an issue. For any potential postback type scenarios, ie posting a form where there may be a message coming back, I just use jQuery to do the post. Once you
have set up the application to handle it then it is literally only one line of code to do, and the user experience is much better to boot. I am in the process of developing a site and it doesn't have a single post back. Even paging lists or posting data forms
with server side validations doesn't produce postbacks. It is not overly 'Ajaxified', just enough to smooth over the rough stuff.
Just out of curiosity craigvn - have you posted a rich text box (tinymce/ftb/fck editor)? Also, are you using a jquery plugin to do the postback or are you just using get? Just getting started w/jquery so still a little shaky with it
Just out of curiosity craigvn - have you posted a rich text box (tinymce/ftb/fck editor)? Also, are you using a jquery plugin to do the postback or are you just using get? Just getting started w/jquery so still a little shaky with it
Actually for my form posts I don't use jQuery because XmlHttpRequest is still a bit shaky for that IMO. For example you cant post INPUT type FILE using XmlHttpRequest. Instead I use this Ajax pattern (http://ajaxpatterns.org/IFrame_Call) for forms. It is
more reliable and I have written a simple wrapper function that makes it very easy to use (1 line of code). I have used TinyMCE this way also. I use jQuery for everything else.
The easy answer is just dont use post backs and all the form re-population type stuff is no longer an issue.
Yeah that would be cool. What would be really revolutionary is if asp.net didn't allow you to send back a full page of html at all except for the first page request.
Ang3lFir3
Member
14 Points
7 Posts
Re: Why not support post-backs?
Mar 25, 2008 01:15 AM|LINK
As ShaneBauer pointed out ASP.Net MVC is not a replacement for WebForms its only an alternative.... just another option in ASP.Net Development.... Options are a good thing!!! And most importantly its a MSFT supported framework. For those of us who have ever been employed by companies where that is a requirement.... having a Supported proper MVC framework is a good thing
WhatThe12
Contributor
3418 Points
984 Posts
Re: Why not support post-backs?
Mar 25, 2008 10:03 AM|LINK
Why not have the option to have controls that persist their state across post backs with the MVC pattern?
srulyt
Participant
1073 Points
230 Posts
Re: Why not support post-backs?
Mar 25, 2008 10:16 AM|LINK
you can do this manualy using session, application or profile variables
if you really like viewstate that much you can create your own implementation using a Dictionary<string, Object> and serializing it to a Base64 string and store it in a hidden field on your page.
this is very simple and would allow you to hae view state in the pages you want without having the whole post back mechanism
viewstate
WhatThe12
Contributor
3418 Points
984 Posts
Re: Why not support post-backs?
Mar 25, 2008 05:21 PM|LINK
Yes but the point is that I don't want to have to do it manually. And when I pick up someone else's work, I don't want to have to work out their scheme that they've come up with for manually doing it either.
If you don't like viewstate or controls automatically loading their state from the forms collection and the feature was there, then it would be even more simple if you just didn't use it or turned it off.
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.
Yeah, nice encapsulation there.
JeffreyABeck...
All-Star
16423 Points
3329 Posts
Re: Why not support post-backs?
Mar 26, 2008 01:59 AM|LINK
Part of the point of MVC is to move to a more Convention over Configuration style. MVC makes things easy, so long as you give things sensable names and have reasonable object layouts and such. So yes you run the risk of inheriting bad code but at the same time the framework makes it much easier to do things the right way.
Well here's how the flow goes:
1) You get your instance's id in action's parameter list.
2) You load your model from the database
3) You call BindingHelperExtensions.UpdateFrom(instance, Request.Form);
-- so long as you named your form fields sane things like say the property names this will just work.
4) save your instance
5) call render view
Warning: Code is often uncompiled and possibly started life written on the back of a napkin. Beware typos.
ChanceUSC
Member
319 Points
209 Posts
Re: Why not support post-backs?
Mar 26, 2008 02:52 AM|LINK
Frameworks such as the MVC and Ruby On Rails in combination with Ajax are what is going to lead into the web 3.0 standard. I don't think it will be that long before full page post backs across a server are a thing of the past. If I'm right and that is the way of the future, then a system that is built upon the concept separating data, presentation, and logic will prevail.
On one hand you have a system that needs a code behind file for each page, a system where full post-backs and ugly (but at the time necessary) hacks such as viewstate are built into the core of the framework. On the other you have a framework that efficiently separates the code, data, and gui providing much needed room for growth. Just need to send a form back to the server? No problem, send the 32 characters over to a controller method and let it handle it. Need to change the content? No problem, send a request to a controller and let it fetch the partial view for you.
The MVC (and RoR) has the potential to evolve web development into a full-scaled work flow. Critical components of the life cycle such as unit testing have been a forerunner in importance for at least the MVC from what I can tell. I don't know about you but I've had the unfortunate displeasure of QAing for web-based applications and its... well.. its a hell of a lot worse than regular QA and thats saying a lot. Although I have no, and I mean -no-, desire to jump back into quality assurance it is nice to be able setup unit tests and just flip a switch.
MVC / RoR = way of the future
Chance
craigvn
Member
24 Points
9 Posts
Re: Why not support post-backs?
Mar 26, 2008 04:54 AM|LINK
The easy answer is just dont use post backs and all the form re-population type stuff is no longer an issue. For any potential postback type scenarios, ie posting a form where there may be a message coming back, I just use jQuery to do the post. Once you have set up the application to handle it then it is literally only one line of code to do, and the user experience is much better to boot. I am in the process of developing a site and it doesn't have a single post back. Even paging lists or posting data forms with server side validations doesn't produce postbacks. It is not overly 'Ajaxified', just enough to smooth over the rough stuff.
ChanceUSC
Member
319 Points
209 Posts
Re: Why not support post-backs?
Mar 26, 2008 05:27 AM|LINK
Just out of curiosity craigvn - have you posted a rich text box (tinymce/ftb/fck editor)? Also, are you using a jquery plugin to do the postback or are you just using get? Just getting started w/jquery so still a little shaky with it
craigvn
Member
24 Points
9 Posts
Re: Why not support post-backs?
Mar 26, 2008 05:58 AM|LINK
Actually for my form posts I don't use jQuery because XmlHttpRequest is still a bit shaky for that IMO. For example you cant post INPUT type FILE using XmlHttpRequest. Instead I use this Ajax pattern (http://ajaxpatterns.org/IFrame_Call) for forms. It is more reliable and I have written a simple wrapper function that makes it very easy to use (1 line of code). I have used TinyMCE this way also. I use jQuery for everything else.
WhatThe12
Contributor
3418 Points
984 Posts
Re: Why not support post-backs?
Mar 26, 2008 11:37 AM|LINK
Yeah that would be cool. What would be really revolutionary is if asp.net didn't allow you to send back a full page of html at all except for the first page request.