Paul M Foster wrote:
On Mon, May 10, 2010 at 06:09:00PM -0400, David McGlone wrote:
On Monday 10 May 2010 13:04:36 richard gray wrote:
On 10/05/2010 18:17, Ashley Sheridan wrote:
It makes sense sometimes to have different files for different sections
of a website. For example, blog.php, gallery.php, cart.php could deal
with the blog, gallery and shopping cart sections for an artists
website. Yes, it could all be achieved with one script handling
everything, but sometimes when the areas of the site differ greatly, it
results in a lot of extra code to deal with pulling in the right
template and content parts. I've always favoured only including the code
a page needs rather than a huge amount of stuff that it doesn't.
this isn't necessarily true - the architecture I've developed uses a
single dispatch script (works fine with the mod rewrite option 2
scenario as well) - this script does general checks/security/filters etc
then simply determines what page/function the user wants from the
request ($_GET/$_POST parameter) and passes control to the specific
handler via including the relevant controller module. The controller
module is responsible for which template is required and loads up
specific classes needed to process the request etc so each module just
loads its own stuff and nothing else so there's no overhead.
This method also has a small extra benefit that the web server document
root just has a very simple 2 liner script instead a myriad of php
scripts... if the webserver is misconfigured then someone who sees the
source code doesn't get to see much..
This thread makes me wonder if using Smarty is smart. Does anyone here use a
templeting system such as smarty or am I the only one?
Lots of people use templating systems and particularly Smarty. Here's
the difference between a templating system and just hand-coding:
Hand coding--
<input type="text" name="flavor" size="20" value="<?php echo $flavor;
?>"/>
Templating system:
<input type="text" name="flavor" size="20" value={flavor}/>
(Okay, I'm not familiar with Smarty syntax, but in essence template
systems allow you to type less when you want PHP values to show up on
the page.)
Advantage: It *may* be easier for non-programmers to "read" the page
with templating systems. I'm not sure this is really true. They're still
liable to say, "What the heck is {flavor}?" Besides, my inclination is
to tell designers to make everything look pretty, turn the resulting
HTML over the the coders, who will then mark it up for PHP. After that,
the designers can stay away from it.
Disadvantage: You're adding another layer (and a LOT of code) just to
save yourself some typing. With straight PHP, the server reads the code,
interprets the PHP, substitutes values and shoves the page down to the
browser. With a templating system, the system must load and call the
templating engine, which must then substitute the proper values, and
then output the built page to the browser.
Your choice.
I get tired of correcting this incorrect assertion. Some templates
engines do what you describe. Not all. Some directly generate PHP source
code which is then either directly accessed via the web server or
directly included by another page. Generating PHP code from a template
engine can provide superior benefits over pure PHP since the distilling
of simple XML (or otherwise) tags can be rendered once via simple or
complex PHP processing during template compilation versus the same
processing being done on every page request. In fact some will produce
plain HTML that doesn't even require the PHP interpreter.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
