Dividing PHP and HTML - maybe easy

**News Me** · Jul 17 '05, 11:34 AM

Re: Dividing PHP and HTML - maybe easy

Dave Smithz wrote:[color=blue]
> Hi,
>
> Summary:
> Best way to divide out the HTML and PHP in some code I inherited. How can I
> keep the HTML files separate?
>
> Full Details:
> I've now been working two weeks on PHP / MySQL code I inherited and the
> client is a happy bunny. This was my first crash course outing with PHP, but
> with basic PERL experience found it fairly easy to pick up and used the code
> I inherited as my guide.
>
> However, the current code has every page as being top half php, bottom half
> HTML (with some embedded PHP where necessary)
>
> 
<? occasional bit of PHP ?>
<P>
-----

NM

--
convert UPPERCASE NUMBER to a numeral to reply

**laurence** · Jul 17 '05, 11:34 AM

Re: Dividing PHP and HTML - maybe easy

Hi Dave.

One way to completely separate PHP & HTML is to use Templates.

Two templating systems come to mind:

1. PEAR::HTML_Temp late_IT
Man page:

Manual :: HTML_Template_IT

http://pear.php.net/manual/en/package.html.html-template-it.php

PEAR Home: http://pear.php.net/
PHP comes with all required to install PEAR core elements, among which (I
think) is HTML_Template_I T.
I have used this extensively and find it works extremely well. My only
concern is that I find template load time is relatively high, with my 10K+
templates taking 0.2 - 0.3 seconds to load.
This is why I intend to investigate another templating system...

2. Smarty.
Home: http://smarty.php.net/
I have not used this yet, but note it has a smart caching feature, caching
templates once loaded. Heaps of other features also. Just reading it myself
now.

Probably plenty of other templating solutions, but these two are part of the
php nuclear family, with plenty of news group and other support.

Hope this helps.

Laurence

"Dave Smithz" <SPAM FREE WORLD> wrote in message
news:421540bd$1 @news1.homechoi ce.co.uk...[color=blue]
> Hi,
>
> Summary:
> Best way to divide out the HTML and PHP in some code I inherited. How can
> I
> keep the HTML files separate?
>
> Full Details:
> I've now been working two weeks on PHP / MySQL code I inherited and the
> client is a happy bunny. This was my first crash course outing with PHP,
> but
> with basic PERL experience found it fairly easy to pick up and used the
> code
> I inherited as my guide.
>
> However, the current code has every page as being top half php, bottom
> half
> HTML (with some embedded PHP where necessary)
>
> Eg.
> START OF FILE
> <?php
>
> do some general processing to set up variables
> ?>
>
> <HR>
>
> 
> <!-- note that the current code does not even output a HTML HEAD tag - any
> reason why this might be?--?
> <? occasional bit of PHP ?>
> <P>
> End of HTML
> END OF FILE
>
> The HTML pages are ugly and they have very much hard coded formatting
> information in them.
> Hence the application is entire need of an overall.
>
> What is the best way to approach this?
> I really would like to keep the HTML parts in another file so they could
> be
> editing in programs like dreamweaver to be honest. I obviously want to
> role
> out the use of CSS so that I can change the look and feel quickly.
>
> Is there a command in PHP that when the main processing is done you can
> reference another file which contains HTML to be displayed but none of the
> current variable information is lost.
> I say this because if I use the header(location :) command I have to repost
> the form variables which is pain.
>
> Ideally I could just have the main PHP bit in the code, and when it is
> done
> it references a HTML page that is displayed(That HTML page may contain
> snippets of PHP). So functionally things still work as they are, but it
> lets
> me put the HTML in a physically different file.
>
> I hope this makes sense.
>
> Thanks in advance.
>
> Kind regards
>
> Dave
>
> PS: Having just written this, I then tried to open one of my PHP files in
> dreamweaver and what do you know, it opens and of course handles the PHP.
> Still I still think the question is valid and maybe I will be told it is
> not
> a good idea to use Dreamweaver to manage code with PHP in it.
>
>[/color]

**Chung Leong** · Jul 17 '05, 11:35 AM

Re: Dividing PHP and HTML - maybe easy

"Dave Smithz" <SPAM FREE WORLD> wrote in message
news:421540bd$1 @news1.homechoi ce.co.uk...[color=blue]
> Hi,
>
> Summary:
> Best way to divide out the HTML and PHP in some code I inherited. How can[/color]
I[color=blue]
> keep the HTML files separate?
>[/color]

"The downside of separating HTML from PHP code is you don't get to use PHP
in your HTML code."

That's a rather banal statement but it's a point that people often fail to
consider. PHP is a very powerful tool. When you exclude it from HTML then
you lose a lot of power in controlling the appearance of your web pages. My
advise is unless you really need to do it, don't.

