Ayende @ Rahien

It's a girl

In Defense of WebForms: Well, maybe not...

Mats Helander is in love with WebForms, and he explains why. I think that I have already explained why I don't agree with that, but allow me to go over his points. One important thing to notice is that Mats ignore the problem of "WebForms tries to be WinForms", because, as he says, that is usually an issue raised to explain the root cause WebForms problems.

I think that this is a mistake, because the rest of the problems in WebForms are non as critical as the issue of trying to be WinForms. And the main problem there is state. The web is stateless, windows is stateful. Once you break that basic concept, you already in a world of hurt.

I am much more in love with the WebForms model, which in my opinion is beautiful, efficient, powerful, flexible, scalable, portable, un-obtrusive, perfect for spitting out html, has a really well designed page lifecycle and it jives very nicely with MVC thank-you-very-much

image I was going to try to formulate an answer to that myself, but I think that I will let Mats' own word handle that:

The WebForms page lifecycle model is too complex to wrap your head around

Well, ok, it is.

But it is also really, really good. I freely admit that whenever I need to do something more complex than implement Page_Load and the event handlers of controls, I get totally lost. But when I eventually get it to work – by luck, swearing and occult sacrifice – I must admit I am impressed with the results.

And after saying that, you still think that you can call it good?! That is my definition of Hell. Building software should be predictable, maintainable and obvious. I don't have an issue with learning complex stuff, but needing occult sacrifice (which I have felt the need as well) to get it to work is out of the question. To quote Paul Graham:

It's pretty easy to say what kinds of problems are not interesting: those where instead of solving a few big, clear, problems, you have to solve a lot of nasty little ones. One of the worst kinds of projects is writing an interface to a piece of software that's full of bugs. Another is when you have to customize something for an individual client's complex and ill-defined needs. To hackers these kinds of projects are the death of a thousand cuts.

Sorry, just that is enough to keep me away from WebForms.

Mats then talks about using the DOM that WebForms provides:

Say that you were asked to implement the following method:

     public string SerializeToXml(Employee employee);

There are two obvious ways to do this:

StringBuilder

Using a StringBuilder object (or a plain string) you simply build up the xml as a string, doing things like stringBuilder.Append(“[name]” + employee.Name + “[/name]”);

XmlDocument

Using an XmlDocument object you build up your xml as a Document Object Model (DOM), doing things like xmlNodeEmployee.ChildNodes.Append(xmlNodeName);

When asked to implement the following method, you have the same basic choice:

     public string SerializeToHtml(Employee employee);

You can either use a StringBuilder and just build up the html as a string, or you can build up a DOM representation of your html.

imageMu! I can also do the smart thing and use a templating language. Using XmlDocument to generate XML is tedious in the extreme, because the DOM is built to the document model, not to ease the way we build XML. There is a reason why Orcas has a whole new set of ways to work with XML, because going the DOM approach is just too awkward.

As anyone who has ever worked with AST / DOM can tell you, just because it is the way the computer thinks that way, it does not means that this is the best way to generate it. If I wanted to generate XML, I would much prefer to use something like BooML than XmlDocument. Take a look at the differences:

[XmlLiteral()]
def GetBooksXml(books):
    books:
        for book as Book in books:
            book:
                @id = book.Id
                title book.Title
                author book.Author

The same goes for generating HTML. The DOM is a very awkward way to handle it.

 Mats then raise several cases where having a DOM is useful. Multiply outputs and wanting to delete an existing node after the fact are two of the issues he raises, he then says:

The problem, in my view, with going with a platform that doesn’t offer the flexibility of a DOM is that you don’t have the option the day it would become useful.

I would say YAGNI to that, while adding that if you want it, it is already there. In MonoRail it is DSL Support for Brail, in Ruby on Rails it is Haml. Here is how it looks like:

<?brail
dsl Html:
	body:
		component SmartGridComponent, {"source" : names}
	end
end
?>

Right now it does direct calls to HTML, but it is trivially possible to add HtmlDOM implementation, and handle that.

