A question of style: Inline code in .aspx pages.
-
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
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
-
You should think, "JSOP will have to maintain this one day". That will get rid of the "presents". If you want a non-expert opinion, I would prefer to keep them separate. Since the paradigm keeps changing, that looks like the sensible thing to do. Mixing them will mean that you'll probably have to separate them one day.
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
-
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.