Instead of separating code by technology (HTML vs PHP), separate them by
purpose. For example, I keep code that deal with the user interface in a
file call interface.php. It contains mostly HTML with some PHP sprinkled in:

<? function PrintHeader($ti tle) { ?>
<html>
<head>
<title><? echo htmlspecialchar s($title); ?></title>
</head>
<body>
<? } ?>
<? function PrintMessage($m sg) { ?>
<div>
...
</div>
<? } ?>
<? function PrintFooter() { ?>
</body>
</html>
<? } ?>

To print the various parts of the page I just call the appropriate function.

This is a more powerful technique than simply including a header.htm and a
footer.htm, as you can pass parameters to these functions and utilize PHP
functions for text manipulations. The file will also render correctly in a
browser/editor.

**Matt Mitchell** · Jul 17 '05, 11:35 AM

Re: Dividing PHP and HTML - maybe easy

"Chung Leong" <chernyshevsky@ hotmail.com> wrote in message
news:2MSdnUASM_ p6CojfRVn-uA@comcast.com. ..
[color=blue]
> "The downside of separating HTML from PHP code is you don't get to use PHP
> in your HTML code."[/color]

The downside of mixing php into your html is that you land up with
unmaintainable code, especially if you are creating a dynamic website for a
third-party (think customer?) who can only handle html.

It also makes redesigning the site a lot harder, since you have to be
incredibly careful about moving the PHP code around. Also, I would argue
that separating PHP and HTML files isn't "separating files by technology";
rather, it's "separating code and data".

Creating html-type templates, with simple text placeholders for fields,
allows non-expert users to play with the presentation without breaking the
site. It also allows you various other options, like:

- 'You can change anything in the /templates directory, just don't touch any
of the PHP files'

- Automatic uploading of template files, so that you can block the
client/intranet editor/whoever from editing/accessing the source code.
Apart from the potential considerations of "who gets to see the source
code", it also means you can provide users with a *safe* way to modify a
site's look

- Online editing of template files - use CMS-type markup to change the look
of a site, without any requirement for HTMl editing or FTP access, etc.

- Running all (or most) of your site through a single PHP file - I like to
use URL rewriting for this. Avoid duplicating the same code across multiple
files, so that you don't forget to change that essential line in 52
different places

- More readable code - you can see what's happening, and why, and where.

- Better code maintainability in general

- Better security - you can make sure that there are no unexpected PHP tags
in the templates

- etc, etc
[color=blue]
> That's a rather banal statement but it's a point that people often fail to
> consider. PHP is a very powerful tool. When you exclude it from HTML then
> you lose a lot of power in controlling the appearance of your web pages.
> My
> advise is unless you really need to do it, don't.[/color]

PHP *is* a very powerful tool, and like all powerful tools, performs best
when handled carefully. If you are fixing a climbing frame for a child,
using an arc-welder, you fix the frame and give it back to them. You don't
leave the welder there where they can use it.

Embedding php is great for quick-and-dirty tasks. If you're doing something
more complex, it is no longer quick, and all you're left with is dirty. I
would advise, only embed php in html if you have to. If you extend the site
in future, you may live to regret it!

Matt

NC · Jul 17 '05, 11:35 AM

Re: Dividing PHP and HTML - maybe easy

Dave Smithz wrote:[color=blue]
>
> Summary:
> Best way to divide out the HTML and PHP in some code I inherited.
> How can I keep the HTML files separate?[/color]

Templating might help...
[color=blue]
> 
> [/color]

Because <HEAD> and <BODY> tags became optional as of HTML 4.0,
perhaps?
[color=blue]
> Is there a command in PHP that when the main processing is done
> you can reference another file which contains HTML to be displayed
> but none of the current variable information is lost.[/color]
....[color=blue]
> Ideally I could just have the main PHP bit in the code, and when
> it is done it references a HTML page that is displayed(That HTML
> page may contain snippets of PHP). So functionally things still
> work as they are, but it lets me put the HTML in a physically
> different file.[/color]

Have you used include/require at all?

Cheers,
NC

**John Dunlop** · Jul 17 '05, 11:35 AM

Re: Dividing PHP and HTML - maybe easy

NC wrote:
[color=blue]
> Dave Smithz wrote:[/color]
[color=blue][color=green]
> > 
> > [/color]
>
> Because <HEAD> and <BODY> tags became optional as of HTML 4.0,
> perhaps?[/color]

The tags are not required by earlier versions either.

Their being omissible is not in itself a reason to omit
them. Ciwah's recommendation, I faintly recollect, is to
include both sets of tags.

Slainte!

--
Jock

**Chung Leong** · Jul 17 '05, 11:36 AM

Re: Dividing PHP and HTML - maybe easy

