A question of style: Inline code in .aspx pages.
-
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
-
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 definitely prefer keeping all code out of the markup, even though I coded in asp for years and am very comfortable with that approach. To me, this is one the HUGE turnoffs (among others) of MVC, going back to this messy model.
-
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 maybe the only one that looks as MVC and inline code as a blessing. Yes by far it is harder to maintain, but the possibilites it can open up far exceeds the ability maintain it. This is probably because I have been programming for nearly 40 years, I have different point of view on coding. I have programmed in Assembly, qbasic, fortran, pascal,c, c++, lisp,sql, html,xml,c#..... I have found .Net in gerneral, until MVC, to be quite limiting. It is more interesting now with MVC. RC
-
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
-
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
Not too long ago I got into a debate with some folks from Thoughtworks over lunch on a Monday. They were attacking dynamic data templates and the whole ASP.NET paradigm. I presented a scenario of a simple, temporary internal application for a small department in a large organization and asked how they would code it. They got into design patterns and unit testing and concern separation and automated UI testing (and on). They guessed it would take a relatively small team about a week to pull it off. Using the templates approach, I had completed the entire thing in 12 hours over the weekend. Which was the correct approach? I think that, like many programming questions (should I unit test this?), separation comes down to size and scope of the project. MVC 3 (especially using Razor) allows us to make the binding bits very clean. You can farm most
ifsoff to partials and keep your primary views fairly clean that way (binding and loops will remain). I think that over-separation of concern can be as much a problem as muddling together a big fatty-fat-fat page. When you're on a smaller project with limited scope, why not use the abilities of the view engine? Also, why do people seem to be offended by "code in the view"? I actually think that there is code that belongs in the view: why can't Iiftwo divs meant for different flows? Why is that bad? What if UI cues from inline code is a simpler way to create a better, more usable UI than getting caught up in over-engineering and academia debate? Now...I will say that I am also a student of design patterns and MVC itself is an implementation of a classic. On larger projects I tend to give myself a level of protection from both a maintenance and an accountability standpoint; typically that means good test coverage and good practices in dev. But it doesn't mean that the odd bit of inline won't appear...My Latest: Google Maps in ASP.NET MVC 3 with Razor Tech blog: They Call me Mister James
-
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
Nowadays I am very cautious of one-size-fits-all solutions. With classic ASP that is what we seemed to get. There was no real separation --- I guess putting in some thought code have lead to better separation (web-classes in VB6 had some of this). So the solutions here seemed to be put everthing on the page. With ASP.NET we got better separation even though it was still possible to place code in the page. But the solution here seemed to be to separate everything. The thing with MVC is that the code I put on the page is view-specific code. It has everything to do with rendering the output. However, when performing operations or retrieving data, etc. these are encapsulated in the relevant classes, and data required by the view is passed in the model. So I don't think it is really going back to where we were but rather a matter of: put code you need on the page and code that shouldn't be on the page in classes. But again, one could've ended up with this solution using the previous options.
-
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
Eh depends on the scale and scope of the project. If its a large project and has a bunch of complexities to it. Then I split the code, if its a table view of some data, or a basic IO database project then I'll "cheat" with MVC and go that route. Really just depends.
-
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
This recent trend away from separation of code from display has disturbed me, too, especially as it is coming from the very folks who preached separation during the last half of the 90s into the current decade. It really started to bother me when MS and all the "expert" bloggers instructed us to put the SQL query into the markup in the form of DataSource controls. Did they decide that all the maintenance horrors they said would happen when you put code in your form/markup were just a myth, or that the new technologies magically made those points moot?
-
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