Robert Cummings wrote:
On Mon, 2009-05-25 at 15:04 +0100, Stuart wrote:
2009/5/25 Robert Cummings <robert@xxxxxxxxxxxxx>:
Have I done something to annoy you lately? You seem to be directing a
lot of hostility my way recently. Just wondering.
I'm sorry you're taking it personally... you may want to invest some
time into growing thicker skin. It's a rare day indeed that I waste the
time and energy needed to be hostile to an individual person. I have
better things to do.
It's true to say that I only remember what I want to remember, but
that's only because my head is of a fixed size and I don't want to
forget how to walk, eat or sleep. However, when I'm presented with an
alternative point of view I give it the attention it deserves. If it
can help me in my day-to-day work you can be damn sure I'll remember
it, and that I'll use it!!
Anyways, I'm assuming you're referring to this post:
http://www.mail-archive.com/php-general@xxxxxxxxxxxxx/msg242954.html.
Let's take a look at these points shall we...
* To simplify the use of parameters so that they can be used in
arbitrary order with default values.
Parameters to what? I don't really see what you're referring to here.
I guess you don't have flexible includes. One size fits all. But many of
my custom tags are akin to functions, they accept variables that allow
either compile-time or run-time configuration of a given piece of
content. For instance:
<jinn:menu title="Some title" accumulators="true" expand="active">
<item caption="About Us" href="//about-us/">
<subMenu>
<item caption="Profile" href="//about-us/profile"/>
<item caption="Partners" href="//about-us/partners"/>
</subMenu>
</item>
<item caption="Forums" href="//forums/"/>
</jinn:menu>
This is all expanded at compile time with appropriate div/ul/li/a tags
for styling and accessiblity correctness. Saves oodles of time from
having to do it by hand everytime. Similarly, the PHP engine isn't doing
it on every page request, nor is it being retrieved at run-time from a
cache on every request.
so..
- in your template you've hard coded data that would typically be
managed by a cms (captions, hrefs, which pages are shown)
- using a syntax that nobody knows
- which removes most of the functionality a web developer wants (such as
choosing which elements, class, ids, additional attributes)
I'm a big fan of xslt and xml; but this just seems completely inverse to
every other approach I've seen - it's removed all presentation based
stuff from the presentation layer??
kinda thought the whole point of a template was to be able to specify
the structure of the document and place the data you want where you want
it, in the way you want to.
Not to tell a custom system to give you a block of html code it thinks
is best while you manually specify the data to be used in the html it
generates. (?)
* To allow for the encapsulation of complex content in tag format that
benefits from building at compile time and from being encapsulated in
custom tags that integrate well with the rest of the HTML body.
See above example.
"integrate well with the rest of the HTML body"?? I guess you mean "it
looks the same as the HTML". You consider this a good thing? Each to
their own I guess.
XML, for the most part, walks and talks like HTML.
conversely, html is a markup language, then they made xhtml which
conforms to xml syntax; thus (x)html walks and talks like xml.
again xml rocks; but we already have xsl (transformations) which are
supported by both php on the server side and by most browsers on the
client side - which makes it awesome as you can simply dump out your
data as xml and let the client machine do all the rendering. Also XSL /
XML have had the input from the worlds best, for many years, are
recommended, fully thought out and well supported.
* To remove the necessaity of constantly moving in and out of PHP tags.
What do you have against PHP tags? It's exceedingly cheap to move in
and out of PHP tags, especially when compared to other things your
site will be doing like connecting to databases or accessing files.
It disrupts the readability of the code/content itself. I use them often
enough in various projects. Additionally, there are quirks with PHP tags
and newlines being eaten in the content that requires a superfluous
newline be added to the content itself.
I vaguely agree on this one, it can disrupt the readability of an xhtml
based template - unless you have a decent IDE then it makes no odds.
new line quirks I'd like to see some examples of though - never came
across this (yet) myself. Got any examples
* To speed up a site.
By this I'm assuming you mean based on performing substitutions in
templates at compile time as opposed to runtime. I would argue that if
you have large parts of a template that never change, why are they
dynamic in the first place? However, this has very little bearing on
the speed of a site. My templating system uses several levels of
caching that effectively achieve the same result.
No, caching is not the same as a template engine that compiles the
actual requested source code. A cache has an intermediate run-time step.
My engine can do both styles, but it's an obvious speedup to not need a
cache or even my template engine running at request time.
can one assume then that this is a publish based system whereby you
republish the "site" / html when you change or update something? (even
if that's just publishing the templates and including them in ouput)
* To speed up development.
This one you're going to need to explain in a bit more detail. How is
writing templates in XML any quicker than writing them in PHP?
If I don't need to manually type out all the divs and various other
structural elements for HTML (or some other presentation system) then
I've saved time. See above example, the syntax is simple, but the
content generated less so. As such, I've saved time.
can't see how this
<subMenu>
<item caption="Profile" href="//about-us/profile"/>
<item caption="Partners" href="//about-us/partners"/>
</subMenu>
is any faster to write than (learning curve not included)
<ul>
<li><a href="/about-us/profile">Profile</a></li>
<li><a href="/about-us/partners">Partners</a></li>
</ul>
I can see though that every dev and their dog knows the pure html
example inside out and how to customise it.
I really don't get the point in using an alternative markup langauge to
generate the same amount of html with no real functional benefits?
maybe its an example thing.. if it was something like
<subMenu>
<ul>
<item><li><a href="/href">/caption</a></li></item>
</ul>
</subMenu>
then I'd get it..
* To make easier to use for non-developers.
I hear this argument a lot but I'm yet to meet a designer familiar
with something like Smarty who could not pick up basic PHP very
quickly. The concepts involved are very similar and utility functions
can be written that provide the same operations that Smarty makes
available. Actually I should caveat that statement by noting that I
did once work with a team of designers who refused to even attempt
using PHP, but I put that down to them being scared of it - I failed
to talk them round.
Sorry, my experience does include non-programmer content writers. My
system is not smarty, it should not be confused with smarty. I've used
smarty and I don't like smarty *lol*.
confused..
people write content in the templates and then let the system control
the format of the html thats generated?
not people write content in a cms then the template controls how the
content is displayed?
* To integrate standards compliance checks into the build phase.
IMHO this is a false notion. You can check the templates for standards
compliance, but not the output. The nature of templates is that
they're not complete until they have been filled in with dynamic data.
True standards compliance checks can only be performed on the output
from a site, not the inputs.
Wrong, this is not a false notion. Your ignorance doesn't make it false.
My engine allows tying content validation to the build phase because the
build phase knows the final URL, and submits the final URL to the
validation engine for validation. Not the template, not the compiled
content which will often contain PHP code, but the actual URL for the
compiled page is sent to the validation engine. Alternatively the
post-handler could retrieve the content itself from the known URL via
cURL and submit this to the validation engine. Given this scenario, you
have probably realized the dynamic bits are filled in since it's the
same as any request by a browser.
if its invalid can it fix it? or is it just a report? does it prevent
publishing or?
ps: couldn't any dev just do the same on any site (or even call
http://validator.w3.org/check?uri=URL_HERE )
* To do sooooooooooooooo many things that are just inconvenient and
tedious using intermingled PHP code with fixed parameters order (or
alternatively a big fugly array).
Again with the "fixed parameters order". What the smeg do you mean by
that? And "a big fugly array"? Not sure what you mean by that either.
If you don't understand what is meant then I'm not about to teach you. I
would guess the majority of readers know exactly what I'm talking about.
If you need a hint, go back to the first paragraph of this response.
with the example i get you now, first time round i was lost - still
though writing the same amount of jinn code as you would html code but
with less functionality - is that not just as inconvenient and tedious
(to 99% of people)
Quick question, how would you implement the following using your
XML-based template syntax...
<div class="option <?php if (!empty($option_class)) { echo
$option_class; } ?>"> ... </div>
It depends, from whence is the data coming? My engine supports run-time
conditional tags that can do this verbatim. The problem is, content is
usually encapsulated in a view so I wouldn't be pulling it form the
global scope. I don't like the empty() function anyways, it's a kludge
since 0 is also considered empty, and I consider 0 a value. Null, false,
and the empty string would echo just fine as an empty string and so
would not need a conditional around them. I would probably have sorted
this in the business logic.
lol @ the empty() bit - it has its uses though and thankfully we're not
limited to using only empty()!
It's worth noting that I'm simply suggesting a different way of
looking at the world. If you have a templating system you're happy
with then feel free to continue using it, but I'd encourage you to
take the time to consider whether it actually gives you any tangible
benefits. I've used Smarty as well as a number of proprietary
templating systems and I'm yet to come across one that can justify its
existence over simply using PHP.
I'm all for different ways of looking at the world, but patently false
arguments are annoying. They come up with respect to templates quite
often.
It's also worth noting that when I refer to a "templating system" I
mean something that introduces an extra step when running a template.
I consider the template classes I use to be a templating system but
they do nothing but formalise the process of passing data to other PHP
scripts and providing utility functions for them to use.
The extra step exists whether it occurs at run-time or once at
compile-time. The advantage to compile-time is that it occurs once for
all subsequent requests. Run-time occurs every time unless a cache is
used, in which case the outermost cache request occurs every time.
there's a time and a place for both though - if you've got a semi static
website or classic brochure site for an sme then yeah precompile; but
this approach can kinda kill an app when a view/page is comprised of
data which changes a few times a second and is different on a per user
basis. (think any major site)
all this has actually really helped me - as I now know for sure that I
don't want to use anything at all that has an alternative or
non-standard syntax; telling a ui guy they need to learn something new
and custom just to do some html doesn't sit well with me; I can make
excuses for things most ui guys know anyways.
Ultimately, i think that xslt and flash / flex are my fav approaches -
and as for a templating engine focused on xhtml/xml output - well there
just isn't a decent one and this is why php was created in the first place?
the one major benefit I see from using a template engine, however good
or bad (with its own syntax, not php), is that it ensures no business
logic is in the presentation layer.
seen one too many mysql_query / while / echo loops in my life.
regards!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
