Web Development - The Line Between Code and Content?

markmcb asks: "I help design a LAMP web site and I'm constantly plagued by trying to decide on what level should I separate functional code and markup. Depending on what you read, some say embedding HTML in your PHP scripts [or Perl, or Java, or Ruby, or Python, etc] is bad while others say it's no big deal. However, seldom are any practical applications of such code cited. How is your site built? Do you mix HTML with your code? If not, how do you overcome the simple and easy method of doing so? Lastly, what performance gains/losses have you noticed by doing so?"

Comments

Simple

[neoform]

Seperated: If you want something modular and scalable (but slower)

Embedded: If you want something faster and easy to write (but not as scalable)

Logic vs Presentation

[illuminatedwax]

People will always tell you to "separate logic from presentation" and that is good advice - to a certain extent. I don't think that this is correct all the time, however, because it is not a correct statement per se because the two cannot always be separated. However, they usually can and usually are, and web pages are a good example of this. But what does "separate" mean? Does it mean physically moving your presentation to another file, generating it, etc.? There are many different ways, all of which work best in certain situations.

Here's what you should worry about instead:
1) Is the program readable?
2) Can you easily make changes in the program without having to change too many other parts of it?
3) Are you having to rewrite the same code too much?

Those are some pretty basic computer programming design concepts, and if you apply those, you'll find that the answer should be pretty clear. Just keep everything clean and life will be happier.

Separation good

[legLess]

Separation is good. I can trot out the old "let coders code and designers design," but I often do both, and there are other benefits. You should look at model view controller. You don't have to drink all the MVC kool-aid to get good ideas from it.

Wonder why Slashdot looks like ass? I've spent a lot of time hacking Slash source and, until their recent refactors (and maybe even now) there was markup everywhere in the Perl. It made a redesign impossible without actually writing code, and possible introducing bugs.

MVC says that the presentation layer should be separate from the rest of the application. If you think about it, that's the same idea as keeping presentation (e.g. CSS) separate from content (e.g. XHTML). That idea has clearly won out.

Performance can be a factor for smaller systems, but if you cache your templates or have them precompiled (e.g. JSP) it helps. Also, programmer efficiency is almost always more important than code efficiency. Keeping the controller code and the view separate allows you to find and fix code bugs without wading through all sorts of presentation logic. Who cares about how a nested list is constructed in XHTML when you're trying to find out why your app is barfing?

PHP is it's own template language.

[Bitsy Boffin]

So many people these days have bought into the Smarty templates stuff. But what they have forgotten is that PHP is perfectly good as a template language. Why are they using a whole separate language to do a job that the very language that the 2nd language is written in can do just as well?

I think it's that people are stuck on such total and complete separation of "logic" and "display" that they have this erroneous idea that the only way that can be done properly is to use two separate languages.

But ask yourself, is

  {Loop One $LoopVar1}
      <tr><td>{$LoopVar1}</td></tr>
  {/Loop}

any different to

    <?php
        foreach($One as $LoopVar1)
        {
            ?>
            <tr><td>{$LoopVar1}</td></tr>
            <?php
        }
    ?>

The answer I hope you see is, YES, the first one is heaps slower because the page has to be parsed for the second language and then executed either in that language, or more commonly TRANSLATED into PHP and executed in that instead!

The deal is, separate your Business/Application Logic from your Display Logic, but you don't need two languages to do that.

Sure if it makes it easier and faster for you then you might have some short hand notations to reduce coding, stuff like
    {$Foo}
which is replaced with
    <?php echo htmlspecialchars($Foo) ?>
or
    <form:input type="date" name="Foo" />
which is replaced with a text input with a value of $Foo and a calendar date picker button, these could save you a few minutes coding and also makes it much cleaner for the designer.

But stuff like
  {If Foo} stuff {/If}
or
  <loop var="Blah"> stuff </loop>
is just inventing another syntax for the hell of it, it gives you no advantage, and infact probably increases the amount of code you have to write.

Some people will say here that "oh designers shouldn't deal with PHP". But what they fail to realise is that most designers use "WYSIWYG" tools, principally Dreamweaver for the professionals (as much as hand coding is desirable, lets be realistic, graphic designers seldom do that). And here's the thing, Dreamweaver will do a much better job if the page contains some PHP than if it contains an arcane template language, even one as popular as Smarty. They are LESS likely to break stuff, and infact more likely to UNDERSTAND how the code works if it's in PHP and not in a template language.

