+972 52-548-6969
Obscuring HTTP
time to read 1 min | 86 words
Jeff Perrin do a really great job is sumrising what the biggest issue with WebForm is:
Now the first problem with Webforms is not that it’s an abstraction, or even that it’s a leaky one (they all are). The problem is that what Webforms attempts to abstract away is actually simpler than the abstraction!
Comments
Eh, certainly if your goal is to write "something that uses HTTP protocol", then you don't need any abstractions over HTTP. But I thought your goal is way above...
My goal is to respond to the user in some way, usually by sending specially crafted text that can be interpreted by a browser on the other end. Complicating the matter makes things worse needlessly.
Embracing the simplicity inherit in the request/response model means that you end up with very simple design.
Sorry for posting this again but I was wondering what your thoughts are.
In your screencast (hibernating rhinos #2) you dragged a customers table to the web form designer. Then you claimed that there isn't a way to filter the customers returned based on something like a permission (for example).
In reality this is simple. All you have to do is hook the RowDataBound event and hide the row. Surely you know this, I'm not sure why you made that argument since it only strengthens the other side when there is such an easy response.
Heh, Scott and I joked that if we were going to do a MonoRail workshop for ASP.NET users, we'd probably want to spend quite a bit of time explaining what GET and POST are. I guess that's not really a laughing matter though.
That is absolutely not a joking matter, sadly.
Come on, saying that the goal of WebForms is to abstract HTTP is like saying the goal of NHibernate is to abstract the SELECT statement.
I don't want to get into the merit of whether WebForms do it well or not, but there's a lot of things being abstracted and simplified (for the good and for the bad) there.
I wish MS used Monorail as an option.
For now, I'm stuck with Webforms since MS supports it and customers want it.
There is fear that when I leave no one would know Monorail.
But, until Monorail is not 'beta/RC' status I won't use it for production. I use NHibernate 1.2.4000 and want a corresponding Monorail installation (not from subversion, an installer like RC)
Sorry for this, but these are guidelines I must follow. The risk is too high if my customer knew I wasn't using a true release version.
(I thought Hammett was going to release it from a paying customer?)
Aaron,
I have worked with many developers who work with ASP.NET but do not even know how to make basic HTML and Javascript adjustments. They rely heavily on the visual designers and wizards. So that puts them an extra layer away from the protocol and network layers that they should understand for the sake of performance as well as reliability. For example, if they think a set of AJAX callback is guaranteed to return in the order it was sent out they come across some problems.
Day by Day front end web development is not really about HTTP. It is about doing a page after the other. I enjoy the state abstraction of web controls. I like the binding mechanics. Recently I was happy to find CSS-Adapters. May be I forget about the pains - but I am happy about web forms - they serve me well. (You have work with em, not against them ;-)
And isn't HTTP this TCP abstraction?
Day by Day front end web development is not really about HTTP. It is about doing a page after the other. I enjoy the state abstraction of web controls. I like the binding mechanics. Recently I was happy to find CSS-Adapters. May be I forget about the pains - but I am happy about web forms - they serve me well. (You have work with em, not against them ;-)
And isn't HTTP this TCP abstraction?
The point I was trying to make was that abstraction of HTTP is good, because working with the raw protocol is obviously not something any sane person would do. But the Webforms abstraction is so vastly different from the underlying model (HTTP) that there are far too many leaks. This is of course open to interpretation and debate.
Robert, don't even get me started on the ridiculous-ness of CSS-Adapters. An entire framework created to work around the fact that the default ASP.NET web controls often output horrible markup is just... Awesome. In a tragic way.
robert,
No, HTTP is not an abstraction of TCP, it is a communication mechanism that uses TCP, different thing all together.
Day by Day front end web development is not really about HTTP - If you really think that, then you are hitting the sweet spots of the WebForms framework, good for you.
But try to build a non trivial page and see what is going it then, when you need to manage the state and handle all sorts of "interesting" issues that occur as a result
I must admit that sometimes I love web forms, but sometimes I hate them....it is about 70% love and 30% hate :D. I have a basic concept of Castle Monorail, it seems to me far superior than web forms, but I cannot use for production code, the company where I collaborate wants to stay on the standard...so....no monorail for me :(.
Web forms are not that orrible, but they can be overabused, for example by developers that do everything in visual studio designer and really do not know well http basic concepts, post, get, form-urlencode..etc etc.
For the CSS adapters I must admit that they solve some problems, it is true that standard web forms control generates horrible html, but it's true also that with a CSS adapters you can make your site validate XHTML rules more easily.
Alk.
Ayende, "it is a communication mechanism that uses TCP",
if you go that way you could say, ASP.NET is not a abstraction of HTML but a web application development framework ;-)
Found on Wikipedia: “It is useful to remember that HTTP does not need TCP/IP. Indeed HTTP can be "implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used."” (HTTP for mobile phones does not rely on TCP?)
I had to work with php and asp and after these two ASP.NET felt so much better. I know the competition to ASP.NET are RoR and Monorails - and really, really, wish they are a so much better that they make me change the way I develop ;-)
ASP.Net has a lot of great things in it, but it is not WebForms.
WebForms takes that and make the stuff that used to be easy very hard. Some of the seemingly hard stuff become easier, but the hard stuff now requires stepping outside the framework comletely.
Do give it the Rail frameworks a chance, they pack both the ease of use of accepting the model with all the nice stuff that you like in ASP.Net
Comment preview