Angus Lees was once rumoured to have said:
> \begin{Crossfire}
> > Mason [aka HTML::Mason] is one of the two `embeded perl' systems for
> > mod_perl. The other one is EmbPerl.
[snip]
> HTML::Embperl is similar (in goal) to the others, but:
To be fair to Mason, I'm going to compare against Gus' comments.
> already has completely integrated sessions (you just access the
> "magic" %fdat hash, and it creates/tracks/stores/retrieves a session
> for you)
This aspect of Mason is both good and bad - there is no automagical
session handling. However, the positive side is that you can roll
your own, and decide when and how its triggered.
> automatically parses certain HTML tags, to (eg) automatically iterate
> over rows/columns in tables, set default form values, automatically
> switch from HTML-escaping to URL-escaping of output, etc.
Most of these can be achieved using simple perl constructs with
existing modules in Mason.
> can do a full component-based design of your pages, and override
> pieces in subtrees, etc. each page only has to contain the unique
> content, no boilerplate "include header/footer" statements.
This is actually the same as Mason. Mason uses a component model too,
and the autohandler provides your "for all" template - furthermore,
autohandlers are invoked recursively up the tree so you can nest
functionality without replicating then functionality of autohandlers
further up the tree.
> keeps a log of the request (when debugging is enabled), and adds
> hyperlinks at the top of the page, so you can see the evaluation and
> hyperlink to code lines.
I'd imagine that Mason would have similar features, but I've never
used them.
> can interactively run pages (from a wrapper perl script) in the perl
> debugger, and it shows you the right source lines, etc.
can't do this yet in Mason AFAIK.
> the backend parser is written in C, so its quite a bit faster than
> mason (see: http://www.chamas.com/bench/index.html)
Its not like Mason's speed is a problem for SLUG anyway. :P~ Mason
tries to make up for its performance caching the Mason->Perl compiled
pages - which remain cached in memory when mod_perl requests them.
> it doesn't try and hide the perl, so you can do everything you're used
> to in normal perl, with very little changes. (this was one of my main
> reasons for choosing it over alternatives)
Mason also uses straight perl - Mason pages are compiled back to perl
and are cached in that form, just like JSP pages inside most JSP
environments.
> embperl 2.0 (still alpha) supports multiple syntaxes (including XML,
> SSI, Apache::ASP, and straight perl CGI), completely tunable caching,
> etc.
I can't see why such a thing would be so important.
Mason also has built in data and response caching which operates over
components, not just pages.
Backends can be coded as perl modules, called from inside of Mason for
those who are into templating systems, otherwise you can code in-place
for those who prefer embedded-code solutions.
Furthermore, Mason is fully documented (see masonhq.com), and is also
moderately widely used.
Another cute feature is <%filter> which lets you run a content filter
over components that have just executed - this can lead to some *very*
cute solutions to problems [it makes navigation bars which show the
current page that much easier to implement].
Mason also features "dhandlers", which are invoked when a document
can't be found for a given URI, allowing you to create virtualised
content trees from data-sources easily.
Anyhows, the documentation is a suggested read since it covers the
feature-set better than I can.
C.
--
--==============================================--
Crossfire | This email was brought to you
[EMAIL PROTECTED] | on 100% Recycled Electrons
--==============================================--
--
SLUG - Sydney Linux User Group Mailing List - http://slug.org.au/
More Info: http://slug.org.au/lists/listinfo/slug
