[EMAIL PROTECTED] (Marc D. Spencer) writes:
> I have to chime in a little (also noting that we have drifted a bit
> off the original topic...)
>
> While working for a large company as the Chief Architect for the web
> group I was faced with the same need to investigate template options
> - within the discussion of Build or Buy. And yes, JSP (and ATG
> Dynamo) were on the list of potential buy options.
>
> I took a novel approach: Since I am an engineer, and can only really
> think like one, I _asked_ the web designers, and the web technicians,
> and the programming and management staff what their needs were. I'll
> summarize as briefly as I can below:
>
> o The designers do not like any template structure that uses the
> angle bracket notation <foo>. It makes some wysiwyg editors unhappy
> to see foreign tags, and in the current race to HTML4.0 strict, new
> tags make the validation tools (which have to be applied
> pre-template-parsing, of course) unhappy.
>
> o There are actually 3 groups involved, and separation of function
> as much as possible allows the three groups to work independently on
> a project without requiring concurrent editing of the same file.
>
> - HTML coders
> - Behavior (the perl or java code)
> - Resources (pulling in images or other referenced objects)
>
> With the templating options discussed so far, you tie the HTML
> coders and the perl/java coders to editing the same file. Separation
> of these two is really key, according to those I asked. The Project
> Managers like the separation too.
>
> o Don't forget localization. None of the existing products that we were
> able to look at handled localization of templates. Localization must
> be handled by HTTP accept headers and/or manual overriding.
>
> o Virtual hosts are real, and template reuse, especially across VHs,
> while allowing for VH specific customization (driven by the perl/java
> or configuration) is a nicety.
>
>
> We ended up developing our own solution, using mod_perl. By the way,
> performance tested against ATG's Dynamo, it performed 500 - 700%
> faster.
>
> FWIW.
>
The approach I have taken for some of my clients is to separate the
HTML and Perl entirely. The designers/HTML coders just create plain,
static HTML, with no strange tags. The pages created are run through
a batch script that takes a specification of locations in the page
that should be altered in some way, and transforms the entire (static)
work-in-progress web site into a preview web site (once the any
changes have been verified the contents of the site is then moved to
the live site). Elements and attributes can be inserted or deleted,
and pages can be transformed into Perl subroutines. Currently
locations are specified with ID attributes, but I am intending
extending this to use XPath. This keeps the HTML content and Perl
code *entirely* separate. As an example, report pages can be created
filled with dummy data -- the first row will generally be wrapped in a
Perl loop and cells populated with live data at run time and all other
dummy data rows deleted. The batch transformation process takes about
five minutes for a site with a couple of thousand documents.
The system has performed well for us (one site using it is www.nhbs.com).
There is an old document about the system on
http://www.ford-mason.co.uk/resources/perl/WYSIGASP.html
(the system originally carried the moniker WYSIGASP -- what you see is
good as a starting point)
I intend to update the system and tidy up the documentation and so on
once I have got the mod_perl Pocket Reference out of the way. I
started work on the system a few years ago now, so I need to think
about how it fits in with XML, for example.
Andrew
--
Andrew Ford, Director Ford & Mason Ltd Tel: +44 1531 829900
[EMAIL PROTECTED] South Wing, Compton House Fax: +44 1531 829901
http://www.ford-mason.co.uk Compton Green, Redmarley Mobile: +44 7785 258278
http://www.refcards.com Gloucester, GL19 3JB, UK
