Ayende @ Rahien

Ayende Rahien commented on Removing the leaky abstractions from WebForms

Tue, 20 Mar 2007 00:36:01 GMT

Joe, check here for an example of the controls lying to me: http://ayende.com/Blog/archive/2007/03/20/WebForms-and-lies.aspx I will post about the rest of your issues in a short while

Joe Young commented on Removing the leaky abstractions from WebForms

Mon, 19 Mar 2007 15:56:51 GMT

Can someone explain why rails/mvc is better than a view presenter approach? I have looked over the getting started examples and docs for MonoRail and can clearly see the clean separation of the view and the controller. I can also see that it is using raw html and a scripting language, all of which as far as I can tell is reverting almost back to classic ASP. Also, what about server controls? IMHO, they are a huge time saver. Not to mention custom 3rd party controls I can use that contains a lot of functionality so I don't have to write it in. I have never once had a control lie to me about its state, if something was wrong about its state, it was because I did something wrong, not the control. I understand the issues with ViewState and the event model behind ASP.NET, but I think with proper abstraction like view / presenter the and judicious use of viewstate, most if not all problems can be dealt with.

Jeff Brown commented on Removing the leaky abstractions from WebForms

Thu, 15 Mar 2007 08:38:28 GMT

I wholeheartedly agree! ASP.Net tries to do too much and forgets the basics. The abstractions ultimately must be leaky because inevitably you find yourself having to inspect HTTP responses or dissect the raw HTML produced by some fancy control so that you can apply CSS or DHTML effects to it. Not good. I almost never get any mileage out of a designer unless it's written as a true direct-manipulation interface like SmallTalk. Almost all of the interesting stuff in a UI is dynamically generated so it does me no good at all to produce a static mock-up of a form. Even less so if the mock-up is incorrect because it is produced in some way other than running the actual code. A designer's mock-ups do not provide high fidelity with the real app and they never will. I believe this is true to all designers whose implementation requires providing a distinct representation of the view from that actually used by the system. I've also frequently encountered issues due to ASP.Net's closed-world implementation. There are many things that the framework is allowed to do via internal APIs that apps cannot reproduce or change. One of my favourite examples is the fact that SQLDependency auto-enlistment works because SQLCommand knows to look for an undocumented CallContext variable value that ASP.Net has set just prior to page processing. I think there's something seriously wrongheaded about coupling your Data and Web frameworks together like this. I respect the work that many brilliant and talented people have put into ASP.Net but it's not for me. Nope... I'll be using MonoRail for my next app.

Ayende Rahien commented on Removing the leaky abstractions from WebForms

Thu, 08 Mar 2007 22:20:08 GMT

I am using the something like: string policyName = Scope.Input[Constants.Policy.Name]; Where Constants.Policy.Name is "Name", which is also the id of the control on the page. I am handling the ASP.Net name mangling by searching not on the full key, but on the last part of it only.

Luke Breuer commented on Removing the leaky abstractions from WebForms

Thu, 08 Mar 2007 21:51:27 GMT

You say to get data from the request and not from controls; does this mean you know exactly what name attribute will be generated for every control (is it always the same as the client_id?)? I assume you're not using string literals here? (I believe you linked to this post, titled "We Hate String Literals": http://blog.eleutian.com/PermaLink,guid,088e158b-cd3c-4920-8df5-a3628013cc1d.aspx .)

Ayende Rahien commented on Removing the leaky abstractions from WebForms

Wed, 07 Mar 2007 07:44:50 GMT

