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.


PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to