Mats has this to say on the page lifecycle complexity issue:

So my response to this accusation is to say that the complexity is usually hidden from the application developer.

Really? Take a repeater and put a button in the ItemTemplate, with an OnClick handler to a method. Now DataBind it, send it to the client, and press on one of those buttons. A postback occurs, but the event is not raised. Why?

This is just one of several hundreds of examples that I have where, as an application developer, I need to intimately understand the page lifecycle model and how it affects me. I don't really think that you can say that that an app dev is free from having to always deal with that on all but the simplest page.

imageHere is another telling statement:

Since it is too complex for me to understand, I really couldn’t make a judgment

Mats wrote an OR/M  implementation, which is one complex piece of software. I have a lot of personal respect for that, since I know what is involved in making such an effort. If he can't grasp the page lifecycle, what is the chance that most developers would be able to?

 WebForms and MVC

I have talked about the issues that WebForms MVC has extensively here, but I can surmise it simply as: There is no way for the controller to know that a user has pressed a button without the view being involved, or to build a Controller that doesn't need to be modified to fit the page lifecycle.

You can see how I think about the flow of a request using an MVC platform in the image. Notice that the view is the last thing that is involved, since it is not an important player until the very very end.

One thing that come up as a result of that is that a lot of the DOM manipulation games that Mats talks so much about are simply not necessary when you are using an MVC architecture, it is not needed because you know, in advance of building the view, exactly what you need to do.

I have done extensive work in this area, and my conclusion is that it is simply not possible to get separation from the view layer in WebForms, it is built into the platform, and cannot be changed.

Conclusion, while Mats may have intended to support the WebForm model, but I think that he had managed to bring up the points where using WebForms hurts.

And, as the joke says, stop doing that.

Comments

Dan
08/25/2007 11:22 AM by
Dan

In my opinion the real problem is the impossibility of compile .ASPX pages in a class library without weird tricks.

And the runtime method to return a compiled .ASPX instance requires Full Trust level, thanks Microsoft.

If we could get a library with our views ( compiled .ASPXs without any business logic, only elemental manipulation of data transfer objects ), doing MVC wouldn't be that difficult.

The handler would be a Front Controller that parses the URL and redirects to the expected Controller, that after doing the business logic stuff fill the view properties and render it.

Or put the url-controller rules directly at sections.

So back to topic, the problem are the VIEWS. I want a lighter version of ASPX/ASCX parser & compiler, that doesn't care about <asp:* runat="server" /> tags or raising events.

Something like the old ASP parser that only cares about <% /* code */ %>, and the compiled template would go to an assembly at /bin directory like a regular class library.

If the resulting class has a Render() method that returns a plain string ( HTTP works with plain strings Microsoft !!! ) it would be easy to test the views, to version them and so on.

Mike
08/25/2007 11:33 AM by
Mike

I have never liked the posting back of pages. Seriously, what normal user understands the dialog you get when you refresh a page that was previously posted? Page expired, wtf?

Ayende Rahien
08/25/2007 11:56 AM by
Ayende Rahien

Dan,

You are talking about MonoRail :-)

And I certainly agree with you here.

Dan
08/25/2007 01:05 PM by
Dan

Monorail is a full MVC framework for asp.net , so my actual interest in MonoRail are the view engines.

The other goodies can be great sometimes, but for most projects I prefer a plain C# class as controller that receives from the front controller ( the IHttpHandler at web.config ) a HttpContext decorator that implements IHttpContext for testing.

The real pain comes with the view engine, the asp.net compiled views:

  • Have a public default constructor by default that doesn't return a worker instance, any compiled view needs a parent Page class.

  • The Render method needs an instance of HtmlTextWriter class for generating the final string. In fact, that HtmlTextWriter class can vary the expected (X)HTML depending on web.config settings, .browser files settings... wof !

A lighter version of asp.net parsers without those issues would be an improvement in flexibility, testability, performance and so on.

