Here, briefly, are the basic options in ASP.NET. (only looking at inline versus server controls and code-behind)
I never minded the inline for the output of simple values that are only for viewing. e.g. label controls and viewstate are overkill. It makes easy stuff quite easy to read what the layout is with
h1%= _movie.Title %/h1
h3%= _movie.Director %/h3
span class=description%= _movie.Spoiler %/span
and alternative can be, when databound (asp.net)
h1%# Eval(Title); %/h1
h3%# Eval(Director); %/h3
span class=description%# Eval(Spoiler); %/span
or another alternative is to use server controls when you need more control and keep the markup readable.
h1asp:Label id=lblTitle runat=server //h1
h3asp:Label id=lblDirector runat=server //h3
asp:Label id=lblSpoiler runat=server CssClass=description /
in the ‘code behind’ file, at some point in the page life-cycle, you’d write…
lblTitle.Text = movie.Title;
lblDirector.Text = movie.Director;
if( string.IsNullOrEmpty(movie.Spoiler) )
{ lblSpoiler.CssClass=missing; lblSpoiler.Text = Resources(MissingSpoilerText); }
else
{ lblSpoiler.Text = movie.Spoiler; }
The reason for the inline styles is allowing for non-coders to change the markup without knowing the code. Obviously this can go too far when there’s too much tweaking that needs to be done, but the idea is flexibility. Personally I don’t dig Eval, because it’s always better to catch errors at compile time, but sometimes easy works just fine. Not every page will get your undivided attention, and it does have the utility of showing what is being used.
The other benefit of inline styles in ASP.NET is (usually) you can alter the output on a live system. If you do everything code-behind then you have to recompile and redeploy. [I say ‘usually’ because in Web Deployment Projects you can specify that pages are not updatable at runtime]
The problem is that real websites, with real logic, get messy quickly no matter where the logic goes. But when things get messy, it’s easier to refactor in code than it is to refactor in html.
%# (Eval(Prop) != null ? (Eval(Prop)) : Resources(PropNotFound); %
One thing in ASP.NET that I still find a bit persnickety is single and double quotes inside inline tags, and obviously this following is quite hard to read. I can’t remember examples offhand, but there are still times inlining fails inside of some tags, but not others.
a href=’%# Eval(Url) %’ title=’%# Eval(Title) %’%# Eval(Name) %/a – watch ’ versus !
At least MS, to their benefit, does allow flexibility. You don’t always have to do it the same way, which is very handy. You can embed the name of events in the aspx file, but you don’t have to (you can attach the delegate at runtime). You can just make a normal tag runat=server and then it becomes a member of the page. It can be a source of errors and frustration (knowing exactly where something is done) but that’s an issue of DRY and following good coding practices.
Sometimes I curst that it’s harder to write some forms of javascript because all the control names are mangled (based on the container they live in), but I get over it.
I usually write a block of code at the beginning of the file, and then I set up some variables to print in the page template, just like this: