I just coined the name HtmlModeler to describe this thing I've been mucking around with, that I've written in Smalltalk. It is an outgrowth of some fun stuff I did at a prior (now-defunct) company named Empresa, using a tool Empresa acquired called VisualMagic. In some distant way, it's vaguely related to Wiki; as I've used and cloned Wiki, I've unleashed the energy in myself that motivates this.

The basic idea is that good websites have a consistency of form and content that screams at the sensitive OO designer. HTML is easy to generate. So an HtmlModeler is a tool (mine is written in Smalltalk, but I think I could readily accomplish the same in Java or Perl) that lets me build an object model of the website. I've ended up making heavy use of the Interpreter, Builder, Visitor, and related patterns from GangOfFour.

The model reflects the way I think about the site. HTML is then generated by traversing the model. But HTML isn't the only thing can be generated... the extensions to Swing, CUA kinds of things, and similar cool stuff constantly distract me.

So it's relatively easy and even fun to make sweeping changes to a site, like moving a logo banner from across the top to down the side.

When I have to go back to a plain ascii editor, I find it quite frustrating by now -- it's a little like giving up macros once you've gotten used to them. Or moving from VisualAge's language-aware Java environment back into a file-based environment.

If you ''must'' use a character editor in the Windows environment, try CodeWright. I like it a lot.

-- TomStambaugh

I've toyed with this idea many times, but never got around to actually doing it.  I usually get sidetracked into on-demand generation of pages rather than pregenerating a static site, despite the latter's many advantages. Can you share any more details of your site model? -- FrankCarver

I should point out that there is an HtmlModeler built into VisualAgeForJava; it's called "ServletBuilder".  Take a look at the source code that ships and you'll see that it's a pretty rich set of HTML objects. -- KyleBrown

----

UserlandFrontier, http://frontier.userland.com/ has been doing this for
a while. There is a freeware version that is a couple of revisions old. The 
latest is based on a subscription type of pricing. Basically, it's an integrated
object database and scripting environment (C-like syntax). The data of your website is managed separately from it's presentation. It has numerous built-in scripts (which also live in the database) and can be customized to your heart's content. The scripts perform a "rendering" of the site, which can be done statically or dynamically.

----

Take a look at http://meganesia.int.gu.edu.au/~phmartin/WebKB. Similar approach but uses knowledge-based engine to accumulate information and generate HTML files.

----

ZopeApplicationServer seems to be following the same idea as UserlandFrontier. It is Python-based, though. So it may or may not be more object-oriented. Has somebody actually used it to some extent? -- HaskoHeinecke

''Zope is also Web-based.  With Manila (a product that sits of frontier), you have an optional Web interface, but you also have a really good development/authoring (good for both the writers and the coders) enviroment. ''

----

I'm still not clear on the definition of an HTML Modeler.. can you explain or demonstrate? I have a vague idea that HTMLgen (for python) is the same kind of thing. It gives you classes for most HTML codes, so you can do things like Strong('this is bold, and ', EM('this is in bold and italics')) -- ShaeErisson

----

I once had this DarkPattern. I ended up seriously disenchanted.

The problem is that if ''all'' you model is the HTML tag vocabulary, your model will end up reflecting its shortcomings and quirks. The Table object ends up used for just about every layout that requires the slightest precision in alignments, etc.

If your site is mostly content-oriented, you won't benefit much; XML is a more parsimonious way of storing documents which have a very regular structure, with XSL taking care of the rendering to HTML; while for more visual or "spiffy" content the "best practice enforcement" and orderliness that the HtmlModeler affords will actually stand in your way sooner or later. Most "sophisticated" site designs abuse HTML in various ways. 

This is IMHO one of the major reasons the ASP/JSP/PHP model of HTML with embedded code statements won over early initiatives similar to the one described here for use in Servlets.

If on the other hand your site is service-oriented (i.e. a "web application") you will eventually run into the converse problem - HTML adresses only concerns of visual presentation, and is unsuitable for expressing ''behaviour''.

However, I view the JSP model as a seductive poison. A JSP page isn't an instance of anything, you can't unit test it, and the apparent simplicity of the "scripting" aspect turns out on closer examination to hide the baroque results of a deep-diving expedition into the Java bag of tricks : a JSP page is first preprocessed into XML, translated into Java via XSL, compiled to bytecode, shoehorned into the VM aboard that most perilous of all tricks, the custom ClassLoader.

(PHP has its own, different problems, though I regard it as slightly more "honest" than JSP.)

I am currently trying out an adaptation of ModelViewController for "service-oriented" sites (actually a full-blown application decoupled from any Web content, which made the problem much more obvious) - I hope to eventually report better results than the alternatives permit.

-- LaurentBossavit