Currently my workaround for doing MVC in asp.net and get testable views ( apart of testable controllers that is obvious ) is:

  • Generate an assembly of views putting ASCX files in AppCode directory. For some reason ASCXs can be placed in AppCode, ASPXs not.

  • Create an instance of a view in the controller using a ViewFactory that has a private System.Web.UI.Page member for loading the UserControl before return it.

  • Fill the properties and call the view's method ToHtml() that internally calls UserControl's Render(HtmlTextWriter) with HtmlTextWriter construced with a StringWriter as argument. Then returns StringWriter.ToString().

So in my tests I can do:

ItemView view = ViewFactory.Create(IHttpContext);

view.Item = new ItemDTO("1","MyItem");

Assert.IsTrue( view.ToHtml().Contains("ItemName:MyItem") );

I like the final code I get, but the maintanibility of the views assembly is a pain in the ass :-(

Ayende Rahien
08/25/2007 01:16 PM by
Ayende Rahien

Dan,

AspView is a lightweight parser for ASPX in MR.

My motivation is that fighting the platform is a losing proposition, you have to do a lot more work to get the correct result.

Dan
08/25/2007 01:46 PM by
Dan

Yeah I suppose you are right, it makes no sense try to get a flexible solution using one that isn't.

I'll take a deeper look to AspView, I'd love to use templates with C# syntax for the UI logic and that can be compiled. And event edited in VS with Intellisense !

And Subsonic seems to use ASPX-style templates too, perhaps there is something very valuable for other uses apart from code generation.

Dan
08/25/2007 01:46 PM by
Dan

Yeah I suppose you are right, it makes no sense try to get a flexible solution using one that isn't.

I'll take a deeper look to AspView, I'd love to use templates with C# syntax for the UI logic and that can be compiled. And event edited in VS with Intellisense !

And Subsonic seems to use ASPX-style templates too, perhaps there is something very valuable for other uses apart from code generation.

Mike D
08/25/2007 03:32 PM by
Mike D

I still have some legacy sites that use ASP and when called to maintain them I miss the simplicity and elegance. I used ASP.NET / WebForms for about one year before dropping them completely. The model is completely flawed and intrusive. The problem is that there was / is no real alternative so you wind up rolling your own. Forgive me but I don’t consider rails an alternative, rails lacks a good IDE and we already have a great language and IDE, nothing against rails this is just a constraint that I choose to work within. I was actually doing MVC and good workflow in ASP before I was aware the concepts even existed, it was natural and felt right.

One possible solution to all of this would be raw ASP style ascx pages that did not have to inherit from UserControl, a dirt simple interface with a Render method but this is difficult to achieve in ASP.NET.

It’s a shame that MS created such a complex and flawed beast because when you refuse to use the asp.net page model you can no longer use some of the great control libraries. Without a solid simple MVC web framework we don’t have access to control libraries that ease pain. There are rumors from ScottGu that MS is working on this but I think we are looking at VS 2010 or later before it comes of age.

Dan
08/25/2007 03:59 PM by
Dan

Hey Mike, there is hope yet. I have looked to AspView like Ayende said and wow... I'm VERY excited.

There is only ONE dependency with System.Web.UI.Page, and seems like is only for design stuff, probably for editing in Visual Studio.

The templates are compiled, the syntax is like a normal ASPX but the result is a class that derives only from AspViewBase. Render method returns void but probably the output can be checked with a TextWriter I guess.

Anyway no problem, it's open source :-))

The real work is to remove the dependencies from Castle.MonoRail.Framework, 24 dependencies. But seems that it won't be difficult because are abstractions of Session, Request, Response, Controller, ViewLoader and so on.

If I get it, in my opinion MVC would be plain easy in Asp.net. So the unique problem would be to maintain code of others :-))

Will Sahatdjian
08/25/2007 07:21 PM by
Will Sahatdjian

