Some Whidbey feedback

From: Alister Jones
Sent: Wednesday, May 05, 2004 6:32 AM
To: Bertrand Le Roy
Subject: SomeNewKid2's feedback on Whidbey

Hi Bertrand,

I'm Alister, and I try to help out on the ASP.NET forums under the alias SomeNewKid2.

Thank you for the invitation to provide some feedback on the direction of ASP.NET v2.0.

First, a little bit of context. I studied business at uni, and have had no programming training. I started with ASP.NET about 18 months ago, and it's my first development environment. Second, my knowledge of ASP.NET v2.0 comes only from the articles on www.asp.net. So, if my perception of v2.0 is that it introduces complexity, then this is perhaps more a reflection of the articles than the product itself.

That said, my perception is that Whidbey is penny-wise, pound-foolish. Its details look fabulous. But its big picture seems either non-existent or, worse, flawed.

Take for example the article on Database Cache Invalidation in ASP.NET "Whidbey". Adding database dependency to the cache is a great detail. However, at the end of the article the following code is shown.

    <form runat="server">
        <asp:sqldatasource id="datasource" runat="server"
                           selectcommand="SELECT * FROM Products"
                           providername="System.Data.SqlClient"
                           connectionstring="..." />
        <asp:gridview id="grid" runat="server"
                      datasourceid="datasource"
                      autogeneratecolumns="True" />
    </form>

At first sight, my response was, "how clever". A moment later though it occurred to me ... this cleverness invalidates the concept of n-tier architecture. Here we have data access in immediate proximity with its presentation. Absolutely no separation of concerns. What I take away from this article is the belief that the "big picture" of Whidbey is to eschew n-tier development, and "flatten" the development model. Where does data validation and business rules fit in? Presumably it's in the same flat model somewhere.

As it stands, ASP.NET 1.x is already maligned for flattening the development model, where the codebehind accesses the database directly (no business layer or DALC in sight), and then binds the data to its presentation control. Now, it seems that the Controller (codebehind) has been banished, and the View and Model are in bed together.

Of course, I may be completely wrong about this. However, the articles trumpeting Whidbey's ease-of-use seem to confirm this flattening of the development model. This returns me to my main concern ... clever details, flawed big picture. Penny-wise, pound-foolish.

A further example of this concern is the introduction of Master and Content Pages. Here again there seems to be an intertwining of what should be separate concerns: data and presentation. Not only does this seem to flatten the development model in a way that disregards n-tier development, it also seems to split data in a most undesirable manner. To explain what I mean by the splitting, say that I am designing an online CD retailer, and a web page looks as follows:

The Business layer may return a single XML file (the Model) as follows:

    <page>
        <album type="Active" id="4" title="Body Language" Price="15" PriceUnit="USdollars" .. />
        <album type="OtherByArtist" id="2" title="Album 1" />
        <album type="OtherByArtist" id="3" title="Album 2" />
        <album type="OtherByArtist" id="4" title="Album 3" />
    </page>

In ASP.NET 1.x, the codebehind (the Controller) then apportions this data using between the server controls, thus forming the page (the View). This is cool, easy to understand, and logical.

Now, Whidbey enters the picture. Now this simple MVC pattern is wrecked. The Model is being carved into pieces to suit the needs of the development tools:

Again, the detail (the idea of master pages) seems cool, but the bigger picture seems flawed. The Model should not be split just to serve the needs of the development tool.

To my mind, the Model should remain intact. Whether its destination .aspx page is a single file or a combination of Master and Content should be of no concern to the Model. Nor do I think it should be of concern to the Controller. The Master/Content mechanism is a concern of the View only.

Hence, I think the following is more logical:

Here, the Model is never split. Also, the Controller (the codebehind) doesn't need to know whether the destination Page is a single page or the result of a Master and Content combination. The controller then binds the data to the server controls on the Page ... just as occurs in ASP.NET 1.x. It is a conceptually simple idea.

Indeed, it mimics the simplicity of XML ... a single XML data file, transformed with a single XLST document. (Both the XML and the XSLT might be the result of earlier combinations or transformations, but whether this is the case is irrelevant to the pending transformation). So the current transformation is a single, simple action ... there is no arbitrary splitting of the XML data or the XSLT document.

Again, I may have the details altogether wrong. But, from the articles I've read, I am most concerned about this mechanism. Clever but flawed. Penny-wise, pound-foolish.

I won't go on. While all the details of Whidbey sound great, the big picture is either missing or flawed. (Or, should I say, the current literature seems to focus on the minutiae, without showing how they fit into a cohesive big picture.) How is this flattening development model a good thing? Spaghetti code in a page was rightly criticised ... but now it seems Whidbey is throwing data, validation, business concerns, controllers, views, security and everything else onto the page!!!! ASP.NET seems to be regressing in the direction of monolithic applications where there is no separation of concerns.

I happen to *love* ASP.NET. Every day I am amazed at its richness. I would still be working as a graphic designer if I had not fallen in love with ASP.NET, and decided to learn this great new technology. But I have real concerns about its direction.

