Other solutions and their shortcoming

Where did all the characteristics we expected take us ?

First we looked into existing and emerging tools.

HTML Editor : a dependant solution

At the time we needed something, HTML editors weren't powerful enough and SGML tools were far to expensive. Today an HTML word-processor like Dreamweaver for instance offer the option to insert some objects defined in its object database and to modify this object only once and push the modification on all the pages using that object. This is close to our policy. Except that if you begin your site with that tool, you have to do all your pages with that same tool. And that is something we refused.

Inclusion of specific tag in the HTML

I'll just insist on one Dreamweaver function that is really useful and indeed, that we use. It is the possibility to define some new HTML like tags in a personal pallet and to drag and drop those tags inside some plain HTML.

SGML, XML... not yet really available but used

In fact our idea was to add some formatted information to plain HTML files and to pre-process theses files to get some graphical HTML one. That was made possible trough the use of SGML. Some information that was added was for instance the place of the file inside the browsing tree of the site or option to precise if the menu should appear at the head or the end of the page. One can still read an old description of these SGML file or an example.

That development present two drawbacks :

• First, it is very difficult to find some WYSIWYG, easy-to-use and cheap SGML Editor. And XML ones are not yet really available.
• Second, each time we want to change the design of a site, we had to modify our SGML Parser. So we needed to separate the parser from the design model. In fact, ManyPage looks a bit like an XSLT pre-processor (XSL Transformation, where XSL stand for Extensible Style Language)

On line database and dynamic web sites

Let's turn our attention to another classical approach. It consists in putting all the information in a Database and generating a new web page for each websurfer request. Such a mechanism has two down side :

Heavy consumption of computing resources.

The database request and the making of the web page consume far more process time that the simple fetch of a simple file.

Difficult access for the search engines : bad indexation

Information that is only available through CGI or ASP pages is not known on the web cause it is not accessible by most of the Internet search engines. This access issue doesn't only involve the web spider robots, but the websurfers too. Who has never been in front of an empty form without knowing what to look for in the database, because having no idea of its content.

Database and pre-processing

There is a solution to these two issues. It consists in dumping the database content into HTML pages before using those pages in a classical web site. It remains two other issues.

Strong formatting of the information

It is better to use a database when the information has a strict structure. If its only about storing a whatsoever html page, directory tree do that very well.

Need to run a database anyway

The main interest of using a database is to be able to do complex request (with logical expressions ).

Two little remarks

Actually, we use database for some parts of our web sites, especially when the information is well structured. And then we follow both the two precept. We dump the database and give the opportunity to people that know exactly what they are looking for to make complex request.

Anyway, if you really want to use dynamic web site (For instance PHP is quite trendy now), it is a good advice to set up a proxy cache in front of it to get better answer time.

What about the way to describe the added design

Eventually, one of the main issue we have to deal with was the way to transform our plain data into rich HTML.

I think the package XML / XSLT / XSL is something good to follow. But today, and it was all the more true when we develop it, I think ManyPage can still be useful in web site management.

Various other similar projects

WML

Perhaps the most similar (and then rival :-) project...

"WML is a free and extensible Webdesigner's off-line HTML generation toolkit for Unix, distributed under the GNU General Public License (GPL v2). It is written in ANSI C and Perl 5, built via a GNU Autoconf based source tree and runs out-of-the-box on all major Unix derivates. It can be used free of charge both in educational and commercial environments."

Jessica and JML

JESSICA: an object-oriented hypermedia publishing processor (R.A. Barta and M.W. Schranz, JESSICA: an object-oriented hypermedia publishing processor. In Computer Networks and ISDN Systems 30(1998), Special Issue on the 7 th Intl. World-Wide Web Conference, Brisbane, Australia, April 1998, 239-249.)

Syndication with JML

WebComposition

H.-W. Gellerson, R. Wicke, and M. Gaedke. WebComposition: An Object-Oriented Support System for the Web Engineering Life Cycle, Computer Networks and ISDN Systems 29(8-13), April 1997

General reflections

Hypermedia Patterns and Components for Building better Web Information Systems ( Martin Gaedke Telecooperation Office (TecO), University of Karlsruhe...)

Various

ezpublish, spip, jahia