When trying to do some ajax work lately without using atlas, I found myself getting more and more upset with WebForms. Simple tasks like trying to emit html without a ton of awful inline script attached becomes a real pain. Viewstate is horrible and I never use it anyway. I have been wanting to use MonoRail for a while, but my main cause of restraint is the time investment. Well, after the last project, I'm ready to take the plunge...

sdether
08/25/2007 07:40 PM by
sdether

I've been spending a lot of my time in stateful Forms and stateless webservices land for the last two years and and so just default to WebForms when i need a webapp.

The one thing I like about WebForms, although more in concept then in practice, are controls. The last time I worked with MVC was in perl using XSLT as my templating engine, so my perception of MVC is rather dated, but do MVCs allow for re-usable UI components? My impression always was that a view was a full page.

I.e. let's suppose a web app with a bunch of configurable widgets on a page that operate independent of each other. In WebForms, i create custom or user controls for these and each post round trip is properly associated with the form. Do modern MVCs have that type of plumbing , where the controller can send incoming requests to multiple models that can feed multiple sub-views? Or do you have to handle the componentization on each page in both the model and the view? thanks!

Ayende Rahien
08/25/2007 10:04 PM by
Ayende Rahien

sdether,

Yes, most certainly it has.

MonoRail has:

SubViews & View Components exactly for this purpose.

This simplicity make it very simple to handle such cases without any complex code.

Mats Helander
08/26/2007 08:53 PM by
Mats Helander

"Mu! I can also do the smart thing and use a templating language"

But that´s just moving the actual strings you´re stuffing into the strinbuilder out into a separate resource , right? (which is no doubt a good idea, if taking the stringbuilding route for anything large like an html page)

" If I wanted to generate XML, I would much prefer to use something like BooML than XmlDocument."

And I am sure you could forward an excellent argument for this, but I´m also convinced your argument will involve a trade-off of some kind. For example, not being able to send the DOM you don´t get to some other method built in c# for further refinement?

Regarding dsl-s...they are great - for coding in. But I usually don´t want my proams to work by generating code in dsl-s and compiling/parsing it. That is, I love that kind of stuff, but maintainers often don´t. But I may be misunderstanding how you meant here? How would I build a method in C# leveraging a dsl for building xml?

" but it is trivially possible to add HtmlDOM implementation, and handle that."

But that´s the whole point of my post - that it isn´t! It may not be overly difficult, but it sure is a lot of work. I´d /love/ to see an open source initiative in this direction, though.

But that´s the whole vasis of my love for WebForms - that the DOM is there! I can´t buy dismissing it as trivial unless you can point to some alternative implementation.

" A postback occurs, but the event is not raised. Why?"

No idea. I usually write my own class inheriting the button class and overriding the onclick method, and that seems to work for just that scenario.

"There is no way for the controller to know that a user has pressed a button without the view being involved, or to build a Controller that doesn't need to be modified to fit the page lifecycle."

Surely the controller can be an Observer of both the view and the model?

In your link, it seems you are talking more about the front controller pattern, which to my understanding is not to be comfused with MVC?

Personally I think mvc is very widely applicable, front controller otoh very useful for some types of applications but nowhere nearly as widely applicable as mvc.

I think you have many good points here, but I remain unconvinced that you´re not underestimating the long term benefits of building your architecture around a DOM.

flukus
08/27/2007 02:33 AM by
flukus

I stopped taking him seriously at about this paragraph:

"Well, that’s where opinions go aside, but I am always sternly on the side of using a DOM for producing a complex document – especially if you want to be able to produce multiple outputs, as you may need to do when trying to support multiple browsers."

Sure, we've probably all made a few css hacks for IE, maybe even some javascript ones, but who has ever had to render different html to different browsers?

Even if you did I doubt it's any simpler than doing it with something like nVelocity or ruby.

He even likens templating/nVelocity to string manipulation when it is so much more powerful.

Overall I'd say the article reeks of someone defending the technology he is used to using without properly investigating other ways of doing it. Perhaps a more concrete example of a scenario where monorail fails would be better.

Ayende Rahien
08/27/2007 04:31 AM by
Ayende Rahien