Thanks for letting me raise my concerns.

I am aware that to suggest Microsoft is missing the big picture will come across as highly arrogant. However, my argument is that if I can't see Whidbey's simplicity or big picture, then I doubt any newbie will see them, either. Maybe there need to be some articles that sell the steak, not the sizzle?

Thanks for your work on ASP.NET. It's a joy to use.

Kind regards,

Alister Jones

From: Bertrand Le Roy
To: Alister Jones
Sent: Thursday, May 06, 2004 2:46 AM
Subject: RE: SomeNewKid2's feedback on Whidbey

Thanks for the feedback. Let me explain what the big picture really is, but your feedback is very interesting in that it gives us an idea of how our communication is actually perceived and how we should tune it to be better understood.
Let me first state that I understand your concerns, having been an architect in a small web shop before I was hired by Microsoft.

1. Database cache invalidation and n-tier architectures

Here, in an n-tier architecture, you would use an ObjectDataSource that takes its data from your business layers, not a SqlDataSource. The database cache management would take place in the DAL: the declarative cache invalidation does have its procedural equivalent that can be called from any layer, and the DAL if it exists is of course the right place for that. Chances are all the .NET O/R frameworks on the market will quickly seize the opportunity to use this feature.
Our main problem here is that when you write an introductory article, you tend to flatten out the model and show quick and dirty stuff instead of solidly architectured full-blown applications. But we could probably mention that the examples in the article do not represent what you would do in a bigger application, and indicate what would be different.
The beauty of data source controls is that they are interchangeable: you can build a prototype with a SqlDataSource and switch to an ObjectDataSource later.
The article is actually wrong on one point: the CacheDependency class is not new to v2.0: it’s always been there.

2. Master pages

First, let me point out that MVC has never been a pattern that fit well in ASP.NET. Actually, Martin Fowler introduced in “Patterns of enterprise application architecture” the Page Controller pattern that better reflects a typical ASP.NET application. There are some MVC frameworks for .NET, but they are somewhat convoluted and sacrifice most of the cool things of ASP.NET on the MVC altar.
Now, a page controller is not that different and your points still stand.
The question I want to ask you, though, is why do you want to have dynamic data in the master? The master should only contain layout and general contents, not specific data. What would make more sense in your example would be to have two content place holders in the master (one for the album list in the left margin, and one for the album contents on the right). This way, the page controller stays in charge of all the data (in one piece), the content page displays the data in relevant controls (and does not have to manage the general controls of the master) and the master is just responsible for the general layout of the site.

I think that it is in fact better architecture and separation.

Please do go on if you have other concerns. I’d love to read what you have to say about the other subjects you briefly mention at the end of your mail. For example, validation is a great architectural subject because UI ergonomics actually get in the way of cleanly separated architectures. Still, there are some ways to have both. About security, the Whidbey architecture is actually much better architectured than what we had with v1.1 thanks to the extensive use of the provider pattern.

I also wanted to thank you on behalf of the team for your great participation in the ASP.NET forums.

Bertrand

From: Alister Jones
Sent: Wednesday, May 05, 2004 6:37 PM
To: Bertrand Le Roy
Subject: SomeNewKid2's feedback on Whidbey

Hi Bertrand,

I plan on spending some time today re-reading the articles about Whidbey. So tonight I'll expand further on the concerns that I have. Again, thanks for the invitation to do so.

I thought however I should close the two points we've talked about. Otherwise the next email would awkwardly address old concerns as well as introduce new ones.

1. Database cache invalidation and n-tier architectures

Thanks for the explanation. I had not heard of an ObjectDataSource before. Now I can readily see how the asp:SqlDataSource supports quick-and-dirty and/or prototypes, and an asp:ObjectDataSource supports n-tier architectures. So explained, I can see how clever it is ... supporting both flat and tiered design, using the same declarative and/or programmatic model.

I appreciate the point that articles tend to use flat-model examples for the sake of simplicity. After all, most readers can extrapolate on the examples, and see how they apply in a more complex scenario. But Whidbey is different for two reasons. First, the target audience are those who do not have Whidbey, and such readers do not necessarily have the "other pieces of the puzzle" necessary to extrapolate (such as ObjectDataSources). Second, the target audience must surely be intermediate and professional developers ... the ones Microsoft are "preparing" for Whidbey. Beginners and hobbyists could not care less about a pending technology, when they've got their hands full with the current versions. *IF* that is the correct target audience, then the flat-model examples probably under-sell Whidbey. After all, the asp:SqlDataSource in the article looks remarkably like a declarative DataSet, and intermediate and professional developers will dismiss this. "The data source can now be a declarative DataSet as well as the programmatic DataSets I now use. Big deal." Which I think further exemplifies my concern: a focus on details, with no big picture in sight. 

2. Master Pages

I've actually read the excellent Enterprise Solution Patterns Using Microsoft .NET document. So I understand what you mean about ASP.NET implementing the Page Controller pattern.

