ASP.NET MVC

Re: Why not support post-backs?

kirchi — Sun, 27 Apr 2008 10:16:03 GMT

I see one "bad" thing in approach with MVC right now -

I cannot use it on my WebForms website.

I am thinking about using MVC for parts of website while using WebForms for another part - for example I would use WebForms for simple forms that should postback, and use server side validation etc, while I would like to use MVC for AJAX calls and loading dynamically parts of a webform page from MVC rendering engines.

What do you think ? is it wrong thought ? :)

P.S. I decided to add one more thought to one I supposed above.

Suppose I am starting new project - ok I am aware of some advantages of MCV And I really want to try it in my next project - I want to move to it. BUT like in any software company one of main important determinants of a successfull project - in my company is spent time.

I have written a lot of controls - it's a whole library with my own implementation of powerful TabControl, TreeGrdi component, GroupBox, tooltips, and a bunch of AJAX extenders,

so what now ? How I should be encouraged to use MVC and how should I encourage my project manager to start using MVC? Will I be able to hit the same time limits, or will I be able to again create UI-s with the same level of complexity ?

May be I will be fired for my initiative :)

I mean there are a lot of things that are stopping me right now.

Re: Why not support post-backs?

paul.vencill — Tue, 08 Apr 2008 15:21:06 GMT

Like I said in my frist response; I'm probably splitting hairs too much. My point was simply that if you take a normally developed ASP.Net website where the developer doesn't specifically plan for browsers lacking javascript, and someone surfs there with a browser that is javascript *capable* but javascript *deactivated* then the postback functionality will not work properly. While that doesn't always matter, I've worked in domains where it does. What you're describing relies on detecting browser capabilities, not browser settings. I understand what you're saying, though, and I really wasn't trying to spawn a debate, merely make the point that javascript is prevalent in ASP.Net whether you use Ajax or not.

Re: Why not support post-backs?

WhatThe12 — Tue, 08 Apr 2008 13:31:14 GMT

If you don't like MVC, DON'T USE IT.

If you don't like this thread, DON'T READ IT and DON'T REPLY TO IT.

Re: Why not support post-backs?

WhatThe12 — Tue, 08 Apr 2008 13:29:01 GMT

OK...

An asp.net form post is as much a post back as a call to _doPostback. A call to _doPostback is an asp.net form post. Its just javscript doing the submit.

Dude, get over it, asp.net post backs don't need javascript! If you look at the framework you'll even see code that enables you to do a post back using a link and the query string.

Is this an undocumented feature or have I not been keeping up?

Re: Why not support post-backs?

jdcrutchley — Tue, 08 Apr 2008 13:28:38 GMT

Still talking about this? Really? It's pretty simple...

If you don't like MVC, DON'T USE IT.

If you don't like WebForms, DON'T USE IT.

The .NET framework is CHOCK FULL of stuff that you may never need to use. Not everyone uses datasets. Not everyone uses web services. Not everyone uses the built-in membership stuff. Not everyone uses LINQ. This is just one more thing to add to the list of MANY things that you can take or leave depending on your needs.

I for one think it's great we have so many options!

Let's fight over Mac vs. PC while we're at it...

Re: Why not support post-backs?

[C.I.] Reman — Tue, 08 Apr 2008 04:56:31 GMT

The problem with postbacks is (or with webforms), that it has a "too" complex pagelifecycle (with viewstate and so on) for the stateless HTTP. A postback is technically nothing more than a form submit - but why should each site has a "form" tag - that is not the idea of this HTML element. I´m glad that there is a alternativ for the webforms which is more comfortable with the web development.

Re: Why not support post-backs?

paul.vencill — Tue, 08 Apr 2008 03:33:55 GMT

If that's true, then every web framework out there has postbacks... which obviates the other guy's argument completely, as his premise was that it was an asp.net feature. ;)

Re: Why not support post-backs?

WhatThe12 — Mon, 07 Apr 2008 21:18:29 GMT

Technically, *postbacks* do; form posts do not. postbacks by definition (from my reading) are an asp.net feature that uses the _doPostback function. form posts are an html feature that happens to be used by some asp.net controls instead of postbacks. Maybe I am drawing too fine a line, I dunno...

Hehe, I disagree. A form post is as much a post back as a call to _doPostback. A call to _doPostback is a form post. Its just javscript doing the submit.

Re: Why not support post-backs?

paul.vencill — Mon, 07 Apr 2008 19:35:21 GMT

WhatThe12:

