tags:

views:

89

answers:

3

As an exercise in web design and development, I am building my website from the ground up, using PHP, MySQL, JavaScript and no frameworks. So far, I've been following a model-view-controller design. However, there is one hurdle that I am quickly approaching that I'm not sure how I'm going to solve, but I'm sure it's been addressed before with varying degrees of success.

On my website, I'm going to have a resume and an "about me" bio section. These probably won't be changing very often.

For my resume, I think that XML that can be rendered into HTML (or any other format) is the best option, and in that case, I could even build a "resume manager" using PHP that can edit the underlying XML. A resume also seems like it could be built on top of MySQL, as well, and generated into XML or HTML or whatever output format I choose.

However, I'm not sure how to store my about me/bio. My initial idea was a plain text document that can be read it, parsed, and the line breaks converted to paragraphs. However, I'm not sold on that being the best idea. My other idea was using MySQL, but I think that might be overkill for a single page. What I do know, however

What techniques have you used when storing text for a page that will not change very often? How did they work out for you - what problems or successes did you have?

+2  A: 

Just use a static page, if the information won't change very often. Just using static HTML gives you more control over the display format.

McWafflestix
I don't see how static HTML will give me any more control over the display format than a well designed solution using some combination of PHP, MySQL, JavaScript, and XML. Could you elaborate on that point, especially with the MVC paradigm in mind?
Thomas Owens
Are you suggesting the same thing that Boldewyn is?
Thomas Owens
If the information doesn't change, scripting behavior is useless; don't bother using it. That's what I'm saying.
McWafflestix
Simple solution for simple task.
Mercer Traieste
@MercerTraiste: Exactly.
McWafflestix
+2  A: 

Generally treating infrequently changing information the same as frequently changing information works well if you add one other component: caching.

Whatever solution you decide on for the back end, store the output in a cache and then check to see if the data has changed. Version numbers or modified dates work well here. If it hasn't changed, just give the cached data. If it has changed then you rebuild the content, cache it and display.

As far as structure goes, I tend to use text blobs in a database if there is any risk that there will be more dynamic databases. XML is a great protocol for communicating between services and as an intermediate step, but I tend to use a database under all my projects because eventually I end up using it for other things anyway.

Godeke
Caching is the silver bullet, but it's also the complexest to achieve. +1
Boldewyn
... think of cache invalidation, performant cache retrieval, ...
Boldewyn
Actually I don't believe in silver bullets, but simplistic caching is... simplistic. For low volume and simple design sites a simple version number check to avoid a rebuild is enough. Of course you can get into component caching instead of page caching, multi-level caching and all that. I don't think that is what the question requires though.
Godeke
+3  A: 

Like McWafflestix said, use HTML, if you want to output HTML. Simplest case within PHP:

<?php
create_header_stuff();
include('static_about.html');
create_footer_stuff();
?>

and in static_about.html something like

<div id="about">
...
</div>

Cheers,

Boldewyn
Ah. This use of static HTML makes more sense to me than McWafflestix's textual description.
Thomas Owens