That 90′s Show and MonoRail

July 21st, 2007

Seems that there’s a new blog devoted to promote alternatives to WebForms. Way cool, for sure. But fundamentally wrong. Starting with the post Thou shalt not mix presentation and code. Quoting:

In the early days of web development, it was common procedure to write application logic inside your HTML pages using ASP, JSP, PHP, Perl or another early web application development framework.

Yeah! Couldn’t agree more. Assuming that he mean Business Logic, though..

Of course, back then we didn’t know any better, but don’t you just cringe when you see something like this:

<table border="1">
<%
For I = iRecFirst To iRecLast
Response.Write "<tr>" & vbCrLf

For J = iFieldFirst To iFieldLast
Response.Write vbTab & "<td>" & arrDBData(J, I) & "</td>" & vbCrLf
Next
Response.Write "</tr>" & vbCrLf
Next ‘ I
%>
</table>

Er.. this is presentation logic. And albeit you could write this in a more elegant way, there’s nothing wrong with it.

Microsoft saw the need for something better and came up with ASP.NET

They came up with WebForms, yes…

Indeed, at first glance it was a big improvement, urging developers to cleanly separate code from markup by providing the “code behind” way of programming. But if you look closer it was still a mess.

Absolutely. And not only that. They tried to come up with a stateful paradigm for web development. Interesting, but that led to problems. Much have been written about it, so I’ll assume the reader knows what I’m talking about.

[...]
I am still a little annoyed by the lack of separation between the actual presentation (markup) and the code controlling the presentation. The other day I was checking out MonoRail and was browsing through the samples, and I saw a lot of ASP-like stuff in the HTML markup. Loops, method calls, the whole shebang. I felt thrown back to the nineties.

Honestly, I felt the same thing when I started to play wth Ruby on Rails, back in 2004. Took some time to admit that there’s nothing wrong with that approach. You’re not mixing business logic, that’s all presentation logic, and they belong together.

Now you can say that you want a more dramatic separation between the presentation and the presentation logic. I second the fact that some project set up can greatly benefit from that (a team with very distinct roles). Dynamator is something that provides a solution for this very problem.

If I had to approach this challenge I’d use something I’ve planned for the IronPython view engine, which is relying on xml and namespaces to control logic. This is very strict, and I’m sure some (possibly most?) users wouldn’t like that.

Back to the world of easy to achieve challenges, something I’d like to provide for MonoRail 2.0 is the view pre-processor. The goal is to lower the differences between view engines and standardize common constructions/idioms. For example, capturefor and viewcomponents usage. Today the way you use them on Brail and NVelocity are just too different.

Anyway, that blog has a noble goal, and I’ll follow it.

16 Responses to “That 90′s Show and MonoRail”

Christopher Bennage Says:

I know what you mean when you say “Took some time to admit that there’s nothing wrong with that approach.” I went through this myself just about a couple of years ago. Just recently I was helping a teammate solve a presentation problem in WebForms, and I found myself telling him “think classic ASP”.

hammett Says:

Exactly. There’s this perception that everything but WebForms approach is an old fashion, inadequate approach.

Rhywun Says:

I totally agree. When I first saw Ruby on Rails it looked like a step backward to me, until I actually played around with it. Now I have little desire to work with WebForms any more. I always thought forcing a desktop paradigm onto web programming was a bad idea, and I’m glad to see I wasn’t alone.

Nicholas Piasecki Says:

I completely agree. Mixing code with HTML is perfectly normal when the purpose of the code is to help generate HTML, not drive business logic. Any other paradigm (I’m looking at you, WebForms) is simply obfuscating this code and HTML mixture, although it’s still there–code generates the HTML somehow at some point, so why make it so difficult for ourselves?

I don’t know why people get caught up on a strict code and markup separation. It’s not about separating code and markup; it’s about separating business logic from presentation logic, and both business logic and presentation logic are expressed in code. Presentation code, unlike business code, can and should be freely mixed with the HTML that it’s responsible for creating.

That’s probably why, when I was transitioning from PHP to ASP.NET’s WebForms, that WebForms seemed so completely and utterly insane to me, since it achieved neither separation well, but it *thought* it did because it could say “Hey, look! We’ve got no C# in the .aspx file! Separation achieved!” But that kind of separation is useless, because the code-behind can be (and usually is) as messy as ever, mixing database calls inside button OnClick functions and so forth.

Back in my PHP days, this misunderstanding was reflected in people using templating languages like Smarty. Then, I had an epiphany–PHP *is* the templating language, and it simply takes discipline to know how to separate the business PHP from the presentation PHP. The same could be said for classic ASP; sure, there are lots of spaghetti-code PHP and ASP pages out there. But code separation wasn’t a language problem; it was a developer problem.

When I transitioned to an ASP.NET/MonoRail project, I found that MonoRail made this type of separation much easier and natural for developers. The NVelocity template language (which I both love and hate) is so simplified that it’s really difficult to do anything *but* presentation logic in the *.vm files.

To me, this discussion all boils down to one thing: the foreach loop. Let’s say you want to display a table of sales reports, but after every tenth row, you want to print out an extra row that displays a running total of sales to that point. And you want negative numbers to appear in red, positive numbers to appear in green, and zeros to appear in black. In MonoRail, this is easy; with WebForm’s declarative syntax, just shoot yourself in the face right now. Most solutions I’ve seen end up doing lots of manipulation in the code-behind and then slamming it into a Literal or something, which to me defeats the purpose of the code separation. (If it is easy in WebForms, I’d sure like to know how!)