Mats,

result = dsl HtmlDom:

head:

    title "My title"

end

body:

    div @id="oren":

        text "Just text"

    end

end

end

Controller.DoProcessing(result)

The result of this can be a DOM, using the HTML Controls that already exists.

That said, I still says that the applicatively of this is limited to a much narrower set of scenarios than what you raise.

. I usually write my own class inheriting the button class

Doesn't this contradict the issue of having it pre-built ? If I need to start messing with it, why bother? Why no use something where it is obvious what is going on?

Surely the controller can be an Observer of both the view and the model?

That means that the controller has strong ties to the view and to the page lifecycle, which I don't like.

In your link, it seems you are talking more about the front controller pattern

No, I am talking about being able to use it without the view taking over the entire architecture.

Mats Helander
08/27/2007 07:28 AM by
Mats Helander

@flukus,

", but who has ever had to render different html to different browsers?"

span here, div there. Maybe this has all cleared up in the last few years, though?

"He even likens templating/nVelocity to string manipulation when it is so much more powerful."

"Overall I'd say the article reeks of someone defending the technology he is used to using without properly investigating other ways of doing it

"

Or it could be you haven´t run into any of the scenarios where my points are relevant ;-)

Because in the end it isn´t more powerful, since in both cases the model you´re constructing consists of a string

Mats Helander
08/27/2007 07:32 AM by
Mats Helander

@flukus,

my response to this dissapeared..

"He even likens templating/nVelocity to string manipulation when it is so much more powerful."

that´s because in the end it isn´t more powerful, since in both cases the model you´re constructing consists of a string

Mats Helander
08/27/2007 09:52 AM by
Mats Helander

@Ayende,

"That means that the controller has strong ties to the view and to the page lifecycle, which I don't like."

If you want the controller to be able to control multiple views, then at least those views need /some/ kind of common interface that your controller could talk to, right?

/Mats

Bernardo Heynemann
08/27/2007 10:51 AM by
Bernardo Heynemann

Mats,

I´m not defendind WebForms, since as of today I believe it to be the most bad-practice encouraging thing ever built, but even with MonoRail I do feel the need to have that kind of contract-first approach.

That´s why I like the MVP approach better than the MVC one. Yes, I know that both the View and the Presenter have to know about the contract, but that´s why it´s there, to be well-known. The coupling is really small, and the price pays itself for being able to develop against a typed contract, instead of a PropertyBag or ViewState (Yes Ayende, I am aware that MonoRail will automatically DataBind my view into the model or whatever class I want, since I even used JSONDataBind as of today and it works as a charm).

I´ve built an MVP Framework called NMVP. It´s going through major refactoring and new features implementation as of today and we´ll be building MonoRail integration. That´s right, MVP on top of MVC. That´s how MUCH I like the MonoRail implementation. If you´d like to take a look at the project just reach the old website at http://www.codeplex.com/nmvp.

JS
08/27/2007 11:59 AM by
JS

WebForms... mmh... life cycle... I wonder why a control must inheritate CompositeControl to PostBack events, and why, when such a control : CompositeControl is embedded in another CompositeControl in an Ajax page I must click twice on a linkButton to get the PostBack !

Maybe I need to sacrifice... who ?

Mats Helander
08/27/2007 12:50 PM by
Mats Helander

JS,

I've had good luck with Kali Ma, the old Indian Thug God of Death, for these issues.

/Mats

Harris
08/27/2007 04:29 PM by
Harris

@Bernardo:

I've looked at the MonoRail code, specifically the BooViewEngine, and I think it wouldn't be that difficult of a task to extend the view engine such that all views either derive from a deveoloper-created custom base class (e.g. like you can do in WebForms by having MyCommonBasePage : Page) or have the default base class implement a given interface as this would end up being (or could be) a custom base class with a "default" interface implementation. As it stands already, the MonoRail Brail views are compiled and each derives from the BrailBase class, just like all ASPX pages ultimately derive from Web.UI.Page; so developers would inherit BrailBase, make it abstract, and implement a desired common interface.

