On Sun, 2009-01-11 at 17:01 +0000, Nathan Rixham wrote:
>
> i love these discussions on pedantics and semantics!
>
> personally (when I need to) I always go for a bit of concatenation so in
> the example above:
>
> // somewhere in the business logic / functional layer
> $imgHTML = '<img src="' . $url . '" alt="' . $alt . '" title="' . $alt .
> '" class="' . $imgclass . '" />';
I do the same, except why you have all those space around your
concatenation I don't know. Although, to be honest I tend to vertically
spread my tags/attributes:
$imgHTML =
'<img'
.' src="'.$url.'"'
.' alt="'.$alt.'"'
.' title="'.$alt.'"'
.' class="'.$imgclass.'"'
.' />';
This makes it easy to see at a glance what is there and to also comment
out lines easily.
> .....
> // somewhere in the display layer
> echo $imgHTML;
For images I usually do:
<jinn:image src="//path/to/image"/>
The custom tag will expand the path to wherever the images directory was
defined and will scan the image for width and height and add those
attributes also.
> however; I only really do this when developing or in a quick bit of
> script; whenever possible I'll always use a templating engine, or
> xml/xsl which is the perfect abstraction between data and presentation IMHO.
>
> another little note is that I'd never echo out a class or presentation
> data; infact I'd never use a class on a tag such as img either,
> preference going to a bit of css using selectors
>
> div#article_content p img {
> /* whatever */
> }
Personally, I try not to use IDs to target my stylesheets. I try to use
IDs to target actual objects within the document for use with DHTML or
forms processing. It's a pain in the ass overriding a CSS rule that was
targeted with an ID since the ID carries so much weight. Otherwise, I
generally use higher up class definitions and do as you have done by
drilling down to individual members of the rule.
> I'm not sure what's brought me to these conclusions, I've certainly been
> through all the other methods of doing it - however for a couple of
> years now I've limitted all presentation to css only, css contained in a
> stylesheet - I try to use minimal css classes, and stick to using an id
> wherever I can't simply redefine the html tag.
I use lots and lots of CSS classes, all nicely kept in their own
contextual template files that are then built into the grand stylesheet
file with all my internal comments stripped from production.
> TBH i think even if I'm doing a complete site myself, I still like to
> wear different caps (developer, designer, etc) and as such keep the
> layers as seperate as possible, as if it was somebody completely
> different working on the design.
Absolutely.
> the above means that moving back to the original <h1> example(s) I'd simply
>
> <h1>whatever</h1>
I'd probably do:
<project:title>Whatever</project:title>
Which would expand to:
<h1 class="mainTitle">Whatever<jinn:accFlush
name="contentTitle"/><jinn:accFlush name="contentTitle"
dyanmic="true"/></h1>
Which would expand to a bunch of intermixed HTML/PHP code directly in
the requested document.
The reason for the accumulator flush is to add content to the title in
an unrelated area of the templates as is occasionally necessary. The
first inserts accumulated content during the build process, the second
allows insertion at run-time. Run-time is probably used more often since
it may be when editing a user profile or something and the name is
inserted into the title from the form controller. The compile time
version is used less often but has no run-time hit since it's pre-built.
> css:
> h1 {
> color: rgb(255,0,0);
> font-size: 1.2em;
> }
>
> seeing as you can only have one h1 tag on a single document.
Says who?
> if you can take any points from this ramble of mine, it'd be that IMHO
> the output from a script should at most comprise of something like:
> <?php
> // business logic
> $display_engine->output( $template , $variables );
> ?>
> infact ideally an html tag should never be seen in a php script
That depends on what the role of the PHP script is. A custom tag handler
certainly should output HTML. A forms engine certainly should hide the
HTML details unless you want to do all the low level form crap yourself
(mine outputs convenient CSS classes/ids transparently for me).
> ... and to take it further a echo'd string probably shouldn't either! so
> technically this is bad:
Again that depends on the purpose of the echo'd string. And also whether
you just use PHP for web applications, or as I and many others do, also
use it for shell scripts.
>
> <?php
> if( whatever() ) {
> // whatever
> } else {
> echo 'turns out you entered some invalid data client';
> }
> ?>
>
> while this is good
> <?php
> if( whatever() ) {
> // whatever
> } else {
> throw new UnexpectedValueException( WHATEVER_ERROR_CODE );
> }
> ?>
>
> which is caught higher up, the localized error message for
> WHATEVER_ERROR_CODE is then loaded, fired through to the display engine
> which formats and displays it to the client.
Via echo? Thought you didn't like echo ;)
> can seem like overkill, but if you want to have multiple front ends to
> you're app (say a soap interface, a flash ui and an html ui) there's no
> other way.
You're still echoing it though.
Cheers,
Rob.
--
http://www.interjinn.com
Application and Templating Framework for PHP
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