I knew when I was talking about MVC that I should state I mean it in a conceptual sense, not as a design pattern. Even if the pattern is not applicable, I hazard a guess that most developers conceptualize their codebehind and page as being a separation of concerns, a Controller and View respectively.

You asked why I would want dynamic information in the Master Page. I would not. However, a Peak at Whidbey shows a breadcrumb trail in its master page. A breadcrumb trail is dynamic metadata about the content ... page-specific data. (I literally stopped and thought about this for a few minutes...) Now that I think more about it however, that breadcrumb is likely to have come from a separate site-structure data source - the same data source that is used to populate the tree-view site navigation in the Master Page. So, yeah, it seems I left that article having read the wrong message.

But what then is so great about Master Pages? Both conceptually and code-wise, I cannot see how they are easier than existing options. Look at IBuySpy - the Master Page stuff is on a single ASPX page; the dynamic content comes from self-contained User Controls. For a beginner, or a developer coming from a PHP/ASP environment having used includes, User Controls are easy to understand and use ... User Controls on a Page are like Lego blocks on their green base. Conceptually simple. But Master Pages and regions, dynamic masters and dynamic regions, nested masters and nested regions ... Holy Labyrinth, Batman!

I *do* understand the benefits of Master Pages, as I use MetaBuilders own implementation. However, in terms of increasing the take-up of ASP.NET, will this help? Templating mechanisms are hardly rocket-science, and intermediate and advanced users can easily build or obtain their own. But for beginners and hobbyists (which represents your *entire* future market) it seems an unnecessary complexity. ASP.NET 1.x represents a solid application framework. But with Master Pages, Whidbey seems to be moving into the domain of the application itself. Is this appropriate?

Finally

You're welcome to reproduce in your blog anything that I write. Participating in the ASP.NET forums has been a tremendous way to learn ASP.NET. I'll email you later today regarding my other thoughts about Whidbey, the steak and its sizzle.
Thanks for replying. I'm not expecting free, personalized tuition, so you need not address each of my concerns. (Though I thank you for having taken the time to do so following my first email.)

Kind regards,

Alister

From: Alister Jones
Sent: Monday, May 10, 2004 4:27 AM
To: Bertrand Le Roy
Subject: Further feedback from SomeNewKid2

Hello again, Bertrand.

I want to open by saying that I love ASP.NET. Its richness is amazing, the community support is humbling, and Microsoft's commitment to its developers is superlative. I offer my concerns for the same reason a father expresses concern for a child — I want to see ASP.NET succeed and grow.

I'd like to offer with two examples, that I'll then apply to Whidbey.

1. Improv

First, here is an abridged quote from Joel Spolsky, a former program manager at Microsoft (the full article is here):

"When we were designing Excel 5.0 ... we only had to watch about five customers using the product before we realized that an enormous number of people just use Excel to keep lists. They are not entering any formulas or doing any calculation at all! We hadn't even considered this before.

While Excel 5 was being designed, Lotus had shipped a "new paradigm" spreadsheet called Improv. According to the press releases, Improv was a whole new generation of spreadsheet, which was going to blow away everything that existed before it.

Of course, Improv is now a footnote in history. Why? Because in Improv, it was almost impossible to just make lists. The Improv designers thought that people were using spreadsheets to create complicated multi-dimensional financial models. Turns out, if they asked people, they would discover that making lists was so much more common than multi-dimensional financial models, and in Improv, making lists was a downright chore, if not impossible."

I am concerned that ASP.NET is becoming the Improv of web development. PHP is the Excel. ASP.NET makes the difficult tasks possible. But PHP makes the common tasks easy.

As websites proliferate, an increasing number of websites will be designed by beginners and hobbyists. As the number of web authors grow, so too will the market share of PHP. PHP may not be as "clever" as ASP.NET, but it's certainly easier. Improv may have been cleverer than Excel, but that was irrelevant. Excel made the common tasks easy.

This is why I'd call for ASP.NET to be "dumbed-down" ... with a focus on making the common tasks as easy and intuitive as possible. (The new Login server control succeeds here.)

2. A hammer

Yesterday I wanted to hang a picture on my living room wall. I went to the first hardware store, and explained to the attendant my need. "I want to hang a picture on my living room wall." The attendant replied, "We have just what you need .. a 10-ounce titanium-finished implement with a curved claw, iron head and cushioned recoil ... and a two-inch single-headed fastening device." Panicked, I yelled, "Look out behind you!" As he spun around, I ran to the exit.

I went to the second hardware store, and again explained my need. "I want to hang a picture on my living room wall." The attendant replied, "We have just what you need ... a hammer and a nail." The picture looks good on my living room wall.

I think Whidbey and its evangelists are too close to the first hardware attendant. If we read about ObjectSpaces, we learn that "ObjectSpaces is ... an Object/Relational mapping tool fully integrated with Microsoft ADO.NET ... (that) puts an abstraction layer between your business tier and the raw-data tier where the physical connection to the data source is handled."

Um, thanks, but I just want to buy a hammer.

If we visit PHP we hear, "One of the strongest and most significant features in PHP is its support for a wide range of databases. Writing a database-enabled web page is incredibly simple."