Your controllers could then accept the interface/custom base class as a parameter to the constructor; this would require (I believe, again not an expert or contributor on MonoRail) using Windsor integration to ensure the controller is properly created.

Most of the modification, however, is in the configuration of the view engine to except an alternate base class and then "registering" the views with Windsor.

I'm sure Ayende or others of the MonoRail team will correct me if any of this is incorrect; but that's the way I'd go about it...

Ayende Rahien
08/27/2007 04:30 PM by
Ayende Rahien

No, why would they need that?

My controller has no association to the views, the view are just for rendering, nothing else.

Ayende Rahien
08/27/2007 04:39 PM by
Ayende Rahien

Harris,

This is certainly possible, I just don't see much value in working that way. Views are really simple, no need to make them more complex

Harris
08/27/2007 04:44 PM by
Harris

@Ayende,

Oh I fully agree. I absolutely love the separation of concerns that MonoRail provides. The Controller "silently" pushes what is necessary to the view and the view does what it needs to with what the controller gives it. I've had the "pleasure" of going back to web forms after a short tour with MonoRail and have cried myself to sleep at night because I desire the simplicity that MonoRail provides.

I'm not sure why someone would want to interact directly with the view from the Controller using MonoRail; I was merely proposing a possible way to achieve what Bernardo was looking to accomplish...

Mats Helander
08/27/2007 05:38 PM by
Mats Helander

Ayende's blog was having a hickup and sent his comment in a mail to me but didn't publish it, so we had these offline words:

A: No, why would they need that?

My controller has no association to the views, the view are just for rendering, nothing else.

M: But how can you control the view without being aware of the view?

I always thought the idea behind MVC was to let the controller inject to become a lifecycle event Observer in both the model and the view?

A: I don't need to control the view. The view just does the output generation, nothing more, nothing less.

It is run when the control has finished, taking its output and sending it to the user.

The controller's job in the view ends when it selects the view.

You are thinking about the classic MVC, where the environment was stateful. It has to be adapted to a stateless environment.

---- Bringing it back into the blog from here...

Well that clears up a whole lot for me :-) (I think...)

You're pretty much saying that you're communicating with the controller via http requests, am I right?

Well that is an interesting way to think about it....I don't quite see why the approach would be incompatible with WebForms, but I've only given it a couple of hours thought so far :-P

But ok, now at least I may uunderstand what that particular part of the discussion is about - you're perfectly right that I was thinkingt of MVC in the "old" (not necessarily stateful, though) paradigm of the controller observing the view semi-directly (via an IObserver interface) rather than via the roundabout (but clever) route of http requests.

But, if you still have the patience - why is this concept incompatible with WebForms? Seems you could do it just that way but make use of the DOM (making it nicer to code components rather than mix scrip with html, which - as you may have guessed by now - I'm not wild about) rather than just spit out text? And, for that matter - why would it be incompatible with the "page controller" pattern?

A most enlightening day, this! :-)

/Mats

Dan
08/27/2007 06:02 PM by
Dan

I have decoupled the AspView view engine to be used in plain Asp.net without MonoRail, and yes you can choose the base class that you want.

In fact the big dependencies with MonoRail are in the base class.

The compilation of views requires full trust, WebForms have obvious advantage here for using at shared hosting scenarios.

When using other view engine, you have to options to avoid full trust:

  • Compile the views before deploying.

  • Create a BuildProvider that requires High Trust ( that by the way is a total shame, if you have to deploy in medium trust environment you have to follow the Microsoft way )

Dan
08/27/2007 06:02 PM by
Dan

I have decoupled the AspView view engine to be used in plain Asp.net without MonoRail, and yes you can choose the base class that you want.

In fact the big dependencies with MonoRail are in the base class.

The compilation of views requires full trust, WebForms have obvious advantage here for using at shared hosting scenarios.

