Separate PHP from HTML

André Næss · André Næss

Robert Spielmann:

> Hi all,
>
> the mangling of PHP and HTML tends to get on my nerves when developing
> websites with a bigger volume, e.g. with big layouts or with SQL
> connectiviy. Is there a comfortable way to separate PHP code from the
> HTML? If the recommendation is to use templates, which is a fast and small
> template engine?

How does it get on your nerves? What problem are you trying to solve? In
many cases I think people apply templates without really needing them,
presumably because "everyone else is doing it", so if you elaborate I might
be able to offer some advice.

André Næss

Bruno Desthuilliers · Bruno Desthuilliers

Robert Spielmann wrote:

> Hi all,
>
> the mangling of PHP and HTML tends to get on my nerves when developing
> websites with a bigger volume, e.g. with big layouts or with SQL
> connectiviy. Is there a comfortable way to separate PHP code from the
> HTML? If the recommendation is to use templates, which is a fast and small
> template engine?
>

Well... PHP is already a kind of template language, depends on how you
use it. I'm pretty new to PHP but right from the start I worked with the
following 'architecture' :

- one or more .inc source files, which implement the logic. Absolutely
no 'print', not a single 'echo' in all these files. Pure code.

- one 'setup.inc' file that wrap the calls to the the logic layer,
handle sessions and connection problems, define some 'pretty printers'
functions etc

- one or more .php pages, mostly simple HTML pages, with just three or
four calls to the printers functions from setup.inc for the dynamic
parts. I guess you could those pages 'templates'.

- and of course CSS for the styles, so I don't have to care about this
in the setup.inc's printer functions.

A typical (and somewhat simplfied !) php page would looks like this :

<?php
require_once('setup.inc');
initPage();
?>

<html>
<head>
<?php printHead() ?>
</head>
<body>
<div id="header">

<?php printMenu() ?>

</div>

<div id="content">

<?php printContent() ?>

</div>

<div id="footer">

<?php printFooter() ?>

</div>
</body>
</html>

This way I have a clear separation between logic and presentation, with
almost no 'mangling' of php and html code. The php 'template' page only
depends on the setup.inc file, si I can change presentation without
impact on the logic, and vice-versa. The only 'weak' part is the
setup.inc, but it doesn't have to be a huge file, cause there is
(almost) no logic in it, just dispatching args, getting results, and
formatting.

I'm not sure this is the standard PHP way, nor the better, but at least
it works, and it's (IMHO) clean.

HTH,
Bruno

Jeffrey Silverman · Jeffrey Silverman

On Tue, 29 Jul 2003 22:19:33 +0200, Bruno Desthuilliers wrote:

<snip!>

> This way I have a clear separation between logic and presentation, with
> almost no 'mangling' of php and html code. The php 'template' page only
> depends on the setup.inc file, si I can change presentation without impact
> on the logic, and vice-versa. The only 'weak' part is the setup.inc, but
> it doesn't have to be a huge file, cause there is (almost) no logic in it,
> just dispatching args, getting results, and formatting.
>
> I'm not sure this is the standard PHP way, nor the better, but at least it
> works, and it's (IMHO) clean.
>
> HTH,
> Bruno

My $0.02:
I work in a small web dev office. It is just me/programmer and another
person/designer -- 2 people. Your basic "architecture" is what we used
when we first started developing with PHP. It works great, but...

In our case, I have found that when working with more than one person on a
project it is better to separate the PHP from the HTML. My designer uses
Dreamweaver and tends to develop HTML layout in a WYSIWYG fashion. This
breaks/does not work when you use the above architecture, because
Dreamweaver does not execute the PHP and thus large chunks of layout are
missing from WYSIWYG.

We have tried a couple of template engine classes to achieve further
separation. The HTML is truly *just* HTML and no PHP. This works much
better for us. The designer need never know how a bit of textual data is
created -- only that it will be created. The templates are all full-page
HTML layouts that appear "correctly" in Dreamweaver.

