tedd wrote:
At 1:54 PM -0600 5/24/09, LinuxManMikeC wrote:
You're missing the point just because he threw in some old HTML
styling attributes. The main issue is the overhead of added parsing
layers to find where content goes in the HTML.
I may be missing the point, but I know where content goes in my scripts
and I do that without any parsing.
I've reviewed dozens of projects that use templates and have not found a
single one that considers the separation of languages as it should. As
I've said on the css-discuss list many times (they don't like to hearing
it) but no web language operates in a vacuum.
If you are programming for the web and creating web pages and
applications, then you had better understand how all the different web
languages fit together in current and best practices or you'll just be
generating shortsighted code. It will be just someone else's problem
later to deal with.
agreed, it's just separation of cross cutting concerns applied on all
levels of the application; technologies included. You should be able to
strip any one tech out of an application and replace it with another simply.
This is the one reason I stay clear of big frameworks - if a client
decides they don't like one part of it or hears something bad and wants
it all removed then omg the whole thing was built with "framework name"
- recode! or.. ever had a client say "we want to move from mysql to
postgres" or conversely?
back to the subject though; I hear what you're saying tedd and couldn't
agree more - IMHO the worst thing about xhtml is that damn style
attribute, it should never have been implemented / included - then this
debate wouldn't be happening.
Aren't we already
using a language (PHP) that parses for place holders for dynamic
content within HTML tags?
No, I use php/mysql to pull the data I need and assemble the html to
hold the data where I want it. From there, I use css to make the
presentation and javascript to handle user enhancement. I don't see
where templates help matters much -- especially when most of them use
embedded styling elements such as the font tag for God's sake - that's a
giant step backwards.
having this discussion off-list myself at the minute - seems like the
xslt approach to me (without the xml) and I'm all in favour of it.
data is data, presentation is presentation - if there needs to be a
transformation on the data provided to turn it in to the data the
presentation expects then so be it - but keep the data as structured
data and simply make it available. (n-tier / layered approach too I guess).
Write the template in XHTML, style it with
CSS, and insert content place marks with PHP short tags. Do the
programming work of calculations, validation, and DB access in another
script which will include the template at the appropriate time. Even
create classes to hold various data sets (think JavaBeans) if you
want. Adding a layer of abstraction just so your designers don't have
to write <?=$var?> is silly at best. At lest that's my opinion. Do
whatever works for you.
I do what best works best for my clients*.
If you are writing XHTML, then using <?=$var?> won't work -- did you
know that? That's akin to using a font tag -- it's been outdated and the
reason why I said above use "best practices".
Additionally, my designers design -- I assemble their designs into
functioning web pages and applications. I see no need for any designer
to ever worry about embedding html, php, mysql, javascript, css or any
other web language into my work. They design and I program -- that's the
layers of abstraction I deal with.
often though you have dedicated web designers who do html, css java and
nothing else - and a graphics design guy and the developers (php +
server side) - that was a pointless comment though and it is all
scenario based.
I'm having a huge internal debate on this one at the minute.. somethings
missing.
regards!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
