The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

My comments were related to saving mark-up (rather than data) in the database. Is that what you are saying is OK?

No I would agree with you there. There are some CMS systems that do storage in the database, but I try to keep database activity to a minimum. Getting markup from the db along with everything else you want to do with it, just increases the load. I would vote no on that idea, unless it's a CMS and your getting bits and pieces.

Separation isn't just so that other people can edit your layout. Even if you're the only one working on the project, if you feel like changing your layout by moving things around later and you didn't separate your presentation and logic, you'll be crying because of all the work you need to do.

Personally I wouldn't store templates in a DB, but if you want to and you want to use variable names, you would do the same thing as you do with regular template files. Either parse a templating language or use eval().

My style is to put business logic at the top of the PHP file. Either by using include/require statements or by using code directly. Then the bottom of the file is presentation logic. In most cases, this is HTML which escapes to PHP when needed. This allows me to read the HTML source code and get a better feel of the page layout. Another advantage is that I can see the page layout in a WYSIWYG editor (should I want to do that).

Take everything I said above, and forget it! Firstly, HereDoc is great . Secondly, getting templates out of the database isn't a great way of going about things and thirdly using an MVC approach is much better.

Splitting into files creates an annoyance when editing, even though organisation may be a bit better.

Of course, the example above isn't perfect. However, it just so happens that 'perfect code' really doesn't exist - programming is a constant journey, you always learn new things and your methods can change. This is why this thread wasn't a great one, because it's such an ambiguous topic. Some people have certain ways of doing things, others have others. In the end it comes down to what suits you and what suits the situation.

Jake Arkinstall
"Sometimes you don't need to reinvent the wheel;
Sometimes its enough to make that wheel more rounded"-Molona