Preferred method for using/writing template with PHP and HTML [closed] - php

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
In creating my own template, there seems to be two ways of displaying my body content using PHP and HTML. Which method tends to be the preferred, or most correct, method?
Is there an industry standard? For example - if I showed my code to Facebook, is there a certain method that the person hiring me would be looking for?
Both of them are clumsy at first to write.
Method #1
<?php
//Begins with <body>
templateGetAboveContent();
//Begin unique content
?>
<h1>Example Header</h1>
<div id="article_container">
<?php
if ($row = mysql_fetch_assoc(mysql_query($get_article_sql))
{
?>
<div id="article"><?php echo $row['article_content'];?></div>
<?php
}
templateGetBelowContent();
?>
Method #2
<?php
$body = "";
$body .= "<h1>Example Header</h1>";
$body .= "<div id=\"article_container\">";
if ($row = mysql_fetch_assoc(mysql_query($get_article_sql))
{
$body .= "<div id=\"article\">" . $row['article_content'] . "</div>";
}
templateGetDisplayContent($body);
?>
In Method #2, templateGetDisplayContent() would simply echo $body; where it should be, between the displayAbove and displayBelow code.

Both methods apparently has nothing to do with templates at all.
First one is closer but seeing a word "mysql" in the template one can say that is failed attempt for sure.
You have to make a strict separation between data processing part and data displaying part.
There should be not a single symbol sent to the browser until all data got ready.
So, make your site consists of pages, page templates and main template.
Once your script called, it have to process data, and then load site template, which, in turn, will load page template.
An example layout is going to be like this:
a page:
<?
//include our settings, connect to database etc.
include dirname($_SERVER['DOCUMENT_ROOT']).'/cfg/settings.php';
//getting required data
$DATA=dbgetarr("SELECT * FROM links");
$pagetitle = "Links to friend sites";
//etc
//and then call a template:
$tpl = "links.tpl.php";
include "template.php";
?>
it outputs nothing but only gather required data and calls a template:
template.php which is your main site template,
consists of your err.. templateGetAboveContent() and templateGetBelowContent():
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>My site. <?=$pagetitle?></title>
</head>
<body>
<div id="page">
<? include $tpl ?>
</div>
</body>
</html>
and calls the actual page template:
<h2><?=$pagetitle?></h2>
<ul>
<? foreach($DATA as $row): ?>
<li><?=$row['name']?></li>
<? endforeach ?>
<ul>
This would be a REAL use of templates.
Note that the main site template is able to display variable texts depends on the current page contents.
Is there an industry standard?
No. There are several standards.
Escaping from HTML is closer to one of them, but still you are using it wrong way.

Any programming language is built to give flexibility to the developer. They're just "toolkits" provided to programmers and it's up to the programmers to implement stuff (and invent stuff) they want done. As far as i know, there are a lot of templating engines (both built in to frameworks and standalones) out there that simplify rendering of pages but sacrifice that flexibility for the ease of use.
You mention Facebook (and surely figured out they use PHP). However, what you don't know is that they have developers that build their own API which may include templating for their pages - in other words, their own implementation.
All in all, it depends on what you are going to do and what tools you use at the moment. You should try exploring using frameworks and other tools. You will learn a lot on how each of them implement their templating methods (sooner or later you will lean to one or two of these methods).
personal suggestion: try mustache

There isn't a 100% correct answer to this, as both will ultimately get you the goal you need.
Using Method 1 though will likely allow you to better interact with the templates in the event they need to be updated.
Especially if another party like a designer is involved, who is providing static HTML.
You could easily go into that and just add the PHP tags/code where need be.

Personally, I think the first example is simple and straight to the point. And I think someone who would be hiring you would think the same. Plus, keeping all the body content in a variable would be a hassle to use across a whole site.

Related

is this a good practice to output html using php? [duplicate]

I have been designing websites for a while now, but there is one thing that I have never been quite sure of when using PHP and HTML. Is it better to have the whole document in PHP and echo HTML like so:
<?php
doSomething();
echo "<div id=\"some_div\">Content</div>";
?>
Or have a HTML file like so and just add in the PHP:
<html>
<body>
<?php doSomething(); ?>
<div id="some_div">Content</div>
</body>
</html>
It seems tidier to echo HTML, especially if lots of PHP gets used throughout the page, but doing so loses all formatting of the HTML i.e. colors in the IDE etc.
There are varying opinions on this. I think there are two good ways:
Use a templating engine like Smarty that completely separates code and presentation.
Use your second example, but when mixing PHP into HTML, only output variables. Do all the code logic in one block before outputting anything, or a separate file. Like so:
<?php $content = doSomething();
// complex calculations
?>
<html>
<body>
<?php echo $content; ?>
<div id="some_div">Content</div>
</body>
</html>
Most full-fledged application frameworks bring their own styles of doing this; in that case, it's usually best to follow the style provided.
I think this would depend on your group's or your own decided convention. And it can and should vary depending on what type of file you're working in. If you follow the MVC pattern then your views should be the latter. If you're writing a class or some non-output script/code then you should use the former.
Try to keep a separation of display or formatting of output and the logic that provides the data. For instance let's say you need to make a quick page that runs a simple query and outputs some data. In this case (where there is no other existing infrastructure or framework) you could place the logic in an include or in the top or the bottom of the file. Example:
<?php
# define some functions here that provide data in a raw format
?>
<html>
<body>
<?php foreach($foo = data_function($some_parameter) as $key => $value): ?>
<p>
<?=$value;?>
</p>
<?php endforeach; ?>
</body>
</html>
Or you could place the logic and function definitions in an include file or at the bottom of the file.
Now if you're producing some sort of class that has output (it really shouldn't) then you would echo the HTML or return it from the method being called. Preferably return it so that it can be output whenever and however the implementer would like.
The syntax highlighting is an important benefit of the second method, as you said. But also, if you're following good practices where logic and presentation are separated, you will naturally find that your files that contain HTML are almost entirely HTML, which then, naturally, leads to your second method again. This is the standard for MVC frameworks and the like. You'll have a bunch of files that are all PHP, doing logic, and then when that's done they'll include a presentation file which is mostly HTML with a sprinkling of PHP.
Simple:
More PHP - close HTML in PHP. When you generate HTML code in PHP, when you are doing something like a class, so it is better to make it in echo.
Less PHP - close PHP in HTML. This is stuff like just putting vars into fields of HTML stuff, like forms... And such.
The best approach is to separate the HTML from the PHP using template system or at least some kind of HTML skeleton like:
<main>
<header/>
<top-nav/>
<left-col>
<body />
</left-col>
<right-col />
<footer/>
</main>
Each node represents a template file e.g. main.php, hrader.php and so on. Than you have to separate the PHP code from the templates as something like functions.php and fineally use your second approach for template files and keeping functions clean of "echos" and HTML.
If you can, use a template engine instead.
Although it is slightly easier at first to mix your HTML and PHP, separating them makes things much easier to maintain later on.
I would recommend checking out TemplateLite which is based on Smarty but is a little more light weight.
I've reached a conclusion that using views in MVC framework e.g. Laravel, Yii, CodeIgniter is the best approach even if you are not displaying the html straight away.
Inside the view do all the echoing and looping of prepared variables, don't create or call functions there, unless formatting existing data e.g. date to specific format date('Y-m-d', strtodate(123456789)). It should be used only for creating HTML, not processing it. That's what frameworks have controllers for.
If using plain PHP, create you own view function to pass 3 variables to - html file, array of variables, and if you want to get output as string or print it straight away for the browser. I don't find a need for it as using frameworks is pretty much a standard. (I might improve the answer in the future by creating the function to get view generated HTML) Please see added edit below as a sample.
Frameworks allow you to get the HTML of the view instead of displaying it. So if you need to generate separate tables or other elements, pass the variables to a view, and return HTML.
Different fremeworks may use various type of templating languages e.g. blade. They help formatting the data, and essentially make templates easier to work with. It's also not necessary to use them for displaying data, or if forced to use it by the framework, just do required processing before posting the variables, and just "print" it using something like {{ yourVariable }} or {{ yourVariable.someProperty }}
Edit: here's a plain PHP (not framework PHP) - simple-php-view repository as a sample view library that allows to generate HTML using variables. Could be suitable for school/university projects or such where frameworks may not be allowed.
The repository allows to generate HTML at any time by calling a function and passing required variables to it, similar to frameworks. Separately generated HTML can then be combined by another view.
It depends on the context. If you are outputting a lot of HTML with attributes, you're going to get sick of escaping the quotation marks in PHP strings. However, there is no need to use ?><p><? instead of echo "<p>"; either. It's really just a matter of personal taste.
The second method is what I usually use. And it was the default method for me too. It is just to handy to get php to work inside html rather than echo out the html code. But I had to modify the httpd.conf file as my server just commented out the php code.

How much code should be in a CodeIgniter view?

First steps are done, some pages are coded. And after looking to the result I've got the question... how much code is there should be in templates (View)?
For example, here is a template file:
<?php $this->load->view('header'); ?>
<?php $this->load->view('banner'); ?>
<div id="items">
<?php
for($i=0; $i<count($main); $i++) {
echo '<div class="item">
<div class="name">'.$main[$i]['name'].'</div>';
if($main[$i]['icq']=='') { }
else { echo '<div class="phone">'.$main[$i]['phone'].'</div>'; }
echo '</div>';
}
?>
</div>
<?php $this->load->view('footer'); ?>
Do you think there is too much code in this template or it is normal?
The first answer was actually spot on, but the user deleted it (probably due to peer pressure). Basically, you do not want any logic in your template. In an ideal world, you had a tag for all the model data, but since we are in an HTML world, there isn't, so you either have to use XSLT or use ViewHelpers.
Let's focus on the ViewHelper approach.
This is hard to maintain:
<div id="items">
<?php
for($i=0; $i<count($main); $i++) {
echo '<div class="item">
<div class="name">'.$main[$i]['name'].'</div>';
if($main[$i]['icq']=='') { }
else { echo '<div class="phone">'.$main[$i]['phone'].'</div>'; }
echo '</div>';
}
?>
</div>
And it won't get any better if you replace the PHP with Smarty. This is easy to maintain:
<div id="items">
<?php echo itemlist($items, 'template.htm') ?>;
</div>
Below the now deleted question, there was a commentor objecting this "code isn't easy to maintain for non-coders because now they don't know where itemlist is defined and what it does." but that's complete gibberish. Think about it for a second.
On the one hand, they claim non-coders will have issues with a simple function call but on the other hand they expect them to understand the mishmash of PHP code mixed with HTML. A designer does not care about the presentation logic, but just the actual presentation. The output.
A single function call clearly says: "here be an item list", which is much easier to grasp than "here is a for that echoes a div and maybe something else if icq is given". A function call is as good as a tag. It has clearly defined input and output. How it achieves that output is irrelevant to anyone but the developer.
Your ViewHelper encapsulates the presentation logic. It's a snippet you can reuse across all of your Views. That is much more maintainable than copy and pasting all that logic over and over again when needed. In the example above, there is two arguments to the helper:
$items is an array or other traversable type holding your actual item data
'template.htm' is the filename of the template used to render the data
I'll make the second one optional, because I'd assume it's always the same template anyway. But since the commentor complained the non-coder wouldn't know where to look, I felt it necessary to show how easy it is to tell the non-coder where to look.
function itemlist($items, $template = './templates/itemlist.htm') {
ob_start();
foreach($items as $item) {
include $template;
}
return ob_get_flush();
}
There might be more efficient approaches to solve the inclusion of the template. The main idea should be clear though. Hide the presentation logic from the actual template. Your "template.htm" would then look like this:
<div class="item">
<div class="name"><?php echo $item['name'] ?></div>
<?php echo contact($item, 'icq' 'phone'); ?>
</div>
No if and elses. No string concatenations or curly braces. The logic to decide how to the user can be contacted is hidden in a ViewHelper as well. All the non-coder has to know now is the arguments to the ViewHelpers and that's as easy as knowing which attribute to write to a tag. Give them a cheat sheet if necessary.
Related information:
http://martinfowler.com/eaaCatalog/templateView.html
EDIT
Due to the two comments below I decided to expand on this answer. The above is not abstraction for abstraction's sake. It is for reusability and maintainability. I've already pointed that out above but let me explain that here again.
Actually, I find it odd to object to using ViewHelpers because you'll have "have presentation in two places" but not complain about separating header, banner and footer. It's the same thing. You isolate parts that are reusable and put them into their own templates. Separating the logic from the template in that step is just the natural next step to achive even more maintainability.
A view template that contains logic is effectively a script and not a template. Any view template that contains the logic to assemble itself is doomed to repeat itself. This might not be an issue with small sites but if you are working on a site with a couple dozen or even hundreds of view and widgets, not abstracting these parts will lead to code duplication. Put all the logic into the template and it will quickly become a tangled mess of c&p'ed markup mixed with conditionals. For any duplication, you'll double the time it takes to change it. Add inline styles and obtrusive Javascript and you are in maintenance hell.¹
If you use OOP for the other parts of your application, then why would you go procedural in your view? If you understood that you should separate Javascript and CSS from your HTML, why would you mix PHP into your template? It doesn't make sense. The OP's code snippet is a script and not a template. As such, it is the domain of the developer. And because of that you apply all the good practise you apply to other parts of your application as well. And that includes isolating logic into functions and/or classes.
Granted, a designer looking into a script might not immediately know what's going on. But then again, she might not know that either once you start to add in native PHP functions. What's mb_strimwidth doing? And substr? What's that ?: construct? The more actual PHP you add, the harder it will be to read for non-developers.
If you want to have designers work on templates, don't give them scripts. Give them templates. And if you do, isolate the logic from it and replace it with easy to grasp function calls. Use function names that clearly communicate what the function does. So the designer only needs to know if "I use this with that input, I will always get that output. I don't care how that output comes to be. I'll leave that to the developer".
Isolating the logic into functions (or classes) also gives you the immediate advantage of being able to test the logic used to render specific parts on that page in isolation. You don't have to setup the entire environment required to create a page, but just pass in the required input and assert it's output (that's why the function buffers the string instead of outputting it btw).
¹For those of you who think this is not an issue, I strongly suggest to find yourself a legacy application that truly keeps all the logic in the view template. Try to change a few things. Once you have had the pleasure of eating through 2500 lines of spaghetti code with at least 500 chars each and containing a mix of repeated PHP, HTML, CSS and JavaScript you'll know what I am talking about.
I don't think what you're trying to achieve in the view is too much logic, but I think it should be cleaned up somewhat.
Something like:
<?php foreach($main as $item): ?>
<div class="item">
<div class="name"><?php echo $item['name']; ?></div>
<?php if($item['icq']): ?>
<div class="phone"><?php echo $item['phone']; ?></div>
<?php endif; ?>
</div>
<?php endforeach; ?>
I find that a lot easier to read, and it does the same job. I also don't think it would be hard for a non-coder to modify, which is ultimately the goal of a view.
When the templates need a lot of logic is could be useful to introduce the ViewModel pattern
The logic that determines when a certain block is shown is placed in the view model.
Example
A template snippet:
<?php if($item['show_phone_number']): ?>
<div class="phone"><?php echo $item['phone_number']; ?></div>
<?php endif; ?>
A view model snippet:
$item['show_phone_number'] = $item["icq"] == '';
short answer:
As little as is viably possible.
View is no a template.
Or at least - it should not be a template. Views are generally instance of classes, which are responsible for dealing with presentational logic. They juggle multiple templates and decide which one to use and what data pass into them.
But CI has none of this. You are basically stuck with a template, which pretends to be "View" , and and instances of ActiveRecord, which they tell you are "Models". Hell .. in proper MVC the Model isn't even a specific class but an application layer.
In long term, this situation will force both presentation logic and business logic into the controller, while at the same time, producing hard-to-maintain templates and activerecord classes.
I think as James, too much code, but you can add an array variable to the get_items() function, to control the prefix and suffix of each item, something like:
$options = Array('item_prefix' => '<div class="item">', 'item_suffix' => '</div>'...)
echo get_items();
Your views should definitely contain most of the html tags, so I do not think that a function get_items should be placed somewhere else. Just clean up your templates a little bit and work with the alternative loop syntax as suggested by Karpie. You could also think about using some existing templating engine like Twig but with that the views have to contain some references to your data as well...
What you want to achieve is that non-coders can edit your html files without having to understand too much scripting logic.

What is the best practice to use when using PHP and HTML?

I have been designing websites for a while now, but there is one thing that I have never been quite sure of when using PHP and HTML. Is it better to have the whole document in PHP and echo HTML like so:
<?php
doSomething();
echo "<div id=\"some_div\">Content</div>";
?>
Or have a HTML file like so and just add in the PHP:
<html>
<body>
<?php doSomething(); ?>
<div id="some_div">Content</div>
</body>
</html>
It seems tidier to echo HTML, especially if lots of PHP gets used throughout the page, but doing so loses all formatting of the HTML i.e. colors in the IDE etc.
There are varying opinions on this. I think there are two good ways:
Use a templating engine like Smarty that completely separates code and presentation.
Use your second example, but when mixing PHP into HTML, only output variables. Do all the code logic in one block before outputting anything, or a separate file. Like so:
<?php $content = doSomething();
// complex calculations
?>
<html>
<body>
<?php echo $content; ?>
<div id="some_div">Content</div>
</body>
</html>
Most full-fledged application frameworks bring their own styles of doing this; in that case, it's usually best to follow the style provided.
I think this would depend on your group's or your own decided convention. And it can and should vary depending on what type of file you're working in. If you follow the MVC pattern then your views should be the latter. If you're writing a class or some non-output script/code then you should use the former.
Try to keep a separation of display or formatting of output and the logic that provides the data. For instance let's say you need to make a quick page that runs a simple query and outputs some data. In this case (where there is no other existing infrastructure or framework) you could place the logic in an include or in the top or the bottom of the file. Example:
<?php
# define some functions here that provide data in a raw format
?>
<html>
<body>
<?php foreach($foo = data_function($some_parameter) as $key => $value): ?>
<p>
<?=$value;?>
</p>
<?php endforeach; ?>
</body>
</html>
Or you could place the logic and function definitions in an include file or at the bottom of the file.
Now if you're producing some sort of class that has output (it really shouldn't) then you would echo the HTML or return it from the method being called. Preferably return it so that it can be output whenever and however the implementer would like.
The syntax highlighting is an important benefit of the second method, as you said. But also, if you're following good practices where logic and presentation are separated, you will naturally find that your files that contain HTML are almost entirely HTML, which then, naturally, leads to your second method again. This is the standard for MVC frameworks and the like. You'll have a bunch of files that are all PHP, doing logic, and then when that's done they'll include a presentation file which is mostly HTML with a sprinkling of PHP.
Simple:
More PHP - close HTML in PHP. When you generate HTML code in PHP, when you are doing something like a class, so it is better to make it in echo.
Less PHP - close PHP in HTML. This is stuff like just putting vars into fields of HTML stuff, like forms... And such.
The best approach is to separate the HTML from the PHP using template system or at least some kind of HTML skeleton like:
<main>
<header/>
<top-nav/>
<left-col>
<body />
</left-col>
<right-col />
<footer/>
</main>
Each node represents a template file e.g. main.php, hrader.php and so on. Than you have to separate the PHP code from the templates as something like functions.php and fineally use your second approach for template files and keeping functions clean of "echos" and HTML.
If you can, use a template engine instead.
Although it is slightly easier at first to mix your HTML and PHP, separating them makes things much easier to maintain later on.
I would recommend checking out TemplateLite which is based on Smarty but is a little more light weight.
I've reached a conclusion that using views in MVC framework e.g. Laravel, Yii, CodeIgniter is the best approach even if you are not displaying the html straight away.
Inside the view do all the echoing and looping of prepared variables, don't create or call functions there, unless formatting existing data e.g. date to specific format date('Y-m-d', strtodate(123456789)). It should be used only for creating HTML, not processing it. That's what frameworks have controllers for.
If using plain PHP, create you own view function to pass 3 variables to - html file, array of variables, and if you want to get output as string or print it straight away for the browser. I don't find a need for it as using frameworks is pretty much a standard. (I might improve the answer in the future by creating the function to get view generated HTML) Please see added edit below as a sample.
Frameworks allow you to get the HTML of the view instead of displaying it. So if you need to generate separate tables or other elements, pass the variables to a view, and return HTML.
Different fremeworks may use various type of templating languages e.g. blade. They help formatting the data, and essentially make templates easier to work with. It's also not necessary to use them for displaying data, or if forced to use it by the framework, just do required processing before posting the variables, and just "print" it using something like {{ yourVariable }} or {{ yourVariable.someProperty }}
Edit: here's a plain PHP (not framework PHP) - simple-php-view repository as a sample view library that allows to generate HTML using variables. Could be suitable for school/university projects or such where frameworks may not be allowed.
The repository allows to generate HTML at any time by calling a function and passing required variables to it, similar to frameworks. Separately generated HTML can then be combined by another view.
It depends on the context. If you are outputting a lot of HTML with attributes, you're going to get sick of escaping the quotation marks in PHP strings. However, there is no need to use ?><p><? instead of echo "<p>"; either. It's really just a matter of personal taste.
The second method is what I usually use. And it was the default method for me too. It is just to handy to get php to work inside html rather than echo out the html code. But I had to modify the httpd.conf file as my server just commented out the php code.

How is duplicate HTML represented in your codebase, in a non-duplicate way?

Most HTML in a large website is duplicated across pages (the header, footer, navigation menus, etc.). How do you design your code so that all this duplicate HTML is not actually duplicated in your code? For example, if I want to change my navigation links from a <ul> to a <ol>, I'd like to make that change in just one file.
Here's how I've seen one particular codebase handle this problem. The code for every page looks like this:
print_top_html();
/* all the code/HTML for this particular page */
print_bottom_html();
But I feel uncomfortable with this approach (partially because opening tags aren't in the same file as their closing tags).
Is there a better way?
I mostly work with PHP sites, but I'd be interested in hearing solutions for other languages (I'm not sure if this question is language-agnostic).
I'm not a php programmer, but I know we can use a templating system called Smarty that it works with templates(views), something like asp.net mvc does with Razor.
look here http://www.smarty.net/
One solution at least in the case of PHP (and other programming languages) is templates. Instead of having two functions like you have above it would instead be a mix of HTML and PHP like this.
<html>
<head>
<title><?php print $page_title ?></title>
<?php print $styles ?>
<?php print $scripts ?>
</head>
<body>
<div id="nav">
<?php print $nav ?>
</div>
<div id="content">
<?php print $content ?>
</div>
</body>
</html>
Each variable within this template would contain HTML that was produced by another template, HTML produced by a function, or also content from a database. There are a number of PHP template engines which operate in more or less this manner.
You create a template for HTML that you would generally use over and over again. Then to use it would be something like this.
<?php
$vars['nav'] = _generate_nav();
$vars['content'] = "This is the page content."
extract($vars); // Extracts variables from an array, see php.net docs
include 'page_template.php'; // Or whatever you want to name your template
It's a pretty flexible way of doing things and one which a lot of frameworks and content management systems use.
Here's a really, really simplified version of a common method.
layout.php
<html>
<body>
<?php echo $content; ?>
</body>
</html>
Then
whatever_page.php
<?php
$content = "Hello World";
include( 'layout.php' );
Sounds like you need to use include() or require()
<?php
include("header.inc.php");
output html code for page
include("footer.inc.php");
?>
The header and footer files can hold all the common HTML for the site.
You asked for how other languages handle this, and I didn't see anything other than PHP, so I encourage you to check out Rails. Rails convention is elegant, and reflects #codeincarnate 's version in PHP.
In the MVC framework, the current view is rendered inside of a controller-specific layout file that encapsulates the current method's corresponding view. It uses a "yield" method to identify a section where view content should be inserted. A common layout file looks like this:
<html>
<head>
<% #stylesheet and js includes %>
<body>
<div id="header">Header content, menus, etc…</div>
<%= yield %>
<div id="footer">Footer content</div>
</body>
</html>
This enables the application to have a different look and feel or different navigation based on the controller. In practice, I haven't used different layout files for each controller, but instead rely on the default layout, which is named "application".
However, let's say you had a company website, with separate controllers for "information", "blog", and "admin". You could then change the navigation for each in a clean and unobtrusive manner by handling the different layout views in their respective layout files that correspond to their controllers.
You can always set a custom layout in the controller method by stating:
render :layout => 'custom_layout'
There are also great helper methods built into Rails so you don't have to rely on $global variables in PHP to ensure your CSS and Javascript paths are correct depending on your development environment (dev, staging, prod…). The most common are:
#looks in public/stylesheets and assumes it's a css file
stylesheet_link_tag "filename_without_extension"
#looks in public/javascripts and assumes it's a js file
javascript_include_tag "jquery"
Of course, each of these sections could be expounded upon in much greater detail and this is just brushing the surface. Check out the following for more detail:
http://guides.rubyonrails.org/layouts_and_rendering.html
What you suggested works OK. As long as print_top_html and print_bottom_html stay in sync (and you can use automated tests to check this), then you never need to worry about them again, leaving you to focus on the real content of the site -- the stuff in the middle.
Alternatively, you can combine print_top_html and print_bottom_html into a single call, and send it HTML code (or a callback) to place in the middle.
I use the partials system of Zend_View (very similar to Rails). A partial is essentially a small HTML template that has its own variable scope. It can be called from inside views like:
<?php echo $this->partial('my_partial.phtml', array( 'var1' => $myvar ));
The variables that get passed into the construct get bound to local variables inside the partial itself. Very handy for re-use.
You can also render a partial from inside normal code, if you're writing a helper object where you have more complex logic than you'd normally feel comfortable putting in a view.
public function helperFunction()
{
// complex logic here
$html = $this->getView()->partial('my_partial.phtml', array('var1' => $myvar ));
return $html;
}
Then in your view
<?php echo $this->myHelper()->helperFunction(); ?>

Lightweight, PHP based, layout framework...know of any? [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I'm looking for a lightweight, PHP based, layout framework. Like how the Zend Framework, uses layouts, I would like to create a layout template and include only the content for the necessary pages.
<html>
<head>
<title><?= $pageTitle ?></title>
</head>
<body>
<?= $content ?>
</body>
</html>
Anyone know of anything that does this? I would use the Zend Framework, but it's just too much for what I want to achieve.
I vote for PHP. (PHP is a templating engine.)
function template($file, $vars) {
ob_start();
if(count($vars) > 0) { extract($vars); }
include 'views/'.strtolower($file).'.php';
return ob_get_clean();
}
Which, incidentally, lets you do the following.
echo template('layout', array( 'content' => template('page', $myData) ));
Should you even bother using another templating/layout engine at all, when PHP itself can suffice in a mere 6 lines?
Edit:
Perhaps I wasn't clear with how this works.
template() is called with the name of the template (subdirectories for organization work too) with an array object as the second parameter. If the variables given aren't blank, like template('index',null) is, then the array is treated as an associative array: and every key becomes a variable containing the value.
So the logic becomes:
template('my_template', array(
'oranges' => 'apples'
));
And "views/my_template.php" is:
<html>
<head>
<title>Are apples == <?= $oranges ?>?</title>
</head>
<body>
<p style="color: <?= $oranges == 'oranges' ? 'orange" : 'darkgreen' ?>">
Are apples == oranges?
</p>
</body>
</head>
So, every time the variable $oranges is used PHP gets the data that was exported from the array, $vars['oranges'].
So all the output is then taken by ob_get_clean() and returned as a string. To output this string just echo or print, or assign it to an array to be passed as content to the layout. If you understand this, then it is very easy to take what I've written and make a layout out of it, or pages with logic that output JSON even.
I would advise you to experiment with this answer before discarding it. It has a tendency to grow on you.
Edit 2:
As requested I'll show the directory layout that my project would use. Do note that other MVC frameworks use a different structure. But, I like the simplicity of mine.
index.php
application/
framework.php
controllers/
welcome.php
views/
template.php
index.php
For security purposes, I have an .htaccess file that routes every request, except those to js/ or css/, to the index.php script, effectively making my directories hidden. You could even make the CSS via a template if you wished, which I've done, for the use of variables, etc.
So, any call made to template('template', array()) will load the file ./views/template.php automatically. If I included a slash in the name, it becomes part of the path, like so: ./views/posts/view.php.
Edit 3:
thanks for your update. So you must have some code in your index.php file that routes the requested url to the appropriate controller, correct? Could you show some of this? Also, it doesn't look like your views mirror your controller directory. Can you explain a little more how urls map to controllers and/or views? What do you have in framework.php? What does it do? Thanks!
The code I've shown is a tiny excerpt of my private framework for web development. I've talked already about potentially releasing it with a dual-license, or as donation-ware for commercial use, but it's nothing that can't be written by anyone else in a short (15-21 days) time. If you want you can read my source code on GitHub... but just remember that it's still alpha material.
The license is Creative Commons SA.
If you want super-lightweight, you could use an auto-prepend file, mixed with some output buffering to build what you want. For starters, you need to set up your prepend and append files - put the following lines in your .htaccess file (you'll probably want to make the prepend and append files unreadable to visitors, too):
php_value auto_prepend_file prepend.php
php_value auto_append_file append.php
Then in your prepend.php file, you'll want to turn on output buffering:
<?php
ob_start();
In append.php, you'll want to grab the contents of the output buffer, clear the buffer and do any other processing of the content you want (in this example, I set a default page title).
<?php
if (!isset($page_title)) {
$page_title = 'Default Page Title';
}
$content = ob_get_contents();
ob_end_clean();
?>
<html>
<head>
<title><?php echo $page_title; ?></title>
</head>
<body>
<?php echo $content ?>
</body>
</html>
After this, you can write each page normally. Here's an example index.php
<?php
$page_title = "Index Page!";
?>
<h1>This is the <?php echo __FILE__; ?> page</h1>
...and an example other.php that does something halfway interesting:
<?php
$page_title = "Secondary Page!";
?>
<h1>This is the <?php echo __FILE__; ?> page</h1>
<p>enjoy some PHP...</p>
<ol>
<?php for ($i = 1; $i <= 10; $i++) : ?>
<li><?php echo "$i $i $i"; ?></li>
<?php endfor ?>
</ol>
And you're done. You can grow on this a bit, such as initializing DB connection in the prepend, but at some point, you'll probably want to move to a more abstract system that breaks out of a fixed mapping of URLs to paths and files.
I'm actually about to release one at europaphp.org along with examples and a full documentation. It's very similar to the Zend Framework in conventions and coding standards. I'll post something when it is done; probably within the next week.
You can get the code at: [http://code.google.com/p/europa/source/browse/#svn/trunk/Sandbox - Default][1].
That link will bring up the latest svn for the Sandbox which you can just download and start using without any configuration.
Currently, it's faster than most any other PHP framework out there.
[1]: http://code.google.com/p/europa/source/browse/#svn/trunk/Sandbox - Default
BareBones: a one-file, no-configuration, MVC framework for PHP5
FryPHP is about as lightweight as it gets.
Limonade might also be useful... not strictly layout.
I've been using Smarty for ages.
It's mature, actively maintained, and widely supported.
Anyway, you'll find a whole range of template engines here:
http://en.wikipedia.org/wiki/Template_engine_(web)
If you click the languages column, you'll easily see what's available for PHP, and how the engines compare.
Just to throw in another framework: CodeIgniter is IMHO very nice, uses an MVC approach, so you'd output your files as views and says to have a small footprint. It also has a template parser on board.
Cheers,

Categories