Separating Content and Presentation with PHP

Daftendirekt

Hello all, just looking for a little advice here.

I'm teaching myself some PHP/SQL at the moment, and I'm having a little bit of trouble figuring out when it's a good or bad idea to mix your PHP and HTML code. I've been Googling and keep stumbling across pages discussing the MVC and separation of presentation and content, but it's just not clicking with me.

For example, are you supposed to build your entire HTML document as a PHP string and then echo it to the browser? Or should you write your HTML as normal, nesting your PHP where ever it's needed? Or should you write up a template PHP file, include it in every page, and write to a content div or something similar?

Sorry if this is a vague question, but it isn't any specific part of the language I'm having trouble with, just this concept. I think what would really help is seeing the code behind a simple example PHP website. I know there's lots of PHP sample code on the net, but it seems mostly geared towards teaching the language itself. Anyone know of anything like this? Or anyone able to point me in the right direction?

Thanks for reading!

colm_c

Using procedural PHP this can be tricky and difficult to maintain, since by it's nature PHP can just be put into part of the page.

The idea is that logic/data retrieval should be done in one central place and your frontend is basically a templating system which displays your data using the already processed data. The template is a combination of php + html.

Best to use an MVC framework which will do the separation for you, and allow you to keep your presentation as separate from your logic as possible.

Frameworks to look at would be:

CakePHP
Laravel
CodeIgnitor

There are many more, but all will have an MVC structure which should help you understand the idea a bit more.

ThrowinShapes

I agree with colm_c. Ideally data should be given to the template, and then you do your conditionals or loops to produce the result that the user sees. E.g. Is user logged in? Then display log out link. Else, display log in link.

I'm finding Laravel is the most intuitive at the moment. Their documentation is great and they have an active community http://laravel.com/docs

There's also Laracasts - https://laracasts.com/series/laravel-from-scratch
Some resources are free, and if you plan on digging in then it's $9 a month.

The Corinthian

Daftendirekt wrote: »

For example, are you supposed to build your entire HTML document as a PHP string and then echo it to the browser?

That would be highly inefficient in many cases; if there's a lot of processing involved, then it would make sense to flush the buffer so send some content out while the rest is still being processed and rendered.

Or should you write your HTML as normal, nesting your PHP where ever it's needed? Or should you write up a template PHP file, include it in every page, and write to a content div or something similar?

You would write a framework that follows a model–view–controller architecture, nether of those two approaches you suggest would satisfy this, from what I can see. There's also no reason to presume that everything needs to be processed at the server.

colm_c wrote: »

Best to use an MVC framework which will do the separation for you, and allow you to keep your presentation as separate from your logic as possible.

You know, that as a result of the increased availability of caesarian procedures in hospitals, very few doctors even know how to turn a baby in a breach birth. That's how I feel about frameworks in general.

smcelhinney

The Corinthian wrote: »

You know, that as a result of the increased availability of caesarian procedures in hospitals, very few doctors even know how to turn a baby in a breach birth. That's how I feel about frameworks in general.

Good analogy, but conversely, if Caesarian is available, and is by its nature less risky than turning a baby in a breach birth, then it should be used. N'est-ce pas?

We're still talking about PHP here folks, you havent stumbled into the Parenting forum.

The Corinthian

smcelhinney wrote: »

Good analogy, but conversely, if Caesarian is available, and is by its nature less risky than turning a baby in a breach birth, then it should be used. N'est-ce pas?

I'd have my doubts that surgery is less risky than turning. Nonetheless, that wasn't my point at all.

My point was that while there's no need to reinvent the wheel, it's probably a good idea that you know how a wheel works and could reinvent it if you had to. Frameworks have become so prevalent, programming languages so abstracted, that many 'developers' don't even seem to understand the most basic of concepts, like how TCP/IP works.

It's made us increasingly dependant on 'other people's code' and resulted in a lot of imperfect solutions as we increasingly seek to tailor the client's requirements to what a framework, for example, will allow, rather than the reverse.

Still, better for those of us who can reinvent the wheel.

</rant.over>

Colonel Panic

Your post highlights what I think is a bit of a software development crisis.

Overall, I think it's great that the cost of entry to write software is lower. The richness of some frameworks and libraries out there is a Good Thing. But yes, it's important to know how to do things from scratch, even if only as a toy/learning exercise.

This applies to things like templates, dependency injection, routing web requests, writing to response sockets, sockets themselves.

It's a dilemma though, you simply cannot always start from first principles in a real-world environment. I've looked into a lot of this in my own time out of curiosity. Seeing magic in frameworks disturbs me and I need to peek behind the curtain.

It reminds me the scifi trope where a civilisation forgets how to maintain their technology and face extinction as a result!

Daftendirekt

Thanks for all the replies. I think I've got my answer anyway! I'll start looking into templating and see how I get on with that.