@ mysterious.e, Selectively working with the view state means that I need to manage it, and I don't like the idea at the first place, better to turn it off completely and work like the web is meant to work. I am aware of the options of compressing / removing it, again, I feel that this is me needing to manage something that should have never been there in the first place. And yes, if I am using WebForms, I _am_ stuck with using the technology in a particular way. >> This depends on where you call it in the page cycle. No, it happens in the Page_Load event, and it would not show the value if it was defined in the aspx page and then databinding (with append data bound items = true) was performed). >> They are global to the instance so you can handle the data from any method. And here is the crux of the matter, I am not handling it in the aspx page. That class is dedicated to presentation logic only. I want to handle it from my controllers, not my views. >> I would that this is a design problem or a design mismatch Yes, I feel the same way, WebForms is not designed to allow good separation of business logic and presentation logic, leading to a lot more work on my part. >> If you want to superimpose your deisgn practices on the webforms model and then gripe that it falls apart then whose problem is that? WebForms. If it tries to be a web framework, it should enable working with the best practices for the web, period. Otherwise, there is a big fault in it. >> No, you mean the WebForms model doesn't fit well with your design pattern. Yes, indeed. Unfortunately, I feel that my design pattern is a best practice for working on the web, and I am not going to work in worst practices just because WebForms thinks that I should

goodwill commented on Removing the leaky abstractions from WebForms

Wed, 07 Mar 2007 02:05:48 GMT

Ayende, Oops you really seems started fire on this one. :) Guys before you say ASP.NET is good or not, I kindly invite you to try monorail first. You will not be in a good position to debate unless you know both reasonable well enough. ASP.NET might not be sucks, but there are lots of hiccups which lots of developers already trained themselve to get use to it. A lot of time a website is really just html and js, a huge abstraction model might not be necessary, or might even hinder a lot of your work. Try to get your ajax do a per html table row update(insert/update/delete), I think in most case you are binded to update entire gridview. And how about a highlight for your new added row? not there unless you take the really big hassle to write the entire ajax enabled web control (I never saw one before). Have a look to scriptaculous sort list and try to implement yourself in asp.net, then I think you have some good idea on what are the difference too. I have been writing ASP.NET since 1.0, and now I move to monorail and never want to look back due to the clean MVC design provided. If Ruby on Rails makes a miracle, it must have a reason, thats what I tend to believe.

mysterious.e commented on Removing the leaky abstractions from WebForms

Wed, 07 Mar 2007 00:21:45 GMT

You could have used and IHttpHandler object. All you get with that is session state (if enabled) and http context. Also, you know that viewstate is not an all or nothing proposition - right? You can selectively turn control state on or off as needed. But, viewstate can get out of hand - but that is not an asp.net problem is much is it as a tuning problem or design problem. Heck, you can even compress it or move the storage else where if it fits your needs. You could have used an .aspx and avoided the use of web controls entirely. In asp.net you are not STUCK with using the technolgy in a particular way. >>> The second reason is that the controls will lie to you about their state. I just run into a situation where a DropDown reported SelectedValue = "" when the selected item was the one defined on the aspx This depends on where you call it in the page cycle. If you call it before the "Init" cycle is completed for the control then may will appear to lie to you becaue state fo the control has not yet been updated. Since asp.net pages use an event driven pipeline, where you call an object for it's state maters. >>> Do not get the data from the controls, get it from the request. You give up validtion plus plus OO for design. Plus, who said you have to pass the controls around. They are global to the instance so you can handle the data from any method. I would that this is a design problem or a design mismatch, not an asp.net problem. >>> I still get a _VIEWSTATE variable in the pages, I assume that it is the ControlState, but so far I haven't dug far enough to find yet. Yes. This is control state. If you want to superimpose your deisgn practices on the webforms model and then gripe that it falls apart then whose problem is that? >>> Update Panels ... They are really cool technology Yes. But this is for webforms. >>> I didn't say that ASP.Net sucked, I said that the WebForms model is not a good fit for the web. No, you mean the WebForms model doesn't fit well with your design pattern. Stop blaming the tool!

Ayende Rahien commented on Removing the leaky abstractions from WebForms

Tue, 06 Mar 2007 00:36:04 GMT

@Mike, I thought that this may be the case. And no way to get rid of that. Thanks for clarifying that.