We have been using the bTemplate class, although, of course, there are
dozens of others:
[url]http://www.massassi.com/bTemplate/index.php?page=home[/url]

Incidentally, I *hate* Dreamweaver, but I can't get my designer to do
things differently.

Of course, *most* important in any multi-person project -- even two people
-- is communication! Talk to each other.

later...
--
Jeffrey D. Silverman | jeffrey AT jhu DOT edu
Johns Hopkins University | Baltimore, MD
Website | [url]http://www.wse.jhu.edu/newtnotes/[/url]

Robert Spielmann · Robert Spielmann

André Næss <andrena.spamreallysucks@ifi.uio.no> wrote in
news:bg6b3p$nl9$1@maud.ifi.uio.no:

> How does it get on your nerves? What problem are you trying to solve?
> In many cases I think people apply templates without really needing
> them, presumably because "everyone else is doing it", so if you
> elaborate I might be able to offer some advice.
>
> André Næss

Hello to Norway,

for example form processing scripts with case statements, like:

switch($action)
{
case "reg" :
{ ?>
<HTML>...<FORM>...etc.
?>
}; break;

case "process" :
// do something with the form data
[...]
case "feedback" :
// output other HTML with status message
}

This results in a fine (irony) mixup of HTML and PHP, can you imagine what
I mean? This tends to happen in other cases, too. What would you propose
in order to unmix that? I am tending to write functions, like Bruno
Desthuilliers proposes. Any other ideas?

Cheers,
Robert

Christian Quentin · Christian Quentin

Hi,

I've been using templates for a while and it seems to me that it's one of
the best ways in many situations where you want to seperate HTML from PHP
code.
When you want to achieve this, the 2 main options are :
- build PHP functions that create basic HTML code and call the functions
needed to build your page. Everything will be in the code and no HTML editor
can help your team. Most of the conception of the site relies on a
developper.
- build HTML pages the usual way, signal variable information by a specific
syntax ({text_to_replace} for example) and use a PHP code outside HTML pages
to prepare and replace variable information areas by their real values. A
template engine usually helps in doing that.

I'm using templates mostly because we're working on multi-lingual sites and
we don't want to duplicate PHP code many times which would end up in a
maintenance nightmare (HTML and PHP mangled in a french page would mean
english HTML plus same PHP code in the english page).
We decided to use templates and tried 2 engines : fastTemplate, ITX from the
PEAR library (usually integrated in Apache servers). They offer the same
basic functionnalities, the main advantage of ITX being its integration in
Apache, so no installation is required.
fastTemplate is not know as a very fast template engine but this was not a
real problem for us.
PHPLib also offers a similar template engine which seems to be one of the
fastest. We didn't use it because we didn't want to spend to much time in
installation.
Other sophisticated template engine (Smarty and this family) provide more
control on the engine behavior but require more time to get started. In the
end, you will put control instructions in the HTML which is what to try to
avoid... They also try to balance this complexity in the engine process with
a cache system which hardly reaches the performance of a simple PHPLib
engine. I think you can find comparative studies on the web (I found one in
french).

In the process of development, you can also get help from a tool like
Dreamweaver to generate HTML and PHP mangled together and seperate HTML from
PHP later. You would thus get help to generate your initial PHP code and
still be able to work with templates aftewards.

Christian

Jochen Daum · Jochen Daum

Hi Andre!

>>

>>> How does it get on your nerves? What problem are you trying to solve?
>>> In many cases I think people apply templates without really needing
>>> them, presumably because "everyone else is doing it", so if you
>>> elaborate I might be able to offer some advice.
>>>
>>> André Næss

>>
>> Hello to Norway,
>>
>> for example form processing scripts with case statements, like:
>>
>> switch($action)
>> {
>> case "reg" :
>> { ?>
>> <HTML>...<FORM>...etc.
>> ?>
>> }; break;
>>
>> case "process" :
>> // do something with the form data
>> [...]
>> case "feedback" :
>> // output other HTML with status message
>> }
>>
>> This results in a fine (irony) mixup of HTML and PHP, can you imagine what
>> I mean? This tends to happen in other cases, too. What would you propose
>> in order to unmix that? I am tending to write functions, like Bruno
>> Desthuilliers proposes. Any other ideas?