Thanks, that's just what I need.

This comparison could be dismissed as overly simplistic. But is it? A tradesman can distinguish between a professional's hammer and a bargain hammer just by looking at them. He doesn't need to be hit over the head with the hammer, literally or metaphorically.

An intermediate or professional developer will recognise the difference between PHP and ASP.NET just by looking at the samples. But beginners and hobbyists (surely the fastest growing slice of the web development pie) just want some plain talk.

Which brings me to the same conclusion as the first analogy. To increase take-up, ASP.NET needs to be "dumbed-down".Not in ability, but in delivery. If Stephen Hawking were addressing high school students, he wouldn't "unlearn" his knowledge and ability ... he'd just choose simpler words and simpler pictures in order to deliver his fantastic story.

Turning now to Whidbey itself.....

ObjectSpaces

I understand the concept and benefit of an O/R mapper. Apparently though, it's hardly a trivial exercise to implement ObjectSpaces. There's a Peanuts comic strip where Charlie Brown suggests that "the secret to life is replacing one problem with another". This seems an apt description of ObjectSpaces. The not-too-hard if repetitive work of saving and loading data objects is being replaced with the apparently hard work of implementing and working with ObjectSpaces. How many data objects would you have to use in an app before ObjectSpaces justifies its development complexity?

Or, asked another way, how many ASP.NET developers in 100 would actually use ObjectSpaces? One or two in 100? Five at most? If so, why is this aspect of Whidbey being pushed so forcefully? Sure, it's mighty helpful to the small percentage of developers who can take advantage of it, and as such is a solid addition to the ASP.NET framework. But no-one else cares. Consider the Improv example. While Whidbey is pushing ObjectSpaces, the rest of the world just wants to display some data ... blog entries, photo albums, company products, etc.

If this argument is valid, then it would be a much better utilization of the ASP.NET's architects' time and evangelists energy to focus on the display of data ... the DataGrid and its data-bound brothers. On the ASP.NET forums, the DataGrid forum reports over 15,000 problems for developers!!!! For such a fundamental aspect of dynamic websites — the display of data — this is worrisomely high. The DataGrid is clearly too complex. Powerful, sure. Flexible, sure. But simply too complex for the majority of developers.

Just as we would fix a busted radiator in a car before we worried about installing electric windows, we should address the problematic DataGrid and its brothers before we focus on smoothing the operation of data mapping. It will make a bigger difference to more people.

Master Pages 

Looks good. (Though I am trusting that Master Pages use the same page execution model as Pages and User Controls.)

Themes and Skins

Everything else in Whidbey looks good. I might suggest that some additions are somewhat frivolous, and others too complex, but I can see their underlying value.
However, Themes and Skins seem to me a completely misguided implementation. The encapsulation of layout and styling (Themes and Skins) is a solved problem with CSS.
If we visit the CSS Zen Garden we see over 270 completely different layouts and styles applied to the exact same markup. These 270 variations are achieved by changing a single external CSS file. How many files would need to be changed with Whidbey's implementation of Themes and Skins? The master page, the content page, the theme skin, the controls' skins, the theme provider and every single element that is to vary from the default theme skin. Whidbey's implementation looks like a maintenance nightmare.
CSS allows you to create one or many files (each cached on the client) that style the entire site. If one were to argue that Whidbey offers finer control, I'd suggest they look again at the CSS Zen Garden. Every page has the same mark up. Yet every single tiny detail can be changed in the external CSS files. CSS is as pluggable and flexible as an HttpModule ... it passes a magic wand over the HTML response. It is a simple, clean, well-understood, well-documented, well-supported styling mechanism. Why oh why replace it with what is effectively a proprietary definition of what it means to style a web page?
Every other aspect of Whidbey I can appreciate. However, I think that the Themes and Skins implementation is so fundamentally flawed that I sincerely hope it is jettisoned. (Or depreciated in ASP.NET 3 and replaced with CSS.)

Personalization

I don't understand this concept's place within the bigger picture. Is personalization just applied Identity? Is a Profile just a collection property of User.Identity (even if the user is not authenticated, and identified only through a cookie)? Does personalization apply only to Web Parts, or to all controls? Is it like an Interface implemented by server controls? Or is it just a specialized collection? Personalization seems a nebulous concept.

Web Zones and Web Parts

I don't understand the place of Web Zones and Web Parts within the bigger picture, either.

Say I'd like my users to be able to customize the view of their financial statements? Is that a theme or a web part? Or a themed web part? Or a personalized theme? Or something else? (I only want to buy a hammer!)

It seems that to present this user's financial statement, I may have to draw out his data according to his authentication and subject to this authorization, maybe put it on the page in a SqlDataSource, then attach it to a DataGrid, which must be inside a web part, inside a web zone, set out according to the theme, styled according to the skin, and controlled by personalization.

