Robert Cummings wrote:
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:
re: space around concatenation; I add spaces in wherever I can, find it
easier to read the code; and when it's a particularly long string it
makes it far more readable; so using my own false logic if it's easier
to see long, it's easier to see short as well.
re: vertically spread; I often do the same thing, general rule of thumb
is if it's anywhere near a full line or scrolling sideways I'll
multi-line it - in this case I would have multi-lined in my own code
aswell :)
$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 use it for both; but sparingly for example <div id="primary_nav">
means I should be able to pick up all sub elements for both dom
manipulation and css rules
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.
only time I'll use lots of classes is for things css like red,
top-padding, bold etc (generics) never for .leftPageImageFirstImage
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.
I do like you're interjinn.. it's like a good coldfusion (no offense
intented)
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?
well it's logical good practise I guess - not a hard and fast rule
(although should probably be thought of as a rule..?)
H* tags are used to describe the semantic structure of a document, the
H1 tag being used to describe what the entire document / page is about,
then h2-h6 being used to split it into sub sections / sub headings. Thus
two H1 tags indicates that the document is two different documents. The
W3C site itself is normally a good indication for things like this, I'm
100% sure if you check the source for every page you'll not find a
single case where there are two H1 tags.
example:
http://www.w3.org/TR/xhtml1/
from the source:
<h1><a name="title" id="title"></a> XHTML™ 1.0 The Extensible HyperText Markup
Language (Second Edition)</h1>
because the document is the "XHTML™ 1.0 The Extensible HyperText Markup
Language (Second Edition) "; if there was a Third Edition it'd be in a
different document
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.
ahh vague misunderstanding, echo's shouldn't be in the business logic
layer, only in the presentation layer, regardless of whether it's a CLI
script or not (caveat being for development debugging I'd reckon) - I'm
sure you follow :)
<?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 ;)
again just not using echo in business / functional layer - we've all
seen those rush job scripts where it's a massive page of php <html> &
<head> at the top then all the functional code mixed right in with a
tonne of echo's (like a db query, loop then echo out each row) -
personally it's a pet hate, that'd be concatentated into a variable and
then echo'd out at the display layer - makes life so much easier to keep
seperate - again sure you follow.
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.
lol - yeah but in presentation layer not business / functional layer.
I'm a stickler for using a 3-tier / MVC or normally an n-tier architecture!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