>
>Functions are neat for sites with few and similar layouts, but as the site
>grows the number of functions can grow very rapidly and maintenance becomes
>a nightmare. As for forms I used to handle them through a package I've
>written (I say used to because I don't do much PHP work these days). The
>way this worked was that I had a file which was a mix of HTML and PHP and
>defined the layout of the form (I guess you could call it a form template).
>In the layout file I had simple calls to output the different form fields.
>These call were coded so as to know what was the current state of the form.
>If the form had been posted with errors, error messages would be output as
>defined in the layout file, otherwise the form would be printed normally. I
>put all the business logic that determined whether the form had been
>correctly posted in a separate structure, but most of the necessary
>validation code was already written, so I rarely had to write any
>validation code once this package was done (and any validation code could
>be added to the package once written).
>
>This approach allowed me to write complex forms with many different data
>types as input and lots of different error states in very little time. All
>I usually had to do was define the layout and the interaction with the
>backend. There are plenty of Form classes out there, but I found them all
>to be too low-level. You typically had to define all the form fields
>through a fairly complex process, and then write much of the validation
>could separately. You also had to do the layout programatically rather than
>simply by mixing code and HTML like in my layout files.
>
>There is a second, and maybe even more important benefit to this approach.
>This is that once you've defined a data type and the rules for its
>validation you can accept that type of data in your application knowing
>that it's safe. This makes it much easier to write secure applications.
>Should you find a bug in your data validation code, no problem, you fix it,
>and it should be fixed for all applications that use this code.
>

It seems I invented your wheel or the other way around. Only, I did it
with templates.

>Template solutions are generally slow, and in many cases rather wasted
>because they wind up implementing large portions of PHP, just slower and
>less intuitive. The goal is often to allow designers to use them, but if
>the designers will have to learn a language which contains so large parts
>of PHP, why not simply teach them the necessary parts of PHP?

Hmm. I'm a fan of simplifying it, so I have only two constructs in my
template system. When I was working with a designer, it was a real
benefit and now that I'm working without one, it is a benefit to me as
well.

>
>As for generating XML and then apply XSLT I'd think twice. After all, HTML
>is just an application of XML, and so you gain very little at the price of
>a lot of extra work. The code which generates the XML will necessarily
>contain a mix of XML and PHP, and I frankly can't see how that's different
>from a mix of HTML and PHP.
>

(...)

Jochen

--
Jochen Daum - CANS Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
[url]http://sourceforge.net/projects/phpdbedittk/[/url]

Jochen Daum · Jochen Daum

Hi Andre!

On Wed, 30 Jul 2003 21:42:19 +0000, André Næss
<andrena.spamreallysucks@ifi.uio.no> wrote:

>Christian Quentin:
>

>> - build HTML pages the usual way, signal variable information by a
>> specific syntax ({text_to_replace} for example)

>
>Or simply: <?= $text_to_replace ?>

This came up in the template discussion the other day and I still
wonder, if it has enough characters to mess up with syntax errors or
if it better than {}.

But what a template system with simple loops and ifs gives me is that
I can build test code into the template system to see, if my code
covers the whole template. And I can also control how often I assigned
a value to a variable.

>
>That way you avoid having to implement a small and probably slow interpreted
>language inside an already slow interpreted language. And once your
>designers want to do the alternating-row-color-thingy you can teach them
>enough PHP to do that.

I think the mistake is that people want to build the rowcolor code
into the template. Only the color value should be in the template.

This is how a typical template of mine looks like:

Cheers, Jochen


<div align="center">Click on any column heading to sort</div>
<table width="100%" cellpadding="3" cellspacing="1" id="rowblock"
border="0">
<thead style="{cursor: hand;background-color: #0066CC;}">
<tr>

<th> </th>


<th width="{TDWIDTH}"><a class="rowhead"
href="{SORTLINK}">{FIELD}</a> <img src="pic/empty.gif" /></th>


<th width="25"> </th>


<th> </th>

</tr>
</thead>
<tbody>


<tr class="row" bgcolor="{ROW_BG_COLOR}"
onclick="location.href='{CHANGE_BUTTON_LINK}';"
onmouseover="this.style.backgroundColor='{ROW_HIGH LIGHT}'"
onmouseout="this.style.backgroundColor='{ROW_BG_CO LOR}'"
valign="top">

<td>
<img src="openedbranch.gif" border="0" alt="Close this branch">


<img src="closedbranch.gif" border="0" alt="Open this branch">


<img src="../pic/ftv2node.gif" border="0">

<img src="../pic/ftv2folderopen.gif" border="0"></td>


<td class="{TDCLASS}" width="{TDWIDTH}">
<a name="{ANCHOR}"></a>
{FIELD}</td>


<td width="25">
<a href="{ACTIONINSERTUNDER}"> <img src="../pic/answer.gif"
height="25px" width="25px" valign="middle"
border="0" style="margin:0px;padding:0px;" alt="Answer">
</a>
</td>


<td width="10"> <a
href="{DETAIL_BUTTON_LINK}">{DETAIL_BUTTON_TEXT}</a> </td>


<td width="10"> <a
href="{CHANGE_BUTTON_LINK}">{CHANGE_BUTTON_TEXT}</a> </td>


<td width="10"> <a
href="{DELETE_BUTTON_LINK}">{DELETE_BUTTON_TEXT}</a> </td>

</tr>

</tbody>
</table>


No records found.

>
>André Næss

--
Jochen Daum - CANS Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
[url]http://sourceforge.net/projects/phpdbedittk/[/url]

André Næss · André Næss

Christian Quentin:

> - build HTML pages the usual way, signal variable information by a
> specific syntax ({text_to_replace} for example)

Or simply: <?= $text_to_replace ?>

That way you avoid having to implement a small and probably slow interpreted
language inside an already slow interpreted language. And once your
designers want to do the alternating-row-color-thingy you can teach them
enough PHP to do that.

André Næss

Jeffrey Silverman · Jeffrey Silverman

On Wed, 30 Jul 2003 21:42:19 +0000, André Næss wrote:

> Christian Quentin:
>

>> - build HTML pages the usual way, signal variable information by a
>> specific syntax ({text_to_replace} for example)

>
> Or simply: <?= $text_to_replace ?>
>
> That way you avoid having to implement a small and probably slow
> interpreted language inside an already slow interpreted language. And once
> your designers want to do the alternating-row-color-thingy you can teach
> them enough PHP to do that.

I beg to differ on that. Have you *tried* to teach a designer PHP?

Separate separate separate, that's the *only* way!!! Just do it, I'm right
and your not. oh, oops, got a bit too snotty there, sorry, heh heh.

--
Jeffrey D. Silverman | jeffrey AT jhu DOT edu
Johns Hopkins University | Baltimore, MD
Website | [url]http://www.wse.jhu.edu/newtnotes/[/url]

Bruce Lewis · Bruce Lewis

Robert Spielmann <des64_nospam_@gmx.de> writes:

> for example form processing scripts with case statements, like:
>
> switch($action)
> {
> case "reg" :
> { ?>
> <HTML>...<FORM>...etc.
> ?>
> }; break;
>
> case "process" :
> // do something with the form data
> [...]
> case "feedback" :
> // output other HTML with status message
> }

I don't actually use PHP, but this same "logic/presentation separation"
issue comes up with BRL. I'm sure there's a PHP equivalent to BRL code
like this:

[
(define-input (string->symbol action))
(case action
((reg) (paste "reg.brl"))
((process) (paste "process.brl"))
((feedback) (paste "feedback.brl"))
(else (error "action required")))

Then the individual pasted pages are freed from the program structure.

PHP has include() or somesuch, right?

--
"Notwithstanding fervent argument that patent protection is essential
for the growth of the software industry, commentators have noted
that `this industry is growing by leaps and bounds without it.'"
-- US Supreme Court Justice John Paul Stevens, March 3, 1981.

Jochen Daum · Jochen Daum

Hi Andre!

>>>> - build HTML pages the usual way, signal variable information by a
>>>> specific syntax ({text_to_replace} for example)
>>>
>>>Or simply: <?= $text_to_replace ?>

>>
>> This came up in the template discussion the other day and I still
>> wonder, if it has enough characters to mess up with syntax errors or
>> if it better than {}.

>
>Well the designer can obviously create syntax errors, but hey, you're
>working together with him, not against him right? Or was that what you
>meant?

I would suppose so, but if I was in a freelance environment, I would
also like to be on the safe side, if I worked against him.

>

>> But what a template system with simple loops and ifs gives me is that
>> I can build test code into the template system to see, if my code
>> covers the whole template. And I can also control how often I assigned
>> a value to a variable.

>
>Uh... sorry but I'm not sure if I understand what you mean there mate...

If I process a loop construct in the tenmplate, which isn't there, my
template system can give me a debug warning. So I can make sure,
template and code fit together.

>

>>>That way you avoid having to implement a small and probably slow
>>>interpreted language inside an already slow interpreted language. And once
>>>your designers want to do the alternating-row-color-thingy you can teach
>>>them enough PHP to do that.

>>
>> I think the mistake is that people want to build the rowcolor code
>> into the template. Only the color value should be in the template.

>
>No, it shouldn't. It should be something the designer can control because
>it's *presentation*.
>

>> This is how a typical template of mine looks like:

>

>> 
>> <th> </th>
>>

>
>What's a case?
>

>> 
>>
>> <tr class="row" bgcolor="{ROW_BG_COLOR}"

>
>Ok so the guy who programmed the iterator "ROW" has to make sure
>ROW_BG_COLOR changes for every iteration? If I understand this correct that
>means that your separation isn't a proper separation because the designer
>can't change the ROW_BG_COLOR (or rather, the X number of colors it
>alternates between). What you want is a system where the designer is fed a
>chunk of data and has complete control over how it ends up looking. That
>means that designers have to understand simple data structures (at least
>one, and most designers are able to understand XML!).

Its a good point. I'm not working currently with a designer, but what
I actually do in most templates, is only assigning a css class. That
way, it is only logically defined by the template again.
But I would expect this decision to be in the domain of the designer.

Also, I haven't met this XML designers yet, but maybe my experience is
not enough.

Interesting discussion though.

Jochen
--
Jochen Daum - CANS Ltd.
PHP DB Edit Toolkit -- PHP scripts for building
database editing interfaces.
[url]http://sourceforge.net/projects/phpdbedittk/[/url]

André Næss · André Næss

Jeffrey Silverman:

> On Wed, 30 Jul 2003 21:42:19 +0000, André Næss wrote:
>

>> Christian Quentin:
>>

>>> - build HTML pages the usual way, signal variable information by a
>>> specific syntax ({text_to_replace} for example)

>>
>> Or simply: <?= $text_to_replace ?>
>>
>> That way you avoid having to implement a small and probably slow
>> interpreted language inside an already slow interpreted language. And
>> once your designers want to do the alternating-row-color-thingy you can
>> teach them enough PHP to do that.

>
> I beg to differ on that. Have you *tried* to teach a designer PHP?

No, but my main point was that most template languages tend to implement
most of the stuff that PHP offer, and so the designers have to learn that
anyway. Besides you don't need to learn them everything. And you can build
a library of functions they can use to simplify it further.

But I guess the best solution would be a template language which is simple
and offers the most common operations, and is implemented as an extension
to PHP so that it doesn't waste so much resources. Or even better: a new
language which builds templates directly into the language.

André Næss

André Næss · André Næss

Brandon Blackmoor:

[...]

AOL! :)

André Næss

André Næss · André Næss

Jochen Daum:

> It seems I invented your wheel or the other way around. Only, I did it
> with templates.

One of the things I was least satisified with in my solution was that I had
to introduce some rudimentary template constructs (an if-clause and basic
variable replacement) to achieve the simplicity I was after :/ PHP as a
language is not very well suited to this sort of thing because you
basically want to extend the language. Lisp would be a much better option I
think. But these days I don't have time to think about web-programming very
much as I am busy with my Master thesis :/

>>Template solutions are generally slow, and in many cases rather wasted
>>because they wind up implementing large portions of PHP, just slower and
>>less intuitive. The goal is often to allow designers to use them, but if
>>the designers will have to learn a language which contains so large parts
>>of PHP, why not simply teach them the necessary parts of PHP?

>
> Hmm. I'm a fan of simplifying it, so I have only two constructs in my
> template system. When I was working with a designer, it was a real
> benefit and now that I'm working without one, it is a benefit to me as
> well.

But can you achieve all you want to do, or do you have to put code to
implement stuff like alternating background colors in PHP? A really good
template solution would allow you to extract stuff from a database and send
it right to the presentation layer where the designer can define what it
should end up looking like. That's MVC!

André Næss

Jeffrey Silverman · Jeffrey Silverman

On Thu, 31 Jul 2003 21:38:29 +0000, André Næss wrote:

<snip!>

> But I guess the best solution would be a template language which is simple
> and offers the most common operations, and is implemented as an extension
> to PHP so that it doesn't waste so much resources. Or even better: a new
> language which builds templates directly into the language.
>
> André Næss

Sounds like ColdFusion to me!

Does anyone use coldfusion anymore? I'm out of the loop...
--
Jeffrey D. Silverman | jeffrey AT jhu DOT edu
Johns Hopkins University | Baltimore, MD
Website | [url]http://www.wse.jhu.edu/newtnotes/[/url]

Bruce Lewis · Bruce Lewis

André Næss <andrena.spamreallysucks@ifi.uio.no> writes:

> Jochen Daum:
>

> > It seems I invented your wheel or the other way around. Only, I did it
> > with templates.

>
> One of the things I was least satisified with in my solution was that I had
> to introduce some rudimentary template constructs (an if-clause and basic
> variable replacement) to achieve the simplicity I was after :/ PHP as a
> language is not very well suited to this sort of thing because you
> basically want to extend the language. Lisp would be a much better option I
> think. But these days I don't have time to think about web-programming very
> much as I am busy with my Master thesis :/

When you say "Lisp", do you include Scheme, or do you mean specifically
Common Lisp?

--
"Notwithstanding fervent argument that patent protection is essential
for the growth of the software industry, commentators have noted
that `this industry is growing by leaps and bounds without it.'"
-- US Supreme Court Justice John Paul Stevens, March 3, 1981.

Brandon Blackmoor · Brandon Blackmoor

Mattiasz wrote:

> That same site has a nice article on the philosophy
> of template engines and also contains the code for a
> class that implement PHP-Only templates:
> [url]http://www.massassi.com/php/articles/template_engines/[/url]

Good article. Thanks for the link.

Separate PHP from HTML

Thread Tools

Display

Re: Separate PHP from HTML

Similar Questions and Discussions

separate Flash from HTML

Coldfusion & data separate

separate list in pages x

.net framework 1.0 and 1.1 processes separate?

CSS into separate file??

Re: Separate PHP from HTML

Re: Separate PHP from HTML

Re: Separate PHP from HTML

Re: Separate PHP from HTML

Re: Separate PHP from HTML

Re: Separate PHP from HTML

Re: Separate PHP from HTML

Re: Separate PHP from HTML

Re: Separate PHP from HTML

Re: Separate PHP from HTML

Re: Separate PHP from HTML

Re: Separate PHP from HTML

Re: Separate PHP from HTML

Re: Separate PHP from HTML

Re: Separate PHP from HTML

Re: Separate PHP from HTML

Posting Permissions