Sam Hokin (sam@ims.net) wrote:
> However, one BIG issue I'm facing is with revisioning concurrent PHP and
> HTML development. Say one has 5 sites that use the same PHP but have
> different HTML design. How would one apply an update to the PHP on those 5
> sites without touching the HTML? It seems almost impossible since the PHP
> and HTML are so intertwined, you'd at least have to automatically generate
> comments for parsing/replacing. This seems to be a big, untreated issue in
> server-side scripting in general. Of course, not that many people develop
> multiple sites that use the same PHP code with different HTML, but I do.
>
> Not a Postgres question at all, but perhaps some smart people on this list
> have some ideas. I'll probably post it sometime to the php-general list.
It's a fairly general problem. The standard response is to say "keep
HTML out of your libraries", and "try to keep your interfaces stable".
Those are both tough to do.
Many people feel that XSLT is the way of the future. XSLT stands for
XSL transforms: changing one DTD to another. If your site's data lives
in XML (or can easily be turned into XML via php, etc), it's pretty
easy to write transformations which render the XML into pages, which
through progressive XSL transforms get navigation and contextual
information slowly piled on (think of slashdot or my-netscape or
scripting.com's little windows of information) until you end up with a
proper XHTML page.
It is not clear how exactly how to do this, how exactly one can avoid
binding too tightly to an XML DTD, the same way you have the problem
right now of tying too tightly to PHP functions.
If at all possible, take a serious look at the lambda function of php -
the ability to dynamically create code and return a reference to a
function. In order to fully grok its power you might need to read
something like The Structure and Interpreation of Computer Programs, a
classic in computer science, which does all of its cool stuff with
Lisp.