Related link: http://www.meyerweb.com/eric/thoughts/2004/06/26/structural-naming/
Starting with an earlier post called I don’t want templates, I want HTML-making shortcuts, I’m slowly exploring the idea of the final HTML in web programming coming not from an HTML template, but from programming shortcuts. It seems ridiculous, I’ll bet. But Eric Meyer’s new post on Structural Naming reminded me why this makes sense.
I do believe, VERY much, in the idea of separating business-logic from presentation-logic. (Some call it model-view-controller. Whatever.)
But when HTML moves towards structural naming, it really is more like creating XML, where it’s the programmer’s job to output solid, valid, structually-marked-up data. NO layout, NO colors, NO fonts, just data….
…and it’s not the designer’s job to get that data into structural and valid HTML. Therefore it’s not a good time to be using separate template systems meant just for designers.
Once the HTML is created, then it’s the designer’s job to use a CSS stylesheet to make that structural data look how they want.
I may be totally wrong with this, but in a few weeks I’m going to try to put this vague idea into practice, and letcha know how it goes.
A good templating system supports this, or rather makes it unnecessary
if you are using Perl's legendary TemplateToolkit then this is possible using a choice of macros, sub-templates and plugins.
More importantly any web developer/designer (i.e. the person who designs the page layout, style sheets, etc) needs to be able to code XML to design an adequate DOM/DHTML framework to drape the stylesheet over.
Good web designers are programmers - they write actionscript (sometimes dealing with XML or other complex logic), Javascript and DOM. They can work with templates and backend programmers to ensure it works as a whole while seperating responsability.
I don't think I would last long if I followed your idea of generating HTML down in the backend code. The designers need control of the HTML.. on a complex website I don't have the time or inclination to track and manage all the internals of the GUI logic encoded in javascript or DHTML and control them from backend code that, frankly, has better things to do.
perhaps you have a background in ASP or PHP, that would seem the only reasonable explaination of embedding HTML in code. You wouldn't embed icons or menu names directly into a GTK or QT application.
been around for years
The venerable CGI module for Perl provides HTML shortcuts, as do various Java libraries. There have been attempts to make complex widget libraries too. The Bivio system uses declarative structures to generate all the HTML. However, most of these things fail to gain wide acceptance because they are not very friendly to the way the HTML coders like to work.
Broken link
The first link in your post isn't allowed to users who aren't O'ReillyNet bloggers.
Use http://www.oreillynet.com/pub/wlg/4876 instead.
Why just HTML?
It seems that your blending of programming and design (sorry, that's how I see it) is really aimed at just web pages. What about RSS? What if you want to implement XML-based services like Amazon? Now that you've buried HTML in the code, you have to write more code. However, separate the data from the markup and the code doesn't change; all you have to do is make new templates. CSS isn't going to get you to RSS. What about printer-friendly pages? Page summaries for "Email this to a friend" links? Unless I'm misunderstanding you, you'll be writing more code and templates.
Broken link
Ack! Fixed. Thank you!
Why just HTML?
Very VERY good point, and in fact has gotten me rethinking this thing. More on that later...