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
Help those who have helped you... remember to "Mark as Answered"
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.
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.
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...
Help those who have helped you... remember to "Mark as Answered"
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.
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. ;)
Help those who have helped you... remember to "Mark as Answered"
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.
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!
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?
paul.vencill
Contributor
6716 Points
1358 Posts
Re: Why not support post-backs?
Apr 07, 2008 12:59 PM|LINK
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
paul.vencill
Contributor
6716 Points
1358 Posts
Re: Why not support post-backs?
Apr 07, 2008 01:00 PM|LINK
Right, and how many sites do you know that *only* use the handful of controls that don't use the _doPostback() javascript stuff?
WhatThe12
Contributor
3418 Points
984 Posts
Re: Why not support post-backs?
Apr 07, 2008 02:34 PM|LINK
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..
mrfleck
Member
164 Points
109 Posts
Re: Why not support post-backs?
Apr 07, 2008 03:06 PM|LINK
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.
paul.vencill
Contributor
6716 Points
1358 Posts
Re: Why not support post-backs?
Apr 07, 2008 07:35 PM|LINK
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...
WhatThe12
Contributor
3418 Points
984 Posts
Re: Why not support post-backs?
Apr 07, 2008 09:18 PM|LINK
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.
paul.vencill
Contributor
6716 Points
1358 Posts
Re: Why not support post-backs?
Apr 08, 2008 03:33 AM|LINK
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. ;)
[C.I.] Reman
Member
158 Points
44 Posts
Re: Why not support post-backs?
Apr 08, 2008 04:56 AM|LINK
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.
English Blog: Code-Inside International
jdcrutchley
Member
252 Points
63 Posts
Re: Why not support post-backs?
Apr 08, 2008 01:28 PM|LINK
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...
WhatThe12
Contributor
3418 Points
984 Posts
Re: Why not support post-backs?
Apr 08, 2008 01:29 PM|LINK
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?