A question of style: Inline code in .aspx pages.
-
Back in the dark ages when we wrote ASP pages, our only real choice was to inter-mingle our code and our HTML. We'd write a little HTML, then open a script block with <%, then emit some data, or start a loop, or open a connection to a database or whatever. Then we'd close the block and continue on with HTML. Then came ASP.NET and WebForms and suddenly the code-behind (and then code-beside) model dictated that there was a separation of code and markup. You were meant to be able to scatter your server-side controls onto a page like any other markup, code against it in the code-behind, then send just the .aspx page with the markup to a designer who would make it perfect and who would never be able to break you code, since there was no code on the page. Then came MVC and suddenly we're back to inline code. Well, not necessarily code - more inline binding of the properties of the view-model. Except where you need to loop. And maybe that bit where you need to branch. And maybe that other bit, too. The whole argument for the clean, precise separation of code and markup seems to never be mentioned these days and so I'd like to know how ASP.NET developers feel about this. Regardless of what framework you use, do you mix it up like it's 1999? Do you stick to your guns and keep Church and State separated? Or do you embrace the inline binding of view-model to view and just not get carried away too much. If possible?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Although I've not given it too much of a look, I couldn't see much advantage in MVCing it over the "Separation of Church and State" that I "grew up on " I hated ASP so much that I developed my own variation, using ISAPI, that allowed for the separation much more than traditional ASP, until ASP.Net came along.
___________________________________________ .\\axxx (That's an 'M')
-
Back in the dark ages when we wrote ASP pages, our only real choice was to inter-mingle our code and our HTML. We'd write a little HTML, then open a script block with <%, then emit some data, or start a loop, or open a connection to a database or whatever. Then we'd close the block and continue on with HTML. Then came ASP.NET and WebForms and suddenly the code-behind (and then code-beside) model dictated that there was a separation of code and markup. You were meant to be able to scatter your server-side controls onto a page like any other markup, code against it in the code-behind, then send just the .aspx page with the markup to a designer who would make it perfect and who would never be able to break you code, since there was no code on the page. Then came MVC and suddenly we're back to inline code. Well, not necessarily code - more inline binding of the properties of the view-model. Except where you need to loop. And maybe that bit where you need to branch. And maybe that other bit, too. The whole argument for the clean, precise separation of code and markup seems to never be mentioned these days and so I'd like to know how ASP.NET developers feel about this. Regardless of what framework you use, do you mix it up like it's 1999? Do you stick to your guns and keep Church and State separated? Or do you embrace the inline binding of view-model to view and just not get carried away too much. If possible?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
I try to segregate as much as possible seems a lot cleaner to me. KISS
If you are cross-eyed and have dyslexia, can you read all right? http://www.hq4thmarinescomm.com[^] [My Site]
-
Back in the dark ages when we wrote ASP pages, our only real choice was to inter-mingle our code and our HTML. We'd write a little HTML, then open a script block with <%, then emit some data, or start a loop, or open a connection to a database or whatever. Then we'd close the block and continue on with HTML. Then came ASP.NET and WebForms and suddenly the code-behind (and then code-beside) model dictated that there was a separation of code and markup. You were meant to be able to scatter your server-side controls onto a page like any other markup, code against it in the code-behind, then send just the .aspx page with the markup to a designer who would make it perfect and who would never be able to break you code, since there was no code on the page. Then came MVC and suddenly we're back to inline code. Well, not necessarily code - more inline binding of the properties of the view-model. Except where you need to loop. And maybe that bit where you need to branch. And maybe that other bit, too. The whole argument for the clean, precise separation of code and markup seems to never be mentioned these days and so I'd like to know how ASP.NET developers feel about this. Regardless of what framework you use, do you mix it up like it's 1999? Do you stick to your guns and keep Church and State separated? Or do you embrace the inline binding of view-model to view and just not get carried away too much. If possible?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
The main reason I am not sure about MVC is that I think inline code is an abortion. I'll avoid it at all costs. I LIKE readable web code.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
-
It can get to be a problem, when - 6 months from now - you look at some code and think, "Man, I do NOT remember writing this stuff." :)
Best wishes, Hans
Usually I think "wow - that must have been a really, really good bottle of red when I wrote that stuff"
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
Usually I think "wow - that must have been a really, really good bottle of red when I wrote that stuff"
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Drinking at work! Where do I apply?
-
Back in the dark ages when we wrote ASP pages, our only real choice was to inter-mingle our code and our HTML. We'd write a little HTML, then open a script block with <%, then emit some data, or start a loop, or open a connection to a database or whatever. Then we'd close the block and continue on with HTML. Then came ASP.NET and WebForms and suddenly the code-behind (and then code-beside) model dictated that there was a separation of code and markup. You were meant to be able to scatter your server-side controls onto a page like any other markup, code against it in the code-behind, then send just the .aspx page with the markup to a designer who would make it perfect and who would never be able to break you code, since there was no code on the page. Then came MVC and suddenly we're back to inline code. Well, not necessarily code - more inline binding of the properties of the view-model. Except where you need to loop. And maybe that bit where you need to branch. And maybe that other bit, too. The whole argument for the clean, precise separation of code and markup seems to never be mentioned these days and so I'd like to know how ASP.NET developers feel about this. Regardless of what framework you use, do you mix it up like it's 1999? Do you stick to your guns and keep Church and State separated? Or do you embrace the inline binding of view-model to view and just not get carried away too much. If possible?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
It's horses for corses. If there's more code then separate them otherwise let them mingle like a Kentucky family.
Panic, Chaos, Destruction. My work here is done. or "Drink. Get drunk. Fall over." - P O'H OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
-
Back in the dark ages when we wrote ASP pages, our only real choice was to inter-mingle our code and our HTML. We'd write a little HTML, then open a script block with <%, then emit some data, or start a loop, or open a connection to a database or whatever. Then we'd close the block and continue on with HTML. Then came ASP.NET and WebForms and suddenly the code-behind (and then code-beside) model dictated that there was a separation of code and markup. You were meant to be able to scatter your server-side controls onto a page like any other markup, code against it in the code-behind, then send just the .aspx page with the markup to a designer who would make it perfect and who would never be able to break you code, since there was no code on the page. Then came MVC and suddenly we're back to inline code. Well, not necessarily code - more inline binding of the properties of the view-model. Except where you need to loop. And maybe that bit where you need to branch. And maybe that other bit, too. The whole argument for the clean, precise separation of code and markup seems to never be mentioned these days and so I'd like to know how ASP.NET developers feel about this. Regardless of what framework you use, do you mix it up like it's 1999? Do you stick to your guns and keep Church and State separated? Or do you embrace the inline binding of view-model to view and just not get carried away too much. If possible?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Logic dictates a clean separation of concerns and nothing brought me more joy than .Net: I would be very reticent about MVC: the concept is great, the execution not so much. besides, 'traditional' Asp.Net is easier to maintain and read. Still, each to their own.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
-
Back in the dark ages when we wrote ASP pages, our only real choice was to inter-mingle our code and our HTML. We'd write a little HTML, then open a script block with <%, then emit some data, or start a loop, or open a connection to a database or whatever. Then we'd close the block and continue on with HTML. Then came ASP.NET and WebForms and suddenly the code-behind (and then code-beside) model dictated that there was a separation of code and markup. You were meant to be able to scatter your server-side controls onto a page like any other markup, code against it in the code-behind, then send just the .aspx page with the markup to a designer who would make it perfect and who would never be able to break you code, since there was no code on the page. Then came MVC and suddenly we're back to inline code. Well, not necessarily code - more inline binding of the properties of the view-model. Except where you need to loop. And maybe that bit where you need to branch. And maybe that other bit, too. The whole argument for the clean, precise separation of code and markup seems to never be mentioned these days and so I'd like to know how ASP.NET developers feel about this. Regardless of what framework you use, do you mix it up like it's 1999? Do you stick to your guns and keep Church and State separated? Or do you embrace the inline binding of view-model to view and just not get carried away too much. If possible?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
I haven't done an aspx page in a few years, but I would still try to keep it separate. I want as little as possible in the actual HTML... Of course, I don't fall into the crowd that gets a woody every time some industry pundit postulates about some new paradigm.
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997 -
Indivara wrote:
Mixing them will mean that you'll probably have to separate them one day.
Are you sure? You know how Chris is always chasing the latest paradigm du jour. :)
Best wishes, Hans
I first read that as "paramour per diem" :rolleyes:.
Software Zen:
delete this; -
Back in the dark ages when we wrote ASP pages, our only real choice was to inter-mingle our code and our HTML. We'd write a little HTML, then open a script block with <%, then emit some data, or start a loop, or open a connection to a database or whatever. Then we'd close the block and continue on with HTML. Then came ASP.NET and WebForms and suddenly the code-behind (and then code-beside) model dictated that there was a separation of code and markup. You were meant to be able to scatter your server-side controls onto a page like any other markup, code against it in the code-behind, then send just the .aspx page with the markup to a designer who would make it perfect and who would never be able to break you code, since there was no code on the page. Then came MVC and suddenly we're back to inline code. Well, not necessarily code - more inline binding of the properties of the view-model. Except where you need to loop. And maybe that bit where you need to branch. And maybe that other bit, too. The whole argument for the clean, precise separation of code and markup seems to never be mentioned these days and so I'd like to know how ASP.NET developers feel about this. Regardless of what framework you use, do you mix it up like it's 1999? Do you stick to your guns and keep Church and State separated? Or do you embrace the inline binding of view-model to view and just not get carried away too much. If possible?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
With ASP.NET MVC, when done properly the seperation is still there. Use a good view engine and stick to using display/editor templates, including display templates for lists and you end up with just standard Html.RenderMeSomethingOnThePage calls which pretty much represent the same magic as the blocks a designer would have to deal with. But, in response to your original question - yes, you should seperate (And keep view logic down to a minimum).. but does anyone ever do that? Nobody I have ever worked with did! (including myself)
James Simpson Web Solutions Developer www.methodworx.com
-
Hans Dietrich wrote:
considering you will be the one maintaining it.
I think that's a terrible way to think. Every line of code I write I always think "some poor bastard will have to maintain this one day". Sometimes I make it easy for them. Sometimes I leave them presents. You know - the type your cat sometimes leaves you.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Chris Maunder wrote:
I think that's a terrible way to think. Every line of code I write I always think "some poor bastard will have to maintain this one day".
... immediately followed by thinking "I need a raise". :laugh:
3x12=36 2x12=24 1x12=12 0x12=18
-
Back in the dark ages when we wrote ASP pages, our only real choice was to inter-mingle our code and our HTML. We'd write a little HTML, then open a script block with <%, then emit some data, or start a loop, or open a connection to a database or whatever. Then we'd close the block and continue on with HTML. Then came ASP.NET and WebForms and suddenly the code-behind (and then code-beside) model dictated that there was a separation of code and markup. You were meant to be able to scatter your server-side controls onto a page like any other markup, code against it in the code-behind, then send just the .aspx page with the markup to a designer who would make it perfect and who would never be able to break you code, since there was no code on the page. Then came MVC and suddenly we're back to inline code. Well, not necessarily code - more inline binding of the properties of the view-model. Except where you need to loop. And maybe that bit where you need to branch. And maybe that other bit, too. The whole argument for the clean, precise separation of code and markup seems to never be mentioned these days and so I'd like to know how ASP.NET developers feel about this. Regardless of what framework you use, do you mix it up like it's 1999? Do you stick to your guns and keep Church and State separated? Or do you embrace the inline binding of view-model to view and just not get carried away too much. If possible?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Situation: based on the contents of some model property, you have to display a particular DIV as one css class or another. So how do you solve this *without* mixing markup and code? Regardless if you're using MVC or not? Either your model has to have CSS class string constants embeded internally (BAD) or you have to branch in your markup (BAD). So which would you do? Me? I choose to branch in my markup. Deciding which css class to use is very definitely a display concern, so it belongs in the view/aspx/cshtml/whatever.
-
Drinking at work! Where do I apply?
We've had the job posted for ages but no many responses. Ah well, we're short on glasses anyway.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
-
We've had the job posted for ages but no many responses. Ah well, we're short on glasses anyway.
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Now that you mention it, I don't recall having seen the job board for ages. Just out of curiosity, do you have a link?
-
Back in the dark ages when we wrote ASP pages, our only real choice was to inter-mingle our code and our HTML. We'd write a little HTML, then open a script block with <%, then emit some data, or start a loop, or open a connection to a database or whatever. Then we'd close the block and continue on with HTML. Then came ASP.NET and WebForms and suddenly the code-behind (and then code-beside) model dictated that there was a separation of code and markup. You were meant to be able to scatter your server-side controls onto a page like any other markup, code against it in the code-behind, then send just the .aspx page with the markup to a designer who would make it perfect and who would never be able to break you code, since there was no code on the page. Then came MVC and suddenly we're back to inline code. Well, not necessarily code - more inline binding of the properties of the view-model. Except where you need to loop. And maybe that bit where you need to branch. And maybe that other bit, too. The whole argument for the clean, precise separation of code and markup seems to never be mentioned these days and so I'd like to know how ASP.NET developers feel about this. Regardless of what framework you use, do you mix it up like it's 1999? Do you stick to your guns and keep Church and State separated? Or do you embrace the inline binding of view-model to view and just not get carried away too much. If possible?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Actually, I feel that MVC leads to an improved separation of concerns, if not necessarily code and markup. By this I mean that separating the Model from the View and Controller leads to big wins. 1. The Model may be reusable in different areas. I've worked with both Windows and Web services sharing the same model as the page architecture. 2. The Controller and routing architecture allows URI's to be much more sensible, and fits better with RESTful architectures. 3. The .aspx represents the view, so the only code in here should be intimately related to Presentation. With respect to the third, if you find anything other than small fragments in the code, then as usual separate it out and invoke it. Yes, you will still be including some code in the markup, but in a good design this should be minimal. The WinForms alternative can appear to have less code in the markup. To my mind though it obfuscates the real nature of the webs request/response architecture. I'd happily make the sacrifice of placing a small amount of code im markup in exchange for a system where the fundamental model seems closer to the nature of what you're actually dealing with. Seems a vastly improved alternative to the mass of ViewState that travels along with a WebForms page - I like to be able to code in a system and predict reasonably what you get.
-
Situation: based on the contents of some model property, you have to display a particular DIV as one css class or another. So how do you solve this *without* mixing markup and code? Regardless if you're using MVC or not? Either your model has to have CSS class string constants embeded internally (BAD) or you have to branch in your markup (BAD). So which would you do? Me? I choose to branch in my markup. Deciding which css class to use is very definitely a display concern, so it belongs in the view/aspx/cshtml/whatever.
This is a case I'd like to see discussed some more. I faced this condundrum in a MVVM application. I put the display property (CSS class) in the view model and could simply bind to it in the view. I guess MVVM has that extra layer where this stuff can be buried.
-
Although I've not given it too much of a look, I couldn't see much advantage in MVCing it over the "Separation of Church and State" that I "grew up on " I hated ASP so much that I developed my own variation, using ISAPI, that allowed for the separation much more than traditional ASP, until ASP.Net came along.
___________________________________________ .\\axxx (That's an 'M')
I did one or two small projects, and may have done some bigger ones if I didn't move away from web dev for a while, where my .asp was little more than a DLL import and method call on a COM component. That object spat out HTML. In hindsight I wrote a forerunner for ASP.NET.
-
The main reason I am not sure about MVC is that I think inline code is an abortion. I'll avoid it at all costs. I LIKE readable web code.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
With the 'older' style HTML helpers, partial views, and well written controllers, there need be very little code at all inline, and now with Razor your markup is even cleaner.
-
Situation: based on the contents of some model property, you have to display a particular DIV as one css class or another. So how do you solve this *without* mixing markup and code? Regardless if you're using MVC or not? Either your model has to have CSS class string constants embeded internally (BAD) or you have to branch in your markup (BAD). So which would you do? Me? I choose to branch in my markup. Deciding which css class to use is very definitely a display concern, so it belongs in the view/aspx/cshtml/whatever.
Vark111 wrote:
Situation: based on the contents of some model property, you have to display a particular DIV as one css class or another.
I render the model property as JavaScript and use jQuery to conditionally set the class of the DIV.
-
Back in the dark ages when we wrote ASP pages, our only real choice was to inter-mingle our code and our HTML. We'd write a little HTML, then open a script block with <%, then emit some data, or start a loop, or open a connection to a database or whatever. Then we'd close the block and continue on with HTML. Then came ASP.NET and WebForms and suddenly the code-behind (and then code-beside) model dictated that there was a separation of code and markup. You were meant to be able to scatter your server-side controls onto a page like any other markup, code against it in the code-behind, then send just the .aspx page with the markup to a designer who would make it perfect and who would never be able to break you code, since there was no code on the page. Then came MVC and suddenly we're back to inline code. Well, not necessarily code - more inline binding of the properties of the view-model. Except where you need to loop. And maybe that bit where you need to branch. And maybe that other bit, too. The whole argument for the clean, precise separation of code and markup seems to never be mentioned these days and so I'd like to know how ASP.NET developers feel about this. Regardless of what framework you use, do you mix it up like it's 1999? Do you stick to your guns and keep Church and State separated? Or do you embrace the inline binding of view-model to view and just not get carried away too much. If possible?
cheers, Chris Maunder The Code Project | Co-founder Microsoft C++ MVP
Personally, I hate inline code and it really has little to do with separation of concerns. It's bitten my butt several times over the years as you try to do things like set page themes or dynamically inject controls in the page processing pipeline. I avoid it like the plague. My recipe for an ASP.Net WebForms aplication... Use jQuery and widgitize or plugin the bejesus out of everything that is even remotely reusable. There should be very few server-side dependencies here as each widget or plugin is highly independent and provides very targeted functionality that serves to extend functionality of the markup in the client; e.g., a datatable widget that adds paging to an HTML table element. Almost everything on the UI is broken into UserControl style reusable blocks. Each UserControl has a javascript controller to manage interactions on the client. Minimize server dependencies in the client controller to AJAX calls to a REST bus to acquire data as needed. Where it makes sense, data is returned as highly semantic markup; e.g., an HTML table element. When you return semantic markup like this, you're not really returning UI (view), you're really returning data (model). On the server side, make them ScriptUserControls (from the AJAX Control toolkit) to allow for easy script dependency injection and use a MVVM or MVP pattern to separate concerns on the server. There tends to be very little code in the ScriptUserControl code-behinds or VM/P's because essentially all they are doing is bootstrapping the client behavior script. The real work is being done by the client behavior and the REST bus. You pass settings and parameters as script properties to the client behavior, so zero inline code (and very little markup) in the .ascx. ASP.Net MVC would probably fit very well here as well - especially in the REST bus implementation. I say probably because, I haven't had an opportunity to try out MVC in my legacy app yet. But I have been able to successfully reuse this recipe and all the client script in a Java appliction based on the Spring Framework, which is nearly identical to ASP.Net MVC. And boy, talk about separation of concerns. All the view is encapsulated in the client scripts. For the most part, zero inline code and super semantic markup. The model is in the classes used by the REST bus to generate the return messages, and the controller is the code-behind for the REST bus. Almost every class has specific and targeted functionality making each class small and easy to understand and ma