Jesus wept! (I did too, but it's more telling when He weeps.)

I'll call for it again, ASP.NET needs to be "dumbed down". Make the common tasks easy. Don't let ASP.NET become the Improv of web development.

The need to simplify the framework.

In Microsoft's own Enterprise Solution Patterns Using Microsoft .NET, it provides the following quote:

"An architect's first work is apt to be spare and clean. He knows he doesn't know what he is doing, so he does it carefully and with great restraint. As he designs the first work, frill after frill and embellishment after embellishment occur to him. These get stored away to be used 'next time'. This second system is the most dangerous system a man ever designs. The general tendency is to over-design the second system using all the ideas and frills that were cautiously sidetracked on the first one."

— Frederick P. Brooks, Jr. in "The Mythical Man Month"

Is Whidbey over-designed using all the ideas and frills that were cautiously sidetracked in ASP.NET 1.x? It seems so.

Personalization and Web Parts. Do they really belong in the low-level Framework? An Application Block I would understand, but part of the Framework? It truly comes across as an unnecessary frill.

Contrast this to the new Login server control.

        <asp:Login runat="server" />

Brilliant. Simplification and rationalisation of a commonly used device. Authentication belongs in the framework, and you could hardly provide an easier way to obtain credentials from the user. This new server control is, to me, a superlative example of ASP.NET's powerful simplicity.

How many of Whidbey's new features are frills? Just because they may end up being used does not justify their inclusion. A gardener with poor taste might place a pissing boy statue beside the pool of a first millennium Greek mansion. An equally tasteless resident might flip the switch and turn on the statue's pissing mechanism. But just because it is used does not justify the statue's inclusion. It simply should not be there.

The need to simplify the message

ASP.NET 1.x introduced a wonderfully simple, yet powerful and extensible model. It has Pages and Pagelets, onto which we place server controls. Simple. Easy to grasp.

But Whidbey is fracturing this conceptually simple model. Even if the model is the same, the introduction of new terms and concepts obscures the model. I honestly cannot tell whether the model is the same or not.

I want to again apply the analogy of buying a hammer. Australia's major hardware retailer sells over 100 types of hammer. If you said one hammer was designed for use on brick walls, I might reason that its recoil has been dampened. If you said another hammer was designed to support hobbyists using balsa wood, I might reason that it is small, and perhaps with a rubberised head. No matter what hammer you might describe, the mere fact that I know you are describing a hammer means that I can intuit what it looks like, how I'd use it, and its likely features.

Some ASP.NET 1.x server controls implement the IPostBackDataHandler interface ... but the simple conceptual model was not broken by naming these controls WhizzBangUserDataHandlers. The Calendar control could have been called a DateDisplayWidget, but the simple conceptual model was not broken there, either.

Peter Blum sells validation server controls. I've never seen them, but I already know what they are and how I'd work with them. They'd go on the Pages and Pagelets, just like every other server control. (Would he have sold as many if he'd called them AssuranceAssets?)

Whidbey breaks the conceptually simple model introduced by ASP.NET 1.x. No longer do we have a simple page surface on which we place server controls. The page has fractured into Master Pages and Content Pages and Themes. The server controls too have fractured into multi-layered Zones and Parts and Profiles and Skins.

Please, call a server control a server control. Call a hammer a hammer. To do otherwise is to add unnecessary complexity. If they're not server controls, then why not? Do they do anything so special as to justify living outside the existing, simple server control model?

ASP.NET 1.x was celebrated for introducing a simple, easy to understand, yet mighty powerful programming model — a Page or Pagelet, onto which we place server controls. But this beautiful, celebrated model is about to be fragmented by Whidbey. How can this fragmentation and complexity be a Good Thing???

Please, keep the model simple, keep the message simple.

I had planned to offer some thoughts about what I see as the potential to simplify ASP.NET's application and page models. However, this email is already way too long. My apologies — I guess we all rabbit on with topics that we are passionate about.

I love ASP.NET. My concerns outlined here are a call for restraint, not a call for fundamental change.

You know, I wrote the above email on the day that I said I would. However, I didn't send it, as I felt it was too critical. ASP.NET is fantastic. I felt like I was criticizing a pimple on an otherwise beautiful woman. But Whidbey makes me extremely uncomfortable, and I've spent the last three days thinking about why that is. It's 3am, and I've finally hit on why I am so worried about ASP.NET ... it already has a helter-skelter feel to its design — an arbitrary feel — and this feeling is being multiplied with Whidbey.

We might explain to a newbie that in order to set the culture of a page, we merely need to add a parameter to the Page directive. After all, we're defining how the page is to be viewed, so it's logical to set the culture on the page itself. This is a solid example of the strength of ASP.NET's declarative programming model. Simple. Easy to grasp. Easy to employ.

We might then explain to the newbie that he can also define the authentication and authorization mechanisms to check the user's permission to view the page. "Ahh," he says, "Let me guess — more parameters on the Page. Perhaps Authentication='Forms' and RoleRequiredToView='Manager,Developer'?" We would need to say, "No, authentication is set in the web.config, and authorization must occur in the page's code." He would be justified in asking, "Why? Why can globalization be set declaratively on the page, yet its authentication and authorization cannot?" What's our answer? "Sorry. It may seem a bit arbitrary, but that's the way ASP.NET works."

