http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Adi, You question was: "And how do you program Asp.Net without webforms" http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment43http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment43Sun, 02 Sep 2007 17:03:24 GMTOk, but Markus didn't use MonoRail / Ruby etc - he used plain Asp.Net..... http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment42http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment42Sun, 02 Sep 2007 16:44:49 GMTAdi, MonoRail http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment41http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment41Sun, 02 Sep 2007 10:05:14 GMTOren 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? http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment40http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment40Sun, 02 Sep 2007 05:58:05 GMTAdi, 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. http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment39http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment39Sat, 01 Sep 2007 09:43:59 GMTAdi, Make a distinction between WebForms & ASP.Net I really like ASP.Net and I really don't like WebForms. http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment38http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment38Fri, 31 Aug 2007 17:17:45 GMT50 million reasons for using Asp.Net: http://dotmad.blogspot.com/2007/08/one-developer-2-servers-over-50.html http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment37http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment37Fri, 31 Aug 2007 16:57:56 GMT"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! ;-) http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment36http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment36Wed, 29 Aug 2007 18:05:21 GMTBecause 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 http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment35http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment35Wed, 29 Aug 2007 03:45:21 GMTVIVA classic ASP circa 97!!! http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment34http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment34Tue, 28 Aug 2007 20:43:46 GMT@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. http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment33http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment33Tue, 28 Aug 2007 07:50:09 GMT@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? http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment32http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment32Tue, 28 Aug 2007 07:35:39 GMT"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. http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment31http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment31Tue, 28 Aug 2007 00:01:39 GMT> 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? http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment30http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment30Mon, 27 Aug 2007 20:32:31 GMTOkay, if I refresh the page for avoiding CAPTCHA caducity the comment appears two times, my excuses ! http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment29http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment29Mon, 27 Aug 2007 18:04:11 GMTI 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 ) http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment27http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment27Mon, 27 Aug 2007 18:02:18 GMTI 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 ) http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment28http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment28Mon, 27 Aug 2007 18:02:18 GMTAyende'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 http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment26http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment26Mon, 27 Aug 2007 17:38:48 GMT@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... http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment25http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment25Mon, 27 Aug 2007 16:44:33 GMTHarris, 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 http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment24http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment24Mon, 27 Aug 2007 16:39:21 GMTNo, why would they need that? My controller has _no_ association to the views, the view are just for rendering, nothing else. http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment23http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment23Mon, 27 Aug 2007 16:30:19 GMT@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... http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment22http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment22Mon, 27 Aug 2007 16:29:37 GMTJS, I've had good luck with Kali Ma, the old Indian Thug God of Death, for these issues. /Mats http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment21http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment21Mon, 27 Aug 2007 12:50:10 GMTWebForms... 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 ? http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment20http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment20Mon, 27 Aug 2007 11:59:40 GMTMats, 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. http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment19http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment19Mon, 27 Aug 2007 10:51:46 GMT@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 http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment18http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment18Mon, 27 Aug 2007 09:52:36 GMT@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 http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment17http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment17Mon, 27 Aug 2007 07:32:09 GMT@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 http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment16http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment16Mon, 27 Aug 2007 07:28:37 GMTMats, 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. http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment15http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment15Mon, 27 Aug 2007 04:31:06 GMTI 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. http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment14http://ayende.com/2737/in-defense-of-webforms-well-maybe-not#comment14Mon, 27 Aug 2007 02:33:38 GMT