Just my two cents. Hope that makes sense.

Scott Bellware Says:

ASP .NET templated controls did almost nothing to encourage separation of orthogonal concerns. It simply ended up separating concerns that aren’t separate concerns.

Philippe Says:

Microsoft’s desire to mimic WinForms in ASP.NET is indeed the heart of the problem. Web applications weren’t meant to be designed that way.

Now we only have to convince the many Microsoft-addicted corporations, because in their minds ASP.NET is the only mature web development technology out there.

while(availableTime>0) { Says:

Shortsighted Way of Evaluating Your Options

Lately I have been reading and experimenting a lot with options to what Microsoft gives me. Before you

Bernardo Heynemann Says:

Since I’m not sure if my post will appear hear, I just thought I’d add to this discussion that I posted about this in my blog at: http://manicprogrammer.com/cs/blogs/heynemann/archive/2007/07/22/shortsighted-way-of-evaluating-your-options.aspx
Hope you all agree with my points :)
Again very nice discussion.

Tim Scott Says:

I just came off a week of fun with Webforms GridView. I’ve been using Monorail lately and forgot what a sorry abstraction the GridView is. I started the week believing it was what it claimed to be, a thing, a databound grid with rows, columns, headers and footers — parts that I could get to in a straightforward manner. In short, I thought it was a WinForms grid. But then I tried to put some totals in the footer. I was quickly reminded it’s not the thing it claims to be. Turns out I cannot forget about the HTML that it renders.

I agree that logic (looping, branching) in the markup is not in itself a problem. However, with Monorail view components it’s pretty easy to eliminate the most complex logic and create in more “semantically pleasing” views, if you are so inclined.

Rhywun Says:

Ugh, what a piece of junk the DataGrid is/was. I don’t know if the GridView is any better because frankly I can’t be bothered to investigate. I remember when I first released an application built on ASP.NET to my coworkers and they clicked on one of those edit links to make the current row turn into editable text boxes. One of them wondered why it didn’t open a separate page to edit that record like, oh, every other web application in existence. I thought at the time, well Microsoft must have their reasons for doing this, and this is going to be “the way” to do it from now on, so… Now I see they have FormViews that try to mimic a more natural approach but they’re still based on postbacks to the same page – i.e. mimicking WinForms. What a pleasure to throw all that junk away.

Mike Says:

Quote: “But that kind of separation is useless, because the code-behind can be (and usually is) as messy as ever, mixing database calls inside button OnClick functions and so forth.”

Quote: “The same could be said for classic ASP; sure, there are lots of spaghetti-code PHP and ASP pages out there. But code separation wasn’t a language problem; it was a developer problem.”

So in ASP.NET the separation is useless because it can be abused but in classic ASP is is a developer problem? Seriously, if you’re going to make a point, try not to contradict yourself.

- – -

Quote: “One of them wondered why it didn’t open a separate page to edit that record like, oh, every other web application in existence. I thought at the time, well Microsoft must have their reasons for doing this, and this is going to be “the way” to do it from now on, so”

I hate to disappoint you here, but the reason it didn’t open a separate page is because you didn’t make it so! Some kind of programmer you are, and blaming it on Microsoft, that makes no sense.

Both of you, of course you’re free to use any other way of rendering, like monorail. And I’m interested in it, so tell me why that is so great instead of trying to convince me why the standard way is so bad with terrible arguments that actually don’t convince me at all.

kentaromiura Says:

I’m sure that nobody will argue if in an xsl stylesheet they
see an for-each construct, so why someone will argue if see a loop for presentation logic in a template?

Rhywun Says:

I hate to disappoint you here, but the reason it didn’t open a separate page is because you didn’t make it so! Some kind of programmer you are, and blaming it on Microsoft, that makes no sense.

Oh right, why should I blame Microsoft for forcing an ugly model on us that requires considerable extra effort to work against? It’s all MY fault. Thanks for clearing that up for me.

Whyrun Says:

@Rhywun
Glad you are clear now. Now time to catch a clue.

Merit indeed exists in seperating out the presentation layout from the presentation code (the stuff that handles events and “glues” or binds the data to the layout). That’s what should really be focused on. Enter WPF and XAML which go a long way to help address this plus improve the designer developer workflow and collaboration.

Nicholas Piasecki Says:

Quote by Mike: “So in ASP.NET the separation is useless because it can be abused but in classic ASP is is a developer problem? Seriously, if you’re going to make a point, try not to contradict yourself.”

Hmm. I was trying to say that it’s *still* a developer problem in ASP.NET. The ASPX/code-behind separation is just extra work on top of everything. The ASP.NET solution (a language solution that separates code and markup) didn’t solve the actual developer problem (separating presentation code from business logic code), which exists in *both* the ASP.NET and PHP/ASP worlds. So because the ASP.NET model is “abused,” the arbitrary code and markup separation doesn’t buy you much.

:: ducks ::

thinking in geek » Blog Archive » SoC in WebForms Says:

[...] Bellware makes a brillant comment on Hammett’s weblog: ASP .NET templated controls did almost nothing to encourage separation [...]

Leave a Reply