Right, and how many sites do you know that *only* use the handful of controls that don't use the _doPostback() javascript stuff?

I really wouldn't know either way. Personally, most of the asp.net sites I've worked on have been internal apps where client script is an acceptable requirement. When I have worked on public sites, a standard submit or image button has been sufficient.

Anyhow the original point is that post backs don't depend on Javascript. Furthermore, there's a difference between improving user experience with client side code and making an entire website dependent on Javascript which is what the poster implied when he wrote..

I am in the process of developing a site and it doesn't have a single post back.

Technically, *postbacks* do; form posts do not. postbacks by definition (from my reading) are an asp.net feature that uses the _doPostback function. form posts are an html feature that happens to be used by some asp.net controls instead of postbacks. Maybe I am drawing too fine a line, I dunno...

Re: Why not support post-backs?

mrfleck — Mon, 07 Apr 2008 15:06:24 GMT

dpant:

Listen pal, I have been working with asp(.net) since ever and yes I can come in and say my opinion much like you can say yours. Most of you guys forget that ASP.NET revolutionized the web when it first came out. Noone, i repeat -noone- wants to refill html forms manually, this is a huge leap backwards. So far this is what this 2nd mvc preview is all about. There may be certain testing advantages but what we want is all our asp.net components, architecture and lifecycle that bring HUGE benefits to RAD web development. There are certain types of websites -if not most of them- that can be created in asp.net in a fraction of time compared to mvc and with a vastly better and richer interface. Of course the mvc is not yet finalized -even the Html and Url helpers are incomplete, and I think everyone expects much more to come. But I cannot just sit and read about asp.net being bad and not supporting separation of layers! Who told you to include your business logic directly in the code-behind files? There are thousands and thousands of (official) tutorials on how to organize your code in layers using the App_Code folder and Web Services! We all know that .net for win applications (win forms) just didn't make it out and that Visual Studio and the whole .net team is focusing 100% on the web. So, cut the crap and let's talk about the real issue: why is microsoft publishing all these new technologies and features (linq, f#, mvc etc) in an inhumanly fast pace without considering the steep learning curve? I mean, come on, new things and options are a good thing but we all know what it feels like to eat your buffet meal in a hurry! My message to microsoft: let us digest the existing techniques; stop chasing competition. ruby for ruby people, php for php people and ASP.NET to us all (amen)!

You are entitled to your opinion, but it would be nice if it was an informed opinion. You never address my comment about plugging in any view engine you want, you just jump right past that and continue your rant. I hope they move faster with these technologies, I don't want them to slow down one bit.

An aditional plus to MS starting to have an alternative that aligns with the rest of the development world is now I will have the ability to hire from a much larger pool. I can also really start to use all of the 3rd party stuff that has been written for those other frameworks. I can't tell you how much things like jQuery have simpplified my job. They were difficult to use in the asp.net world. I have always found myself hacking around the asp.net controls costing me time when all I wanted to do was spit out some specific html. So cheers to MS for doing this and I hope the pace keeps up.

Take like 3 hours out of your day and try it for real. You might just find yourself liking it. Change is not always bad.

Re: Why not support post-backs?

WhatThe12 — Mon, 07 Apr 2008 14:34:59 GMT

Right, and how many sites do you know that *only* use the handful of controls that don't use the _doPostback() javascript stuff?

I really wouldn't know either way. Personally, most of the asp.net sites I've worked on have been internal apps where client script is an acceptable requirement. When I have worked on public sites, a standard submit or image button has been sufficient.

Anyhow the original point is that post backs don't depend on Javascript. Furthermore, there's a difference between improving user experience with client side code and making an entire website dependent on Javascript which is what the poster implied when he wrote..

I am in the process of developing a site and it doesn't have a single post back.

Re: Why not support post-backs?

paul.vencill — Mon, 07 Apr 2008 13:00:31 GMT

WhatThe12:

Ok, I meant a form submission.

I am in the process of developing a site and it doesn't have a single post back.

Is this a public website? If so, does a person without javascript get some kind of warning?

You know that ASP.Net postbacks rely on javascript too, right?

They don't for standard form submit buttons.

Right, and how many sites do you know that *only* use the handful of controls that don't use the _doPostback() javascript stuff?

Re: Why not support post-backs?

paul.vencill — Mon, 07 Apr 2008 12:59:17 GMT

dpant, no need to be hostile; everyone's entitled to their opinion. Maybe you're not trying to be hostile, it just reads that way to me. Sorry if I'm misinterpreting.

I think, though, that you're selling the new *optional* framework short. I have done both ASP and ASP.Net and now I'm trying out ASP.Net MVC framework. I'll tell you that any relationship to classic ASP is purely superficial, and purely in the default view templates. A few examples, based on your comments may be in order:

-- You said manually refilling html forms. That's not necessarily the case, but it depends on your design preference. It's true that there's no viewstate, but you could have the form data get put into the viewdata automatically (there's a handy UpdateFrom() function on the bindings namespace for that), and in your view you could have the form populated from the viewdata just as easily as you do with a regular databound form that's using a template. Further, this is a preview, and the developers have explicitly stated that they're going to work out something like controls and additional 'helpers' once the infrastructure is more complete.