I *do* know why. But it does feel like an arbitrary distinction, don't you think? Globalization, authentication and authorization are all settings that define the user's view of our page .. yet they are implemented completely differently ... declaratively on the page, a configuration setting, and in code, respectively.

Speaking with a more advanced developer, we might proudly say, "Hey, Microsoft has released a fantastic Exception Management Application Block. And Whidbey introduces personalized Web Parts as server controls. Cool, huh?" He might be puzzled. "Hang on ... exception management, which is a fundamental aspect of a framework, is released as an "Application Block"? Yet personalizing a part of the web page, which is the domain of the application, is built into the Framework? Isn't that the wrong way around?" It is the wrong way around. There's a truly arbitrary feel to how ASP.NET's functionality is being implemented.

"How about asynchronous invocation of web services?" he asks. "Oh, that's available as an Asynchronous Invocation Application Block. But we've added Skins to the framework. Cool, huh?" Again he's puzzled. "Um, thanks, but I can skin my site fine with CSS, thanks. But, you know, I could really use asynchronous invocation in the framework."

"Okay," he says. "What about a filter on the output? Can I cleanse it of profanity?" Our answer may be, "Sure. Write an HttpModule." Again, we get a puzzled response. "Input validation and response validation can be set declaratively on the page, but output validation is implemented a different way?" Again, "Yes. It may seem arbitrary, but that's the way ASP.NET works."

There's simply a very helter-skelter, or arbitrary, feel to the way ASP.NET is developing. Aspects that belong in the Framework appear as Application Blocks. Yet stuff that's the domain of the Application are being added to the Framework (why not Application Blocks?). Some items are invoked declaratively. Others, through the web.config. Others still only possible in code. Some client-side stuff is handled by the Framework, others not.

ASP.NET started with such a wonderfully simple model: a Page onto which we place Server Controls. Yet it suffered from some seemingly arbitrary distinctions. (Globalization can be set declaratively, authorization cannot.) Surely ASP.NET v2.0 ... the opportunity to rationalize ASP.NET v1.x ... should focus more on core aspects of the framework rather than adding frills (particularly as the frills themselves are being added in the same ad-hoc fashion)?

Surely Whidbey offers the chance to remove some of these arbitrary limitations? A chance to fortify the wonderfully simple, yet extraordinarily powerful application and page model. Imagine the following:

    <%@ Page Language="C#"
             Culture="en-US"
             Authentication="Forms"
             ValidateRequest="True"
             Theme="Bank" %>
    <% OutputFilter 
             Name="Profanity" 
             Provider="PeterBlum.ProfanityFilter" %>
    <% OutputFilter 
             Name="KeywordHighlight" 
             Provider="Metabuilders.KeywordHighlight" %>

    <asp:DataGrid id="FinancialRecords"
             RoleRequiredToView="Customer,Manager,Developer"
             RoleRequiredToUpdate="Manager,Developer"
             RoleRequiredToDelete="Manager"
             UserCanModifyView="True"
             UserCanModifySkin="True"
             DefaultSkin="Statement">
    </asp:DataGrid>

Here, we've removed all of the arbitrary limitations of working with ASP.NET. Authentication, authorization, personalization, validation, filtering, themes, skins are all available to be set declaratively on the page. There is no arbitrary requirement to use the web.config or HttpModules or Application Blocks. It all conforms to the simple, existing ASP.NET model.

In this way, I think the introduction of the SqlDataSource, ObjectDataSource and Login server controls are brilliant. They add power to ASP.NET without adding complexity. Quite the contrary ... they simplify development, both conceptually and in implementation.

You asked me how I felt about input validation being on the page. I think it's perfectly valid, and consistent with the ASP.NET page model. But why arbitrarily allow declarative input validation, but not provide for declarative output validation or filtering?

The Provider pattern looks very good. But if some providers are set declaratively (such as used by the SqlDataSource), others require editing the web.config, others still invoked in Global.asax ... then the Provider pattern will suffer from helter-skelter implementation. Must they be different? Is this complexity truly required?

I *do* understand the HttpApplication pipeline, and the order of its events. I *do* understand why things are ordered the way they are. But is there really any architectural reason why a Page cannot define its authentication mechanism? Give the choice to the developer. Advanced developers can register it in the web.config and allow it to alter the HttpContext object before it gets to the HttpHandler. Beginners, hobbyists, and intermediate developers can set it declaratively on the Page. Surely the Page object's Init handler can instantiate and invoke the same HttpModule? If not, wouldn't it be a more valuable update to the ASP.NET framework than is, say, Web Parts? Web Parts are going to be the new DataGrid ... spawning 15,000 queries from developers who simply cannot work with them. Why introduce complexity rather than introduce simplicity?

I'm going to summarize now ... with an apology for the length of this email. I know it's horribly long. For that, I'm genuinely sorry. I only hope its length underscores how passionately I feel about the need to simplify ASP.NET.

Please, focus on making the common tasks easy. Be the Excel of web development, not the Improv.

