Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Templating best practise

1 view
Skip to first unread message

UKuser

unread,
Jul 17, 2008, 7:19:32 AM7/17/08
to
http://allyourtech.com/content/articles/29_06_2005_templating_with_php.php
Using method 2 - it mentions

"You may be wondering, "Where will we be pulling this content from?"
There is no single way to do this; content could be pulled from
something as simple as a single text file or from something as complex
as a MySQL database. To keep things simple for this example, we'll
assume that page content is stored in individual files as variables."

What I'm asking - is there a best practise to this concept? I see the
3 possible options as :
1) An array array(title=>title,body=>include/body)
2) Separate files
3) Database for each page

Thanks

A

NC

unread,
Jul 18, 2008, 9:40:25 PM7/18/08
to
On Jul 17, 4:19 am, UKuser <spiderc...@yahoo.co.uk> wrote:
>
> What I'm asking - is there a best practise to this concept?

Not really... When you say "best practice", there's always a
question, "best for what?" And that "what" in turn can be either a
feature of system environment or a design objective...

For example, storing content in a database is good enough for most
occasions, except when you are told not to expect database
connectivity in the target system environment. :)

As to design objectives, you may be told to develop for performance,
maintainability, or time to market. Let's pretend you are told to
store both textual content and executable code. Storing the content
in the database is clearly the preferred solution, but what of the
code? You can:

1. Store it in a database and use eval() to run it, which will
be fine and dandy in terms of time to market and
maintainability, but will have its share of performance
issues, which, however, will only show at high loads, or
2. Store it in files and execute it with include(), which will
have the best performance, but will create problems with
both maintainability (because backing up the database is no
longer enough; the file system must also be backed up) and
time to market (because you now need two separate storage
routines, one for content, another for code), or
3. Figure out a hybrid solution: store code in a database, but
also save each snippet into a file when the relevant DB
record is updated and/or when the code is about to be used
for the first time and then include() the resulting file;
this approach would create a minor performance drawback
(there will be the overhead of generating code files and
checking for their existence), get rid of all maintainability
issues (the database is, once again, the only source of data
the application needs to operate), and push back your time to
market (since you need to write the code to manage the stored
code).

In case some of the above sounds familiar, #1 (with a ton security
precautions surrounding it) is implemented in Drupal under the moniker
"PHP filter" and #2 is used in WordPress' plugin and theming systems
(although you can't create a new plugin or theme file from within
WordPress, you definitely can edit those files with WordPress). I am
not aware of anyone using #3 as described, but I sincerely doubt I am
the first person to have thought of it... :)

Cheers,
NC

0 new messages