-- Missing architectures... not sure which ones you're not finding, maybe I haven't looked hard enough. let's see... forms authentication, present. Membership, present.. profiles, present... caching, present... controls, reduced functionality...

You're not going back to classic ASP where everything you wanted to use had to either be in a code block or in a compiled ISAPI dll. The only thing that I can find that I'm giving up, truthfully, is the compiled controls, everything else is still there. And, frankly, as I was moving more to AJAX and related RIA technologies, I was finding the old style control model more of a hindrance than a help, even with the asp.net ajax extensions.

Just my opinion, take it as you like.

Paul

Re: Why not support post-backs?

dpant — Mon, 07 Apr 2008 10:36:55 GMT

mrfleck:
dpant:

ps: prove me it is optional.

If you had taken the time to even take a high level look at MVC, this would already be "Proven" for you.Part of the power of this framework is that everything is pluggable even the view engine. MVC comes with the asp view engine, but you can plug in any view engine you like. There are several out there and you could even write your own. We are in early CTP here, I have no idea how you can come in and rant just because you don't get it. I would refer you to http://forums.asp.net/t/1220045.aspx for some additional discussion from some folks similar to yourself. Just because you don't like something does not mean you should run in and rant all over the place, especially when it is obvious that you have done no research on the framework other than seeing a set of code blocks and freaking out because you think this might replace your framework of choice. But don't worry, this is just an option and for those of us that see the advantage of this type of framework, we are glad to have the option.

Listen pal, I have been working with asp(.net) since ever and yes I can come in and say my opinion much like you can say yours. Most of you guys forget that ASP.NET revolutionized the web when it first came out. Noone, i repeat -noone- wants to refill html forms manually, this is a huge leap backwards. So far this is what this 2nd mvc preview is all about. There may be certain testing advantages but what we want is all our asp.net components, architecture and lifecycle that bring HUGE benefits to RAD web development. There are certain types of websites -if not most of them- that can be created in asp.net in a fraction of time compared to mvc and with a vastly better and richer interface. Of course the mvc is not yet finalized -even the Html and Url helpers are incomplete, and I think everyone expects much more to come. But I cannot just sit and read about asp.net being bad and not supporting separation of layers! Who told you to include your business logic directly in the code-behind files? There are thousands and thousands of (official) tutorials on how to organize your code in layers using the App_Code folder and Web Services! We all know that .net for win applications (win forms) just didn't make it out and that Visual Studio and the whole .net team is focusing 100% on the web. So, cut the crap and let's talk about the real issue: why is microsoft publishing all these new technologies and features (linq, f#, mvc etc) in an inhumanly fast pace without considering the steep learning curve? I mean, come on, new things and options are a good thing but we all know what it feels like to eat your buffet meal in a hurry! My message to microsoft: let us digest the existing techniques; stop chasing competition. ruby for ruby people, php for php people and ASP.NET to us all (amen)!

Re: Why not support post-backs?

mrfleck — Sun, 06 Apr 2008 22:46:20 GMT

dpant:

ps: prove me it is optional.

If you had taken the time to even take a high level look at MVC, this would already be "Proven" for you.Part of the power of this framework is that everything is pluggable even the view engine. MVC comes with the asp view engine, but you can plug in any view engine you like. There are several out there and you could even write your own. We are in early CTP here, I have no idea how you can come in and rant just because you don't get it. I would refer you to http://forums.asp.net/t/1220045.aspx for some additional discussion from some folks similar to yourself. Just because you don't like something does not mean you should run in and rant all over the place, especially when it is obvious that you have done no research on the framework other than seeing a set of code blocks and freaking out because you think this might replace your framework of choice. But don't worry, this is just an option and for those of us that see the advantage of this type of framework, we are glad to have the option.