In the java Code (an Element in rife) I would fetch the data from the DB, and foreach result would do an:
template.setBean(result, RESULTBEAN:);
template.appendBlock(results,result);
r:v name=RESULT:lastname / can also be written as ${v RESULT:lastname /}, somtimes this is clearer.
There was a very interesting talk/rant on the web recently by a guy who says that modern developers have forgotten some of the core principals of Object Orientated development - such as objects knowing how to render themselves onto a canvas - but I just can’t find the link. It might have been by the same guy who claimed Object Orientated programming should have been named Message Orientated programming, to avoid people missing the point.
If you don’t have the HTML made for you by a Web Designer (i.e. you have to generate it yourself and let them style it with CSS) then this approach could work:
@Huibert Gill : what if you need to add first or odd and even css classes to your table’s TR, for example ? I would guess that all that logic has to be in the controller, who does all the loops, conditionals, puts these in variables sent to the templates … yeah, I’ve been doing that 8 years ago, and it makes the controller way too dependent on the view. Or you divide even more the processing with a controller for business logic, then a separate template-unroll method, then the template itself ( instead of having that template logic inside the template ). Great if it’s working for some people, but while it’s quite pure, for sure, such ways of processing templates have been abandoned for a reason …
Why aren’t we tired of discussing this problem already? Just use an engine like Haml if you don’t actually want to write the HTML itself or want your designers to mess with it.
Use a templating engine like Smarty if you want to write the HTML and are having problems with separating concerns, Smarty will almost force you if you abstain from the {php} tag. Tiny but strong also looks neat even if I don’t like the way the assignments are done per default.
I agree, the business logic should be in the controller. In the view you should have only the rendering logic: just loops, coditional show / hide, etc…
The best way to avoid that kind of tag soup is to balance the logic through the .aspx file and the codebehind file. For instance, if you need to render a table it is easier to concatenate strings in the codebehind and just call a protected method from the .aspx file.
Anyway, the real soup here is the comment soup, what a post reaction!!
I’m completely confused by this post. Tag soup is not an issue in asp.net. Not just in version 2.0 onwards either. in 1.0 there was absolutely no need to write such confusing and messy code.
This makes me understand the reasoning behind the PHP sucks mentality. Whilst I am not a PHP coder, I have seen code written like the Tag Soup you have shown, I have also seen some extremely neat and easy to understand code.
We write all of our asp.net applications as if they were winforms applications. There is no need to embed the code within the visual layout of the page. You wouldn’t be writing script tags like that within the layout of a winforms application, so why do it in a webform?
PHP sucks and ASP.NET sucks. No. Just a lot of PHP and ASP.NET developers only know how to write code that sucks.
Take a serious look at GWT. I think its the most effective approach for web apps (but maybe not necessarily textual content-heavy sites that need to be indexed like a wiki, blog, or news site). I hate the tag soup too (in my case its JSP/JSTL I have dealt with), hence why I’m using GWT for my web apps.
There are also a lot of misconceptions about GWT leading to invalid criticisms. Take the time to study it before dismissing it.
Many posts here claim that ASP.NET 2.0 nicely avoids tag soup. Although Jeff told us Do Not buy This Book (The ASP.NET 2.0 Anthology: 101 Essential Tips, Tricks Hacks, http://www.codinghorror.com/blog/archives/000971.html), I did, and I almost got crazy on pg. 126, where they praise the declarative nature of the GridView control.
What I see is an .aspx page, which is usually a HTML page (the soup) containing server side controls (the vegetables in the soup). For beauty’s sake, they just printed the controls, but what I see is, besides a complicated GridView declaration: a literal SQL query in an asp:SqlDataSource with a special SQL parameter syntax!
What Microsoft sells as declarative programming at least to me looks like a morbid collapse of the database backend (SQL queries) into the the view frontent (the HTML page).
I learnt declarative programming at university with Prolog and layered architecture (database backend, object model, page controller, HTML template views) on the webapp dev job, and I did well with it.
The structure will be a lot clearer if you turn word-wrapping off. Then the indenting will not be interrupted with continued lines. Also, it helps to have proper syntax highlighting for the ruby code, instead of making it an orangey smear. Finally, it helps to have a syntax highlighting that mutes the angle brackets.
That said, are you sure this code is from Typo? I cannot find it anywhere there.
@Tarnold: What Microsoft sells as declarative programming at least to me looks like a morbid collapse of the database backend (SQL queries) into the the view frontent (the HTML page).
All the problems you describe can be completely avoided in ASP.NET:
a) all the attributes in GridView declaration can be moved to codebehind so they no longer clutter-up the markup
b) SqlDataSource can also be moved to codebehind or better yet replaced with ObjectDataSource which is more flexible
What you criticize is some techniques which are best used for explaining programming concepts, for real production code there are better ways. As usually Microsoft gives you lots of choices and you apply it based on specific circumstances. If you do it right you can 100% avoid tag-soup.
in the ideal world i am occasionally guilty of slipping into, html is html with no server side influence. all dynamic portions of a page are introduced after the dom is loaded via ajax. everything is perfectly tieed.
unfortunately this ideal can not exist in the wild while users have js turned off and and any sense of commercial responsibility remains. your content must be indexed.
however, with care, a close approximation to this world is possible.
In the Java world, almost all frameworks are not tag-soupers. Non-XML server-side code mixed to HTML practically doesn’t exist on modern Java web development.
This has always driven me batty. Moreso now that I work primarily in PHP. It gnawed at me with ASP and Rails as well.
The comments: TLDR. I did a quick search for Enhydra-- I’ve worked extensively with it for years. One match! That guy knows the score. Absolute separation between markup and code was great. Java? Not my favorite codebehind. Ruby or Python would be glorious.
Allowance for both modes is what I’d like to see. Then it’s all about balance. Your post on normalization vs. denormalization comes to mind. Salivary glands: Activate!
I’m using CakePHP 1.2 now. I cannot begin to explain how good this framework is. You really need to use it to see all of the points where the mundane work and even slightly more difficult work is simply lifted off of your shoulders.
In your view thought you can use any number of the built in helpers to solve this issue. Since they are built in and not homegrown any Cake developer will be right at home with them. http://book.cakephp.org/view/181/built-in-helpers
Most notable are the HTML, Form, and JavaScript helpers. Also extremely helpful is the RSS helper.
XML + XSLT works so well for this problem that I was naively doing web development for two years before I discovered that this tag soup thing was apparently a problem.
You’re still left with the ugliness that is DHTML, but we’re not quite ready to start building our web sites in WPF yet, are we?
It is perhaps not a coincidence that a person who finds XML to be useless also finds that tag soup urgently requires our attention.
Django example doesn’t have any server side code, it’s all presentation code. Django uses templates that are not even Python itself, it’s a simple markup like PHP’s Smarty. No way to compare it with old ASP, or PHP, or embedded Ruby. Get your facts straight.