Please, simplify the message. If you want to increase take-up, call a hammer a hammer. Don't obscure ASP.NET's powerful simplicity with GeeWhizz terminology.

Please, don't add all the frills and embellishments that were so prudently avoided with ASP.NET 1.x.

Please, remove the arbitrary implementation limitations, and allow ASP.NET's simple yet powerful declarative programming model to shine through.

Please, see Whidbey as the opportunity to refine, strengthen and extend the simple model. Don't break this model by fragmenting the page and fragmenting its controls.

Please.

Kind regards,

Alister

From: Bertrand Le Roy
To: Alister Jones
Sent: Tuesday, May 11, 2004 6:49 AM
Subject: RE: Further feedback from SomeNewKid2

Thanks again for the great feedback and for taking the time to write all that down. Your implication in the community and your feedback are very much appreciated.

I really don’t think we’re breaking the ASP.NET model in any way with Whidbey and I’ll try to answer your concerns. We may have more of a communication problem, which is not really surprising as we’re only starting to explain a tremendous amount of work that’s been going on for the last few years. While everything seems clear to us, anyone that is exposed to such an amount of information can be a little overwhelmed by it and have trouble seeing the big picture. Perhaps it is just an indication that we should explain the big picture more, and isolated details less. Only trouble is, people want to touch the product and use it, and for that to be possible, we have to explain small, seemingly disconnected details.

I can’t help noticing that in this new mail, you’re asking us to keep it simple and use plain concepts instead of complex stuff like ObjectSpaces, whereas in a previous mail, you were pointing out that our papers on data sources were simplistic and did not encourage multi-layered application design, which is a little contradictory. Well, in fact we have to do both. We are trying to address both publics.

And that’s where I cannot agree with your hammer analogy. Programming tools are fundamentally different in that they can present a different face to different users. So in fact, using ASP.NET is like having a hammer that changes as your needs change. But you’re right, to people who just need to hang a frame on the wall, we should just say “here’s a hammer”. And they may later discover that it’s much more than a simple hammer. ASP.NET would be more like a Swiss army knife but even that is not very relevant because you wouldn’t use a Swiss army knife to hang a frame or to do any serious work. Well, you wouldn’t use ASP.NET to hang a frame either ;)

And PHP is not at all easier. It’s just something people are more used to, but if you have to teach web development to someone who does not have any web experience, ASP.NET is much easier to get, and Whidbey even more so. We have put a great emphasis with this version on solving the common scenarios without writing a single line of code. Now, what is a common scenario for someone might not be that common for someone else.

So your remarks on Improv are interesting, but I think making ASP.NET the Excel of the web is exactly what we’ve been trying to do with Whidbey. Over-engineering is something that doesn’t happen frequently at Microsoft these days because we base most of our designs on usability studies and customer feedback (such as yours). So a feature that’s not needed by a significant fraction of our users or that’s not discoverable or usable just goes away pretty fast. But as our user base is so large (we’re talking millions of developers here), we have to answer a very wide range of demands, from the hobbyist developer to high traffic sites such as MSN.

About ObjectSpaces, well, this is not really part of ASP.NET, but more the .NET Framework and Sql Server. It’s an abstraction layer (that you don’t have to use – let me rephrase – that you shouldn’t use if you don’t know you need it) and it doesn’t belong in the presentation layer… So that’s right, most users won’t use ObjectSpaces. But there is a need for such a tool in a significant portion of our audience, so we have to answer that need. Now, we’re certainly not saying that everyone should use it in all circumstances.

If you want to realize the PHP ambition, just drop a SqlDataSource on your page, a GridView, DataList or DetailsView and you’re done… Without writing a single line of code. PHP is so very far from that… I think we’ve dumbed it down pretty well.

By the way, the improved DataList you’re asking for is Whidbey’s GridView. Take a look, I’m sure you’ll like it. It’s simpler, much easier to connect to live data (read and write) and does not need a line of code in most situations.

Now, themes and skins. I’ve seen this very same feedback before from another advanced user of the framework.

Well, I think you’re very wrong on this point.

CSS and themes/skins are not exclusive of one another: you should use CssClass whenever possible when writing a theme. CSS and themes complement each other. Actually, a theme should IMHO always contain a CSS file.

But there are a few things CSS can’t do because they are linked to HTML tags and attributes and not to WebControls and their properties. And while some people have done truly amazing things with CSS, it is very complex and does not have a good extensibility scenario (the CSS standard has to go into a luxury of details and special cases to be complete and still fails to be at this day).

Now, Themes act at the same level of abstraction as WebControls. This means for example that you could perfectly well in a theme define a template for some custom control you’ve written. No way you can do that with CSS. What I mean is that themes solve the problems that CSS can’t because they act at a different abstraction level and are essentially extensible.

Now, every time you define a visual style in a theme, use a CSS class.

And themes are even more pluggable than CSS are (at the control level, at the page level, at the site level or even higher).

And they’re so much easier to write: configure a user control in VS, copy and paste the resulting code into your theme file, and you’re done. You’re using the same syntax to write a page and to write a theme.

I just love this feature.