Here are a some simple rules..
  * Have a minimum of 2 main files for each "page".
  * The first contains your application/"business" logic for the page, it processes, queries, sets everything up for the second page.
  * The second page contains your HTML and the minimal set of PHP to display that, you can use if, foreach, for, echo and the various formatting functions (htmlspecialchars, number_format etc) but that's about it unless you have a good reason.
  * Don't put html in strings. I don't want to see echo "<strong>Foo</strong>"; One exception to this is where it will stop the creation of invalid (or undesirable) HTML nesting in your source file because of some conditional output of extra bits of HTML, the reason for that is so it doesn't screw up in Dreamweaver or intelligent editors which can match tags - this will most often happen if you are making multi-column tables and need to output extra tr's based on some modulus of the record number in a loop.

If you follow this you have cleanly separated logic from display and your designers can now easily work with the display source.

What I've said here isn't just specific to PHP of course, just it's where I see this sillyness the most.

Re:Matter of Personal Preference?

[jalefkowit]

Wait until your project grows to a point where you're not the only person working on it, and then come back and tell us if you still feel this way.

Keeping markup out of your code means that you can, for example, bring in a graphic designer to change the look and feel your site/app without requiring that they know Perl (or PHP, or whatever) -- very few designers know, or care, about programming. And it means that you can bring in other programmers to fix bugs/add features without worrying that their changes will muck up the UI.

I never like this method

[SmallFurryCreature]

Project Leader: Right you coder, the HTML designer doesn't understand PHP so you got use a template language instead you never heard off.

Coder: Oh okay, I can do that, so Designer guy, you can help with learning this template language?

Designer: No, I never heard of it either and I am going to just delete any html I don't regonise just like I do with php tags.

Coder: Fuck.

And this ain't a joke. My introduction to templates went pretty much like this. In order to deal with a designer who kept removing PHP because of the design program she used I had to learn a new "language" wich didn't help since she still kept deleting it.

Also templates are very limited if you want to do extra stuff. Like changing the layout of the table you just gave dynamically.

Is it possible to color each row an alternate color for instance? Probably it is but either way you end up adding more complexity to deal with what problem? Your designer unable to deal with your coding language? Get a better designer. Coders don't just delete html do they?

Re:I never like this method

[MaoTse]

The point is: PHP does not support content/logic separation ;-)

Your designer wanted to delete the code because it was breaking his design tool. Fuck ...

Zope Page Templates do not have this problem.

Agree with all the "depends" comments

[soliptic]

One thing I've noticed is that whenever web programming comes up on slashdot, a ton of people rush in to boast about how they only ever use full-blown MVC, presumably in an effort to look uber-professional and dissociate themselves from this 'dirty php hacker' stereotype.

The thing is, sometimes dirty php hacks are fine.

What are you coding? If I went to ebay, or amazon, or something like that, and they didn't have a serious n-tier architecture, and all their logic code was scattered randomly throughout their html source, that would be a proper WTF.

On the other hand, when I knock up some sort of ultra-basic blog for myself, or a cheesy feedback form for my band's website, or something like that, then using full-on OOP and MVC is an equally big WTF. In that situation, please stop about impressing other people on slashdot with your architecture model professionalism, and write something shamelessly quick and easy. You're going to be the only person updating it, so who cares?

One further point on that subject... everyone praises a clean separation / MVC approach for being essential when you have multiple developers updating code. Well... true in a way... but there are qualifications to that. I remember doing some hacking on php blogging software Plog for a customer last year. That's completely OOP and MVC, using Smarty for templating, and the intellectual side of my brain was impressed with the cleanliness of the design patterns, but the practical side of my brain found it a pain in the arse. The client would say "you see this output of such-and-such a word on such-and-such a page, can we change it?" If it had been I'd go into the source for that page and it would be pretty much a single line of code...

model._request->("by_categories").view

or something ludricously cryptic like that. So I'd have to trying and "trace" things from the by_categories.php through the templates into all the object classes... of course the OOP was so fully-blown that you'd reach some initial completely generic class whcih told you nothing, you needed something which inherited off something which inherited off something.... etc, etc. It was an absolute nightmare, for the simple reason that the documentation, like so many OSS projects, was extremely lacking, verging on non-existent. I went to their wiki and found a page with the perfect title, something like "which functions are handled in which classes", but it just said "coming soon".

To their credit, when I asked on their forums I got a quick and friendly reply, but still, I think it illustrates my point. If you're going to put things into an elaborate architecture so that what-you-see-in-the-final-html-pages bears almost no direct relationship to organisation of the 'business logic' source files, then documentation is essential otherwise it's actually harder for multiple developers to hack than if you just stuff your html full of inline php.