"Matt Mitchell" <m_a_t_t_remove _the_underscore s@metalsponge.n et> wrote in
message news:mLqRd.7688 8$68.17338@fe1. news.blueyonder .co.uk...[color=blue]
> The downside of mixing php into your html is that you land up with
> unmaintainable code, especially if you are creating a dynamic website for[/color]
a[color=blue]
> third-party (think customer?) who can only handle html.[/color]

Well, I'm not saying one should never use templates. If one of the
requirements is allowing the end-user to edit the HTML, then you implement
it, accepting the necessary trade off. If it's not, then why tie your hands
yourself?
[color=blue]
> It also makes redesigning the site a lot harder, since you have to be
> incredibly careful about moving the PHP code around. Also, I would argue
> that separating PHP and HTML files isn't "separating files by technology";
> rather, it's "separating code and data".[/color]

You are not saying much as why having PHP code in HTML makes for
unmaintainable code--other than that it is. No one is arguing for mixing
things up randomly. As I said, one should divide code up by purpose. If the
purpose of a block of PHP code is controlling some aspect of a webpage's
appearance, then it's perfectly natural to place it where it has its affect.
If you're changing the appearance of the site, then chances are, you need to
change any PHP code related to representation too.
[color=blue]
> Creating html-type templates, with simple text placeholders for fields,
> allows non-expert users to play with the presentation without breaking the
> site. It also allows you various other options, like:[/color]

Just wait till your non-expert user starts messing around with your input
fields and hyperlinks. It's a freaking support nightmare. HTML is hardly the
safe medium that you described. Make a small mistake and you have a
cross-site scripting vulnerability and the whole application is shot.
[color=blue]
> - Better security - you can make sure that there are no unexpected PHP[/color]
tags[color=blue]
> in the templates[/color]

One word: phpBB. The Santy worm exploited a weakness in phpBB's template
system.

**Dave Smithz** · Jul 17 '05, 11:38 AM

Re: Dividing PHP and HTML - maybe easy

"NC" <nc@iname.com > wrote in message[color=blue]
> Have you used include/require at all?[/color]

Errrrr, actually I had only read about require_once, but it would seem that
include can just allow me to have the HTML part (with little bits of
embedded PHP where necessary) in a separate file that is called with an
include.

Not tested it yet but it seems when I use an include it will be interpreted
as HTML treated as if in the same file. This is great and good enough for my
needs. Because I came to PHP from inheriting someone else's code, I have
missed a formal tutorial in some of the basics.

Cheers and let me know if I'm wrong on my assumptions above.

Regards

Dave

**Matt Mitchell** · Jul 17 '05, 11:39 AM

Re: Dividing PHP and HTML - maybe easy

"Chung Leong" <chernyshevsky@ hotmail.com> wrote in message
news:u_idncCh_K JpBovfRVn-pQ@comcast.com. ..
: Well, I'm not saying one should never use templates. If one of the
: requirements is allowing the end-user to edit the HTML, then you implement
: it, accepting the necessary trade off. If it's not, then why tie your
hands
: yourself?

Because that way I can change the way something looks, without having to
worry about how it works. It also means I can change the way it works,
without having to change the way it looks...

: You are not saying much as why having PHP code in HTML makes for
: unmaintainable code--other than that it is. No one is arguing for mixing
: things up randomly. As I said, one should divide code up by purpose. If
the
: purpose of a block of PHP code is controlling some aspect of a webpage's
: appearance, then it's perfectly natural to place it where it has its
affect.
: If you're changing the appearance of the site, then chances are, you need
to
: change any PHP code related to representation too.

So moving something displaying on the left of the page to the right is a
PHP, not an HTML issue???

: Just wait till your non-expert user starts messing around with your input
: fields and hyperlinks. It's a freaking support nightmare. HTML is hardly
the
: safe medium that you described. Make a small mistake and you have a
: cross-site scripting vulnerability and the whole application is shot.

No, it depends on what fields you let them substitute in, and how you do it.

If the list of available placeholders is something like

[field:user:user name] [field:site:site name]

without including things like
[field:config:db password]

then you're OK. If your template system is braindead enough to display
current filepath, database host, user password, etc, then it is a fault with
your templating system, and with your code, not with the concept of
templates. Similarly, the existence of computer viruses doesn't prove that
computers are useless, it proves that you have to adopt sensible security
practices.

Validate user data. Don't allow them to insert javascript, php code, sql
injections etc. Don't pass query strings into your app without checking
what they contain, and removing the nasty stuff.

:
: > - Better security - you can make sure that there are no unexpected PHP
: tags
: > in the templates
:
: One word: phpBB. The Santy worm exploited a weakness in phpBB's template
: system.
:

That's a flaw in phpbb's template system. I fail to see how a template
system that allows you to put
<?php
system('rm -fR ./*');
?>

or to allow an html file containing the same, can be a good thing.

Dividing PHP and HTML - maybe easy

Dividing PHP and HTML - maybe easy

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment