Integrating PHP and HTML
Moderator: General Moderators
Integrating PHP and HTML
I read in "Bad Practice!" that integrating PHP into HTML tables, etc is, well, bad practice in some cases.
I know the syntax of putting the PHP data into an HTML table, but how could one do it to make it "efficient"? include()? echo()?
I know the syntax of putting the PHP data into an HTML table, but how could one do it to make it "efficient"? include()? echo()?
-
malcolmboston
- DevNet Resident
- Posts: 1826
- Joined: Tue Nov 18, 2003 1:09 pm
- Location: Middlesbrough, UK
it is not considered bad if you are doing something like
however it is considered bad practice 2 do this
this is something i for one am guilty of, however i feel comfortable with my own HTML skils and im the only person coding my sites so its fine for me, but i can see the problem when working as a team on very large sites, and besides it can be easily avoided most of the time
Code: Select all
<td><?php print $_POST['something'] ?></td>
// this cannot be helped in 90% of casesCode: Select all
<?php
print "<table>
<tr>
<td>$_POST[something]</td>
</tr>
</table>-
The Monkey
- Forum Contributor
- Posts: 168
- Joined: Tue Mar 09, 2004 9:05 am
- Location: Arkansas, USA
This is an interesting topic!
I see why using echo/printf to echo html isn't such a good idea, now.
I just thought I would post that if you have if() or while() statements that you can close the php tag and insert your html like this:
I see why using echo/printf to echo html isn't such a good idea, now.
I just thought I would post that if you have if() or while() statements that you can close the php tag and insert your html like this:
Code: Select all
<?PHP
if($var == "foo") {
?>
<td>Hi I Like Pie</td>
<?PHP
} else {
?>
<td>I don't like pie</td>
<?PHP
}
?>-
penguinboy
- Forum Contributor
- Posts: 171
- Joined: Thu Nov 07, 2002 11:25 am
If this is a question about using tables, see http://www.w3.org/TR/WCAG10.
Html shouldn't appear anywhere in php scripts relating to the "business logic" layer. Business logic is the sum total of business rules eg the queries with which your scripts collect sets of data from a database. A well-designed script has a cleanly separated "model" for each client page: this applies business logic to fetch a set of unformatted data.
The display layer (aka the presentation layer or view) applies formatting to data sets created by the biz layer. The point of a separate layer is that, in general, it is always a good thing to parcel up scripts into separate areas of responsibility. Code is much easier to work with for a start. It's easier to identify the guilty party when things go wrong. A modular design sometimes makes it possible to re-use bits in other projects. If you had a hardware store you wouldn't just dump all the nuts, bolts, fittings etc in one big pile in the middle of the shop floor: everything gets organised in its own display space. Same deal with code.
Apart from these general benefits, a clean model/view separation has a number of specific advantages. The model creates a bunch of unformatted data: all the formatting is applied in the view. Hence, you can use the same model scripts to ouput data in different views. This might mean re-using bits of a forum module to create a simple article comments block. It also allows you to easily create different client output formats: html, xml, pdf etc - just create some new views.
Views apply formatting with a template (or templates) for each model. The simplest way to achieve this is to embed a bunch of echo calls in an html file. All the html is in the html file - no html polluting the model.
That isn't quite the same thing as saying never mix php and html. You can mix them up in the presentation layer if you require presentation logic. An example of presentation logic might be alternating background colours for forum post rows.
One other advantage of separate models and views: designers can work on the templates without having to know any php code. Template files can be opened in any wysiwyg editor.
Finally, if this is all new to you and sounds complicated, really it isn't. The aim is to make things simpler by writing well-organised scripts and by removing dependencies between different chunks of code. At the heart of it all is learning to write concise functions which do just one thing. These can then be shuffled around into whatever layer they belong. You can't design an app without these basic blocks to build it with. If the app is at all complex, the building blocks probably ought to be classes.
Html shouldn't appear anywhere in php scripts relating to the "business logic" layer. Business logic is the sum total of business rules eg the queries with which your scripts collect sets of data from a database. A well-designed script has a cleanly separated "model" for each client page: this applies business logic to fetch a set of unformatted data.
The display layer (aka the presentation layer or view) applies formatting to data sets created by the biz layer. The point of a separate layer is that, in general, it is always a good thing to parcel up scripts into separate areas of responsibility. Code is much easier to work with for a start. It's easier to identify the guilty party when things go wrong. A modular design sometimes makes it possible to re-use bits in other projects. If you had a hardware store you wouldn't just dump all the nuts, bolts, fittings etc in one big pile in the middle of the shop floor: everything gets organised in its own display space. Same deal with code.
Apart from these general benefits, a clean model/view separation has a number of specific advantages. The model creates a bunch of unformatted data: all the formatting is applied in the view. Hence, you can use the same model scripts to ouput data in different views. This might mean re-using bits of a forum module to create a simple article comments block. It also allows you to easily create different client output formats: html, xml, pdf etc - just create some new views.
Views apply formatting with a template (or templates) for each model. The simplest way to achieve this is to embed a bunch of echo calls in an html file. All the html is in the html file - no html polluting the model.
That isn't quite the same thing as saying never mix php and html. You can mix them up in the presentation layer if you require presentation logic. An example of presentation logic might be alternating background colours for forum post rows.
Code: Select all
<?php
/*
param (integer) $i - a row counter
*/
function _setBgColor($i)
{
if ($i % 2 == 0)
{
return POST_BGCOLOR_1;
} else {
return POST_BGCOLOR_2;
}
}
?>Finally, if this is all new to you and sounds complicated, really it isn't. The aim is to make things simpler by writing well-organised scripts and by removing dependencies between different chunks of code. At the heart of it all is learning to write concise functions which do just one thing. These can then be shuffled around into whatever layer they belong. You can't design an app without these basic blocks to build it with. If the app is at all complex, the building blocks probably ought to be classes.
Last edited by McGruff on Tue Aug 09, 2005 12:40 pm, edited 1 time in total.
Never print bare $_POST vars. These must be processed with htmlspecialchars to strip out any nasties such as <script>.malcolmboston wrote:it is not considered bad if you are doing something likeCode: Select all
<td><?php print $_POST['something'] ?></td> // this cannot be helped in 90% of cases
Also, if the post var contains quotes, it could mess up a redisplayed form which echo's previously submitted values.
Last edited by McGruff on Tue Aug 09, 2005 12:40 pm, edited 1 time in total.
- Toneboy
- Forum Contributor
- Posts: 102
- Joined: Wed Jul 31, 2002 5:59 am
- Location: Law, Scotland.
- Contact:
I've read and then re-read McGruff's helpful post and I sense he'd get frustrated (to put it mildly) if I said I was somewhat confused by it, although I am confused by it (don't tell him... I SAID DON'T TELL HIM!).
I'll have a go at understanding and explain my dilemma. Okay, there are ways to draw out your information separately from the actual page formatting, but what if you require PHP usage to get data and format it?
For instance:
My news pages have their data stored in a MySql database. No problem retrieving data for individual items, but for the index page? At the moment I've got a while... loop on that page, and it works a bit like this:
When the page first existed (built with help, admittedly) it was more in this format:
I changed the way I coded it as too often if I would make a change with the format I'd forget a <?php here or there. Is it really that bad a thing to do? 
My other problem is that I have a lot of content which is hard-coded html. If I had known more php when I started I would probably have done it a lot differently, but that's a story for another time.
I'll have a go at understanding and explain my dilemma. Okay, there are ways to draw out your information separately from the actual page formatting, but what if you require PHP usage to get data and format it?
For instance:
My news pages have their data stored in a MySql database. No problem retrieving data for individual items, but for the index page? At the moment I've got a while... loop on that page, and it works a bit like this:
Code: Select all
... {
echo "<td>$column1</td><td>$column2</td>";
}
...Code: Select all
... {
?>
<td><?php echo $column1;?></td>
<td><?php echo $column2;?></td>
}
...My other problem is that I have a lot of content which is hard-coded html. If I had known more php when I started I would probably have done it a lot differently, but that's a story for another time.
There are different approaches to templating but probably the best way to start is the simple embedded echo & include method ie:
(1) a script defines a bunch of unformatted vars
(2) include an html file with embedded echo's
If a the page contains rows, it's basically the same define vars / include html template method, except this time you are looping through an array, printing one row at a time.
In stage (1), define an array of table vars.
To print the rows, create a template function which will iterate over the array, this time including a row.htm file per row.
Add the "printRows()" fn somewhere in the main page template:
There are other template systems to look at but this is possibly the easiest way to get a grasp of the basic concepts. Once you have refactored scripts with separate models (biz logic) and views (presentation logic), it should be fairly easy to replace with a different template system later on - that's the whole point of layering.
(1) a script defines a bunch of unformatted vars
(2) include an html file with embedded echo's
If a the page contains rows, it's basically the same define vars / include html template method, except this time you are looping through an array, printing one row at a time.
In stage (1), define an array of table vars.
To print the rows, create a template function which will iterate over the array, this time including a row.htm file per row.
Add the "printRows()" fn somewhere in the main page template:
Code: Select all
<?php printRows($array); ?>- Toneboy
- Forum Contributor
- Posts: 102
- Joined: Wed Jul 31, 2002 5:59 am
- Location: Law, Scotland.
- Contact:
Interesting stuff.
One of things I remember reading about PHP was that you can make it as simple or complex as you like. Very true. A lot of times I think I've learnt an awful lot, and then I delve through some of the posts on here and realise there is still an awful lot more to learn.
I suppose you could always argue that there is a way to do something, and a better way to do something.
One of things I remember reading about PHP was that you can make it as simple or complex as you like. Very true. A lot of times I think I've learnt an awful lot, and then I delve through some of the posts on here and realise there is still an awful lot more to learn.
I suppose you could always argue that there is a way to do something, and a better way to do something.
stay away from putting any HTML in any PHP. There is no "OK" way to mix them. Contrary to what malcolmboston said, the two never mix, and you end up with horrific HTML and funky-looking scripts. Templating is the way forward. Complete, 100% seperation of code and HTML, yet retaining the ability to dynamically create large table structures (should you need to
)
- launchcode
- Forum Contributor
- Posts: 401
- Joined: Tue May 11, 2004 7:32 pm
- Location: UK
- Contact:
PHP was *designed* in the first place so you can embed it into HTML (and vice versa!) and it's very good at it (read: very fast).
Templating is all fine and dandy in the right situations, but not every script will benefit from the overhead. A lot of people consider PHP itself to actually be a templating language (and they're not wrong either). But lots like to use Smarty or FastTemplate, etc.
If your project demands an n-tier approach then you have to look at some templating solution, but you can still use html/php on the presentation layer.
Templating is all fine and dandy in the right situations, but not every script will benefit from the overhead. A lot of people consider PHP itself to actually be a templating language (and they're not wrong either). But lots like to use Smarty or FastTemplate, etc.
If your project demands an n-tier approach then you have to look at some templating solution, but you can still use html/php on the presentation layer.