When using other view engine, you have to options to avoid full trust:

  • Compile the views before deploying.

  • Create a BuildProvider that requires High Trust ( that by the way is a total shame, if you have to deploy in medium trust environment you have to follow the Microsoft way )

Dan
08/27/2007 06:04 PM by
Dan

Okay, if I refresh the page for avoiding CAPTCHA caducity the comment appears two times, my excuses !

Ayende Rahien
08/27/2007 08:32 PM by
Ayende Rahien

You're pretty much saying that you're communicating with the controller via http requests, am I right?

I wouldn't have put it like that, but this make some sort of sense, yes.

why is this concept incompatible with WebForms?

The problem with this & web forms is that in WebForms the view is the one that has the control on the request. Which means that simple things like switching a view, or renderring a partial view, or combining views is hard, and the more annoying problem is that you still have to deal with a complex view that doesn't want to let go of the request.

This puts the controller as the slave of the view, which is the opposite of what should be.

making it nicer to code components rather than mix scrip with html,

Mats, I disagree with you here. The output format that I need is HTML, so I write in HTML, with maybe a bit here and there of script. This is presentation code only, and it is the simplest & clearest way to do this, IMO.

The DOM has its usages, but it is far more rare that I think you believe.

May I presume that you, too, have been burnt by the ASP "everything is in one place" approach?

flukus
08/28/2007 12:01 AM by
flukus

"span here, div there. Maybe this has all cleared up in the last few years, though?"

Yes it has.

"Or it could be you haven´t run into any of the scenarios where my points are relevant ;-)"

No I haven't. Your yet to provide an example of one.

"Because in the end it isn´t more powerful, since in both cases the model you´re constructing consists of a string"

Because when creating websites i never have need for advanced dom manipulation. Not to mention the design guys hate it when the html is in code, rather than html.

Mats Helander
08/28/2007 07:35 AM by
Mats Helander

@flukus,

"Yes it has."

Ah, that's really nice to hear!

"Your yet to provide an example of one."

I did, in my post. I mentioned any scenario where you need to alter already rendered parts of the DOM during the rendering. Or when passing around DOM parts as prototypes for other parts of the page building service.

"Because when creating websites i never have need for advanced dom manipulation."

Which means that you're not doing the type of work where it makes a difference if you have a dom or not. Fair enough. Silver Bullets considered harmful. I have tried to explain why I think WebForms are excellent for stuff I'm doing and I observed that I wouldn't want to paint myself into a corner by using a platform without such support even when not really needing it since I feel I never know when I'm going to need it. But I haven't tried to claim WebForms are a Silver Bullet - all you'll ever need for all and any of your web app needs! I'm guessing you're not saying Rails is a Silver Bullet, either?

" Not to mention the design guys hate it when the html is in code, rather than html. "

Do they care how the dynamic parts of the html is produced? Are you saying it is the design guys that impose your development paradigm of mixing html with script on you? Well, no, of course not, but are you saying that they at least influence this desicion?

Mats Helander
08/28/2007 07:50 AM by
Mats Helander

@Ayende,

"I wouldn't have put it like that, but this make some sort of sense, yes."

Some sort of sense - that's my middle name! ;-)

"The problem with this & web forms is that in WebForms the view is the one that has the control on the request. "

That assumes you're equating the page to the view. With a page controller pattern, I guess the page is the controller? At any rate: Whatever the front controller does, in terms of dynamically loading custom controller classes and views, why couldn't a class inheriting from Page do the same? That is, assuming that it is possible to separate the concepts of page and view, which I think is quite possible.

"May I presume that you, too, have been burnt by the ASP "everything is in one place" approach? "

Well, that too. :-) But mainly, it is remembering my innocent years as a young, happy-go-lucky CMS developer. You may remember that some seven-eight years ago, CMS was all the rage. Everyone and his aunt were writing one and that included me.

My CMS used a templating engine and my own script language. Unfortunately, it worked. Which meant that for a couple of years, I locked my apps into my own language and my own platform.

