Well, one thing you might want to look at it support levels. Raphael
Manfredi (author CGI::MxScreen ) seems to not have a lot of
time to answer questions and he doesn't have a mailing list setup with
anyone else who can help in his place. I don't always get answers back
from him and certainly don't get them back quickly. For example long
ago, I asked him: "what will MxScreen do when you have to hit a screen
in the middle of the application cold? MxScreen seems to create a
state machine of multi-screen page flow with the assumption that you
start at the beginning and then always move either forwards or back
from there... people like to bookmark URLs and return and the fact
that mxscreen uses post data (i am reaching here, I have forgotten)
makes this common task impossible.

Besides that, when you talk CGI::MxScreen and
HTML::Mason you are talking two very different ends of the
spectrum. With Mason, you embed your logic either in your HTML page or
in a small perl-HTML "component" which you embed in your page. This is
what is known as the "inline" approach. This tight-coupling of Perl
and HTML would seem to make it difficult to change the look and feel
of a website substantially without losing all of the associated
logic. However, Mason advocates site industry-level success to the
contrary.

Even so, however, an unavoidable shortcoming of the Inline approach is
that it does not give the HTML designer WYSIWIG pages. Furthermore, it
robs the power of re-use inherent in programs such as Dreamweaver from
the designer and makes this a programming task. Thus for a web site
company which places emphasis on visual fine-tuning of pages with
close interaction between high-level management and user-experience
engineers, the Inline solution will hamper such workflow.

On the other hand, the Inline solutions do offer you a "one-stop-shop"
for any web application task you might want to handle - error
handling, common-look-and feel, re-use, sessioning, logging, and
caching all come right out of the box with either HTML::Mason
or HTML::Embperl and both of these products have very active
and very supportive and very large user bases. And, because both
products have been in development for more than 3 years, they are both
well-debugged and ready for critical system deployment.

A younger, but perhaps more open solution following the inline
development work cycle is OpenInteract. Again, the support
level is strong. This product is also a bit more open-ended. While
supplying all of the same features as either of the above, it does so
by building on major CPAN modules for each of its cornerstones. For
example, instead of a proprietary templating solutin, OpenInteract
uses Template Toolkit.

Turning to the "meta-html" solutions, with any of these, HTML page
maintenance by non-programmers (HTML designers) is 100% and the
solutions to templating are 100% non-invasive. The most mature product
in this stable is HTML::Template. However, it's maturity has
not led to a stabilization of feature set. Recently it added a small
pseudo-language for expression processing
HTML::Template::Expr and even more recently, it added a
Just-In-Time compiler HTML::Template::Jit which compiles
template to C language for 4x speed improvements. While the latter is
just a performance improvement, the former is adding to the extra
things you might have to learn when learning HTML::Template

HTML::Template also supplies a flexible set of caching options.

It has been around for at least 2-3 years as well and the base module
HTML::Template is most likely completely bug free.

However, as the HTML::Template docs say, it only does one thing and
does it well and fast. You will have to strap together from CPAN a
system for the other aspects of web application development. You might
choose CGI::Application for CGI page reuse (this module has
some surprising hypocrisy in its design. It boasts that it is
webserver and database server agnostic. Yet it is not agnostic with
respect to templating system - it requires HTML::Template. to my mind,
there is no need for a system for multi-modal page use to require a
particular templating system. This, coupled with lack of return emails
from the author make this a less-than-attractive solution for any part
of an open system). You will need something for logging
Apache::Session and so on and so forth.

The other recent entry into the meta-html templating world is my own
HTML::Seamstress.

The poor support level of MxScreen is a pity. I haven't looked at it in detail, but I like the idea of recorded fields (with validation and storage). For my own framework I thought of a ddl (data definiton language) which models datatype, name, label, verification, storage and relation to other tables. So I might be able to "automatically" expand the main table with an 1:1, 1:n or n:m relationship to other tables.

But back to the templating systems:
I don't like the inline-approach. You should be able to change the html-pages without programming knowledge. Especially, tools such as Dreamweaver should cope with the tags. There might be problems with <...> tags, because sometimes they will be converted to '&_lt;' and so on.

A few weeks ago you had a comparison on your home node about the different templating systems. When you compare HTML::Template and Template::Toolkit - which one is faster without using caching or precompiled pages?
I don't need to much from the templates. Loops and IF-THEN-ELSE-constructs are all I need.

Once again, thank you.
I hope we can continue this discussion.
Good bye, Uwe