At 3:19 PM +0000 1/10/09, Nathan Rixham wrote:
tedd wrote:
While one can look at it as defensive programming, it has a larger
scope than that.
Certainly you want to sanitize all input from users to prohibit
injections, but more than that you want to keep data separate from
presentation.
exactly: you want to keep data separate from presentation.
only scope for this is that sometimes you want to store html /
presentation data (seeing as it is data)
I understand that one might want to consider storing presentation
elements as data in a database, but the alternative would be to
simply keep html as html and control the styling via css.
One might want to design a CMS for a client (I've done it) such that
you limit the client's ability to inject presentation choices, such
as using bold/italic tags. But that also requires more programming
effort to determine if the client has entered well-formed html, which
is not easy to do. Lot's of effort for little return.
When confronted with the choice, I try to guide clients into CMS's
where I use constructs like 'Please enter the headline here:" and
"Please enter the body of the text here:" and then provide the <h1>
and <p> tags in the html that delivers the content. That way I
control both the data and presentation.
I could imagine a database containing what <h1> means (i.e.,
font-size, margins, color), but that would not be any different than
a simple css file, would it not? And be much simpler.
Cheers,
tedd
--
-------
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