Personalization only applies to Web Parts. When you develop a Web Part, just mark a property with the Personalizable attribute, and it will get automagically persisted by the personalization provider. See it as a very easy way to get persistent WebControl properties per user.

It is different from the strongly-typed user properties that you can declare in web.config. These are not attached to any control, but give you an easy way to manage personal information (e-mail, telephone, birthday, or whatever you may need) without having to worry about the underlying storage. Once again, it’s an easy answer to a common need.

WebParts answer the very difficult common needs of Portal applications. In much the same way in v1 we had plain HTML, HtmlControls and WebControls giving more and more server abstraction and built-in services in the base class, WebParts are WebControls with more services built in the base class. As these services are not needed by all WebControls, WebPart is a new base class under WebControl.

As always, if you don’t feel the need for the additional services WebParts offer (automatic persistence of per-user property values, drag & drop support, property editing in the web page, data connections between parts, etc.), it probably means you don’t need them, so don’t use them.

The WebPart concept was already implemented in SharePoint, but for a number of technical reasons it was hacky in some ways. Integrating them into the framework enabled us to solve difficult problems that the SharePoint team faced.

By the way, the very same user who gave me the same feedback as yours on CSS and themes is the developer of a WebPart-like framework built on ASP.NET v1 and he seems to be pretty pleased that we included WebParts in the framework. So you see, your needs are not the same as your neighbourgh’s, but it doesn’t mean we shouldn’t address them.

What belongs in the framework, and what belongs in application blocks? I agree with you on the whole, but there are technical reasons why we would do something as an application block or as a core framework feature, namely the need to integrate into the Page lifecycle. Now, this is a problem in itself, and we’re working on ways to make the framework more pluggable in the future so that third parties can do what only we can do today (like mess with the lifecycle).

And of course, application blocks are sometimes a way to release a feature out of band, but most of the time, they are reference implementations of common design patterns more than features.

I’m not sure what you’re referring to when you ask us to call a server control a server control. WebParts are a name that preexisted in SharePoint. And we call a server control anything that derives from Control. A Web Control is anything that derives from WebControl. A User Control is a Control that derives from UserControl. And a WebPart is a WebControl that derives from WebPart. For technical reasons, a master page derives from UserControl, but it’s less confusing not to expose that implementation detail too much and simply refer to them as a different concept. Content pages are pages that have a master. Themes, profiles and skins are just not controls. We cannot oversimplify our exposition of the model to the point where it becomes wrong.

And I think our documentation is pretty consistent on these points.

Now, I pretty much agree with you on the rest of your message, and I’m forwarding it to the right people so that we integrate your ideas into the next version of the product.

I think these e-mails are really interesting and probably not just to you and me. Do you have a Blog? I think the best way to publish this and call for interesting comments would be if you and me published these mails in our respective blogs. I could publish on mine, but it would be so much nicer if you published your own comments on your blog. If you have one.

Thanks,

Bertrand

From: Alister Jones
Sent: Tuesday, May 11, 2004 4:27 AM
To: Bertrand Le Roy
Subject: Further feedback from SomeNewKid2

Hi Bertrand,

Only a quick email this time :)

First, I again appreciate you taking the time to illuminate the bigger picture, which I can find a bit dark.

I was very cognizant of the inconsistency of my two emails regarding placing intelligence on the Page itself. When you explained the same model but different use of the SqlDataSource and ObjectDataSource web controls, it made me recognise that the Page can be a seen as an Application surface, not just a UI surface. And that idea, the Page as an Application surface, made me start thinking about this concept ... and whether its declarative programming model could be extended (such as declaring the Authentication and Authorization provider, per my example).

As I pointed out in my first email, I am a self-taught developer, and ASP.NET is my first environment. So, sometimes I don't understand a concept until it's explained in simple terms. This is where there's a conflict ... the need for simplification against the risk of "oversimplifying our exposition of the model to the point where it becomes wrong." I compliment you on the eloquence of that statement.

You may well be right about Themes and Skins. Your idea that they work at a "different level of abstraction" than CSS, and complement CSS, is a point well made and well taken.

I don't have a Blog. If I did, I would not write about Whidbey. I don't have the product and, more importantly, I am not an advanced developer (I only learned what a Pattern is a few months ago). I really only raised my concerns because you invited me to do so, and to justify my forum statement that Whidbey will be no easier than ASP.NET v1.x.

Your email was very interesting, and has indeed quelled some of my concerns. In fact, I feel somewhat guilty that your explanations are limited to this personal email exchange ... they should have a much wider audience. Again, if you wish to reproduce my concerns and respond to them on your blog, you're very welcome. Where is your blog? Google doesn't know, so nor do I :)

I've learned a lot from you. Thank you. And the very process of trying to delineate my concerns has forced me to think about ASP.NET's fundamental model. It's been interesting. I've often thought about writing an www.asp.net feature article, explaining the model in simple terms. Maybe it would be worth doing so, with an epilogue on how Whidbey builds on this model?

Thanks again. And thank you for your work on ASP.NET — I love it.

Kind regards,

Alister