Ayende Rahien commented on Removing the leaky abstractions from WebForms

Tue, 06 Mar 2007 00:33:42 GMT

@AA, I didn't say that ASP.Net sucked, I said that the WebForms model is not a good fit for the web. And if I could be convinced that a piece of code _really really_ needed to be done in assembly, I would write it in assembly. I find it hard to think about a scenario that would call for this. When I choose what to work with, I take into account not just the code performance, but developer performance as well, assembly is really bad for developers performance.

MIke commented on Removing the leaky abstractions from WebForms

Mon, 05 Mar 2007 21:19:34 GMT

I am sure you already got this, but ControlState IS in the _VIEWSTATE field. I use Fritz Onion's ViewState decoder and it splits up between ViewState and ControlState to see exactly what is in there.

AA commented on Removing the leaky abstractions from WebForms

Mon, 05 Mar 2007 21:05:05 GMT

ASP.NET sucks? Why don't you use assembly code, it must be faster than Monorial, LOL!

Ayende Rahien commented on Removing the leaky abstractions from WebForms

Mon, 05 Mar 2007 14:46:13 GMT

@Samir, Much as I would like to work solely on the Castle stack, in the end, it is the client that gets to make (some) of the decisions. If they really want web forms, I will work with web forms. The file extension would be aspx, the convention would be as close as to MonoRail as web forms would allow.

Samir commented on Removing the leaky abstractions from WebForms

Mon, 05 Mar 2007 14:00:14 GMT

Asp.Net and Atlas sucks!! They are so heavy and slow! Why did you abandoned Monorail? Your articles about Monorail are very nice, but lalely you only speak on webforms. cheers Samir

Andrew Stopford's Weblog commented on Removing the leaky abstractions from WebForms

Mon, 05 Mar 2007 10:45:48 GMT

Ayende has a post on "Removing the leaky abstractions from webforms", webforms do leak abstractions

Ayende Rahien commented on Removing the leaky abstractions from WebForms

Mon, 05 Mar 2007 09:35:17 GMT

No, there is no reference to the view from the controller, I pass the data either via strongly type wrapper on the property bag, or via return values from the controller methods.

David Newman commented on Removing the leaky abstractions from WebForms

Mon, 05 Mar 2007 09:27:06 GMT

Do Igloo controllers have a reference to an IView? Or is everything done through the property bag? Actually, I'm setting up an application at the moment with Castle and ASP.Net and currently I can't inject Presenters (MVP pattern) because they need a reference to the view interface. So I have to call resolve in the presenters to get their dependencies. Do you know if there's a way I can do that Ayende? At the moment I have this: partial class View : Page, IView { Presenter _presenter; void PageLoad() { _presenter = new Presenter(this); } } public class Presenter { IView _view; IDependency _dep; public Presenter(IView view) { _view = view; } public Dependency { get { if (_dep == null) _dep = Container.Resolve(); return _dep; } set { _dep = value; } } public Presenter(IView view) { _view = view; } } In my tests I can set Dependency to my mock, and in live it will get resolved on first use, but I'm sure there's a better way to do it! This is probably the longest comment i've written....

Ayende Rahien commented on Removing the leaky abstractions from WebForms

Mon, 05 Mar 2007 06:05:08 GMT

@Steve I believe that Igloo can certainly give you quite a bit. Take into account that I have fiddled with it to the point that I have the automatic injection of controllers into the views/user controls, and easy access to the user input.

Christopher Steen commented on Removing the leaky abstractions from WebForms

Mon, 05 Mar 2007 03:04:11 GMT

Code Craft Why great coders get paid far too little [Via: shanselman ] Tip/Trick: Integrating ASP.NET...

Steve commented on Removing the leaky abstractions from WebForms

Mon, 05 Mar 2007 00:59:08 GMT

You feel Igloo is ready for prime time production? Is there any good documentation on it? I'm interested in learning more. I want to keep my Atlas, but get a MVC - sounds alot like what you have done