It was productive to develop in. It was relatively easy to maintain. But when the "real" (ASP) platform kept getting better, the applications written on my platform could not take full advantage of that. In the end, I had to admit I had painted myself into a corner, and I resolved not to do that again. It was at this point that I learned about the age-old wizdom of "never invent another computer language". Sure, you may be happy Matz didn't care about that advice, thus writing Ruby. But as a general advice, it is very, very, very good.

throwspoop
08/28/2007 08:43 PM by
throwspoop

VIVA classic ASP circa 97!!!

Ayende Rahien
08/29/2007 03:45 AM by
Ayende Rahien

Because Page is all about the view concerns.

You can do that by inheriting from IHttpHandler, but that is front controller again.

Take a look at the ProcessRequestMain in Page and tell me how you can separate that from the UI concerns?

I resolved not to do that again.

Didn't you build an OR/M ? Doesn't that "paint you in a corner" with respect to other things? Looks like you did it again.

If it was easy & productive & maintainable, I don't see the problem.

If it limited you, you can always extend it, or switch the language to VBScript, etc.

The idea is not to limit yourself unnecessary

Mats Helander
08/29/2007 06:05 PM by
Mats Helander

"Didn't you build an OR/M ? Doesn't that "paint you in a corner" with respect to other things?"

I've built three :-) With each one I've learnt about a new and fascinating corner to try to avoid painting myself into in the future.

The first, "Zeasame", used overnormalization (one field value per row), meaning I painted myself into a performance corner. Doesn't matter how cool your app is if it will never perform well enough.

The second, "Pragmatier Data Tier Builder", used code generation, effectively painting users into a maintainability corner in spite of my many (honestly believed) arguments about why it wouldn't.

The third, NPersist, supports POCO persistence, but to be able to support anything approaching what I consider an O/RM baseline (which, ahem, includes partially loaded objects with retained full behavior, dirty tracking and lazy loading on each field) that means runtime subclassing, painting myself into the Factory corner (can't use new if all objects should be proxied) and the virtual method requirement corner.

However, for the first time I'm feeling (after due time has passed) the corner is more of an acceptable tradeoff than a real corner. So I'm pretty happy with the way NPersist works :-)

"The idea is not to limit yourself unnecessary "

Couldn't agree more! :-)

About ProcessRequestMain....I'll have to admit you have a very good point here....I'll have to think about that and come back! :-P It is not enough to completely invalidate my argument, I think, but I would prefer having a good answer for you! ;-)

Adi
08/31/2007 04:57 PM by
Adi

50 million reasons for using Asp.Net:

http://dotmad.blogspot.com/2007/08/one-developer-2-servers-over-50.html

Ayende Rahien
08/31/2007 05:17 PM by
Ayende Rahien

Adi,

Make a distinction between WebForms & ASP.Net

I really like ASP.Net and I really don't like WebForms.

jmajaranta
09/01/2007 09:43 AM by
jmajaranta

Adi, 50 Million reasons for NOT using WebForms :

This was in the interview of plentyoffish-Markus you was pointing to in your Blog post:

Markus: And then after that, you just get bigger machines. But when you're starting up and you're just starting the site, I found that it's best if you go as simply as possible. Don't use any built-in components from ASP.NET. 


Ron: Oh, really? 


Markus: That's what I found. 


Ron: Oh. 


Markus: I just wrote everything myself. Everything is super simple, nothing more complex than an if-for-while loop. No built-in controls, nothing. The hardest thing is database access. 
Adi
09/02/2007 05:58 AM by
Adi

Oren

I may be missing something here. As far as I can tell you advocate using web dev platforms like Ruby, so how can this go side by side with liking Asp.Net?

And how do you program Asp.Net without webforms?

Adi
09/02/2007 04:44 PM by
Adi

Ok, but Markus didn't use MonoRail / Ruby etc - he used plain Asp.Net.....

Ayende Rahien
09/02/2007 05:03 PM by
Ayende Rahien

Adi,

You question was: "And how do you program Asp.Net without webforms"

Comments have been closed on this topic.