Re: [PHP] templating engine options
On Mon, May 25, 2009 at 6:44 PM, Nathan Rixham nrix...@gmail.com wrote: Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: I continued the discussion with Nathan. I too have had an off-list discussion with Nathan on this topic, and a productive one at that. which would probably be a good time for me to step back in; having had a nice little inside in to both Robert and Stuarts template systems, and indeed way(s) of doing things. Also thanks to everybody else who made suggestions and gave input - it was all appreciated. I'm far from making a final decision, as I've decided to approach this by setting a few guidelines and a wishlist, then either finding / modifying something to do the job, or creating something from scratch. Both Rob and Stuarts systems were more in common than they may think, focus in both was on performance, and only making set data available to the templates (whether pushing or pulling). The syntax did differ though, and functionality aside this is probably one of the most important aspects (imho). Markup XML sits well with me (and most) because we are web developers and use it daily. PHP syntax also sits well because we also use it daily. The fact remains though that this feels like (and possibly is) a different job which requires something different. Both XHTML and PHP do their job well - just as ecma(java)script and css do theirs. However none of these technologies / languages are suited and dedicated to converting provided data in to specified output; specifically, and only, xhtml. XSL Templates are near perfect, built for the job, and very powerful - but time hasn't favoured them well; and until (if ever) a wide spread adoption happens something else needs to fill the gap. Template Specific Thoughts: Smarty, Stuarts Engine, Robs Engine, PHPLIB and many more had one common theme, they all limited the data available. My terminology of limited perhaps sounds wrong, so maybe make specified selected data available or provide access to the view will make more sense. Inline with layered and tiered application design this makes perfect sense; thus.. A template /should/ only be able to access the data made available to it, nothing else. Whether it requests the data or the data is provided is covered later. If it doesn't have all the data needed then this needs reviewed and the application needs changed to provide it. Not the template engine bastardized to accommodate a limited app. A template ~should~ have unique yet easy to understand syntax, something that complements xhtml and provides all needed functionality. (IMHO it should not be php syntax) A template engine must stick within it's role boundaries, it's not a cache engine, its not php, its not xhtml, its not for implementing functionality - it is simply and purely to do its job - take data, populate an xhtml template with it and return the result - nothing more, nothing less. Push vs Pull. This is a much bigger issue than I thought, and perhaps is the crux of the whole thing. I can see two clear approaches; Firstly, (the common one) - app passes data and a template to the template engine - template engine merges it together and passes back - app does as it pleases with data (sends it to client, caches it, fires it in an email - whatever) Secondly, (uncomment) [think modular] - app provides an api / gateway to views of data - template engine requests view(s) specified in template from app - template engine populates template modules with data sends output to I guess the first is template engine as a Util / Service - and the second is template engine as a Layer / App. There are pros and cons in each design, concentrating on the second design for now - this brings in a lot of scope which seems to fit well both practically and architecturally. The freedom to be able to specify in template that... this is template module latest posts, it is bound to the data view (or data provider) latest posts(8) whilst overall combining template (page) is comprised of modules x,y and z - here, here and here. ...really appeals to me; certainly in this scenario where you request (pull) from the application rather than make it all available. This way you only ever perform the business logic required for the information available. The counter part of making everything available incase it may be used is ridiculous (and makes me think coldfusion for some reason??). Architecturally this appears to be good - it's the presentation tier being a presentation tier, the logic tier knows nothing of the presentation tier and simply serves up what is requested. However thats only on the one side of the tier - on the other side we have a huge gaping hole where functionality should be (cache, compilation, delivery) etc, which would require another, as yet unknown layer (or 2). The abstraction and separation of concerns in this setup really appeals
Re: [PHP] templating engine options
On Mon, 2009-06-01 at 12:38 -0400, Andrew Ballard wrote: On Mon, May 25, 2009 at 6:44 PM, Nathan Rixham nrix...@gmail.com wrote: Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: I continued the discussion with Nathan. I too have had an off-list discussion with Nathan on this topic, and a productive one at that. which would probably be a good time for me to step back in; having had a nice little inside in to both Robert and Stuarts template systems, and indeed way(s) of doing things. Also thanks to everybody else who made suggestions and gave input - it was all appreciated. I'm far from making a final decision, as I've decided to approach this by setting a few guidelines and a wishlist, then either finding / modifying something to do the job, or creating something from scratch. Both Rob and Stuarts systems were more in common than they may think, focus in both was on performance, and only making set data available to the templates (whether pushing or pulling). The syntax did differ though, and functionality aside this is probably one of the most important aspects (imho). Markup XML sits well with me (and most) because we are web developers and use it daily. PHP syntax also sits well because we also use it daily. The fact remains though that this feels like (and possibly is) a different job which requires something different. Both XHTML and PHP do their job well - just as ecma(java)script and css do theirs. However none of these technologies / languages are suited and dedicated to converting provided data in to specified output; specifically, and only, xhtml. XSL Templates are near perfect, built for the job, and very powerful - but time hasn't favoured them well; and until (if ever) a wide spread adoption happens something else needs to fill the gap. Template Specific Thoughts: Smarty, Stuarts Engine, Robs Engine, PHPLIB and many more had one common theme, they all limited the data available. My terminology of limited perhaps sounds wrong, so maybe make specified selected data available or provide access to the view will make more sense. Inline with layered and tiered application design this makes perfect sense; thus.. A template /should/ only be able to access the data made available to it, nothing else. Whether it requests the data or the data is provided is covered later. If it doesn't have all the data needed then this needs reviewed and the application needs changed to provide it. Not the template engine bastardized to accommodate a limited app. A template ~should~ have unique yet easy to understand syntax, something that complements xhtml and provides all needed functionality. (IMHO it should not be php syntax) A template engine must stick within it's role boundaries, it's not a cache engine, its not php, its not xhtml, its not for implementing functionality - it is simply and purely to do its job - take data, populate an xhtml template with it and return the result - nothing more, nothing less. Push vs Pull. This is a much bigger issue than I thought, and perhaps is the crux of the whole thing. I can see two clear approaches; Firstly, (the common one) - app passes data and a template to the template engine - template engine merges it together and passes back - app does as it pleases with data (sends it to client, caches it, fires it in an email - whatever) Secondly, (uncomment) [think modular] - app provides an api / gateway to views of data - template engine requests view(s) specified in template from app - template engine populates template modules with data sends output to I guess the first is template engine as a Util / Service - and the second is template engine as a Layer / App. There are pros and cons in each design, concentrating on the second design for now - this brings in a lot of scope which seems to fit well both practically and architecturally. The freedom to be able to specify in template that... this is template module latest posts, it is bound to the data view (or data provider) latest posts(8) whilst overall combining template (page) is comprised of modules x,y and z - here, here and here. ...really appeals to me; certainly in this scenario where you request (pull) from the application rather than make it all available. This way you only ever perform the business logic required for the information available. The counter part of making everything available incase it may be used is ridiculous (and makes me think coldfusion for some reason??). Architecturally this appears to be good - it's the presentation tier being a presentation tier, the logic tier knows nothing of the presentation tier and simply serves up what is requested. However thats only on the one side of the tier - on the other side we have a huge gaping hole where functionality should be
RE: [PHP] templating engine options
Moreover, you can transform XML into JSON via specific XSLT True, I forgot to mention it in my post, XSL just transform, and similar structures can use the same XSL so another reason to prefer it over php in the html. Regards Date: Wed, 27 May 2009 11:47:56 -0400 From: aball...@gmail.com To: f...@thefsb.org CC: nrix...@gmail.com; php-general@lists.php.net Subject: Re: [PHP] templating engine options On Tue, May 26, 2009 at 5:49 PM, Tom Worster f...@thefsb.org wrote: thanks for taking the trouble to write your requirements. it made interesting reading. i've questions on three points below... On 5/25/09 6:44 PM, Nathan Rixham nrix...@gmail.com wrote: XSL Templates are near perfect, built for the job, and very powerful - but time hasn't favoured them well; and until (if ever) a wide spread adoption happens something else needs to fill the gap. i don't know xsl well, but from what i read it seems to be about taking data from one xml document and putting it into another. Not really. The most common use may be that, but xsl can convert an XML document to pretty much any format you want and can even convert between compatible encodings. (You would lose something to try to convert from Chinese to Latin1, obviously, but you should be able to convert from Latin1 to UTF-8 or from UTF-8 to UTF-16 if desired.) It is even possible to go from XML to PDF. (I haven't tried it, so I don't know how well it works.) [snip] one thing i wasn't clear about with xsl is whether or not there's any output language dependence? could i write a template to produce an sql file, or an email in russian? Exactly. The input XML document and the XSL stylesheet must both be valid XML, but the output can be just about anything you want. You could have an XML table definition and use XSL to translate that structure into a valid SQL statements using that table in a specific SQL vendor dialect. Those could be anything as simple as generating CREATE TABLE statements to build a script to create a database or as complex as building stored procedures against those tables. Andrew -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php _ Drag n’ drop—Get easy photo sharing with Windows Live™ Photos. http://www.microsoft.com/windows/windowslive/products/photos.aspx
Re: [PHP] templating engine options
On Tuesday 26 May 2009 03:48:41 am Nathan Rixham wrote:
Sancar Saran wrote:
?php
$content = 'No Comments';
if(isset($comments) and is_array($comments) and count($comments) 0 ) {
$content = '';
foreach( $comments as $index = $comment ) : $content. = a href='.
$comment-link.'.$comment-title./a; endforeach;
}
?
h2Comments/h2
div id=comments
?=$content?
/div
index.php
ob_start();
require('template.php');
echo ob_get_clean();
I'm still do not understand for complex template system requirement.
I just _need_ the two abstracted.
php must have no html in it
html template must contain no php
Why it have to be very complex system.
Large data array, some conditions, lots of loops, and What else ?
http://www.flytag.de/
http://urlaub-finder.de/
http://airportdirekt.de/
All same system. With different css designs.
yup, did this myself for a long time; here is some very old code I
used to use!
newCage();
$content = cage(include $file);
function newCage() {
ob_start();
}
function cage() {
$includeOutput = ob_get_contents();
ob_end_clean();
return $includeOutput;
}
lol
Alright, my vote going to smarty.
After compilation, it running on native php.
And
When we use TYPO3 native marker model (which fits your requirement, no php in
template) I found very dull. Load template to memory, fetch part of template,
generate loop for processing template, feed template keys in the loop.
After some time %75 of code become template feed. Like this
//--- Get Template
$this-templateFileContent = $this-cObj-
fileResource('fileadmin/templates/travelit_booking.html');
$strCarLoop= $this-cObj-getSubpart($this-
templateFileContent,###CAR_LOOP###);
$strPLoop = $this-cObj-getSubpart($this-
templateFileContent,###PASSANGER_LOOP###);
$strCarTable = $this-cObj-getSubpart($this-
templateFileContent,###CAR_TABLE###);
$strHotelBooking = $this-cObj-getSubpart($this-
templateFileContent,###HOTEL_BOOKING###);
$strFlightBooking = $this-cObj-getSubpart($this-
templateFileContent,###FLIGHT_BOOKING###);
if(isset($arrData['MW']) is_array($arrData['MW']['MWLIST']['CAR']))
{
$intCarSize = sizeof($arrData['MW']['MWLIST']['CAR']);
for($intX=0;$intX $intCarSize;$intX++)
{
$arrSubst = '';
$arrSubst['###CAR_OPTION_VALUE###'] =
$arrData['MW']['MWLIST']['CAR'][$intX]
[@]['GROUP'].-.$arrData['MW']['MWLIST']['CAR'][$intX][@]['ID1'].-.
$arrData['MW']['MWLIST']['CAR'][$intX][@]['ID2'].-.$arrData['MW']
['MWLIST']['CAR'][$intX][@]['NAME'].-.$arrData['MW']['MWLIST']['CAR']
[$intX][@]['PRICE'];
$arrSubst['###CAR_OPTION_PRICE###'] =
number_format($arrData['MW']['MWLIST']
['CAR'][$intX][@]['PRICE'], 0, ',', '.');
$arrSubst['###CAR_OPTION_NAME###'] =
$arrData['MW']['MWLIST']['CAR'][$intX]
[@]['NAME'];
$strCarss.=
$this-cObj-substituteMarkerArrayCached($strCarLoop,$arrSubst);
}
}
!-- ###CAR_LOOP### begin --
option value='###CAR_OPTION_VALUE###'
nbsp;###CAR_OPTION_PRICEnbsp;euro;nbsp;###CAR_OPTION_NAME###/option
!-- ###CAR_LOOP### end --
!-- ###CAR_TABLE### begin --
tr
td colspan='5' style='text-align:center;
font-size:14px;'
###BOOKING_RENT_A_CAR_LABEL###
/td
/tr
tr
td colspan='2'
center###BOOKING_RENT_A_CAR_INFO###/center
br/br/
centera href='#'
onClick='Open_Window(http://www.sunnycars.com/b2c.docs/deu.l/single_vehicledetails.html?+getCarUrl(),SUNNY,scrollbar=yes,800,600)'img
src='/fileadmin/templates/img/scar.gif' border='0' /
br/br/###BOOKING_CAR_INFO_LABEL###/a/center
/td
td colspan='4'
select name='MWTYP' size='10'
option
value='-'###BOOKING_I_DONT_WANT_TO_RENT_A_CAR###/option
###BOOKING_RENT_A_CAR_LOOP###
/select
/td
/tr
!-- ###CAR_TABLE### end --
Then I realize, doing some coding for data which I already have make me sick.
and When you go with multi language site you will realize, every tiny bit of
template have to template marker keys. And you have to do this mule job
And begin to use this.
table border='0' cellpadding='0' cellspacing='0' class='dtable rbook-renta-
car'tbody
tr
RE: [PHP] templating engine options
Finally somebody mentioned XSL Transformations. Time is relative because as you need time to learn an API to produce quickly only after a while, thanks to knowledge and confidence, XSL is the same with the advantage that you transform a data structure, rather than work over raw programming language ( portability and re-usability ) I wrote a post in my blog about this long thread, hope you'll get some point: http://webreflection.blogspot.com/2009/05/template-engine-why-bother-xml-xslt.html Best Regards Date: Mon, 25 May 2009 23:44:43 +0100 From: nrix...@gmail.com To: stut...@gmail.com CC: rob...@interjinn.com; linuxmanmi...@gmail.com; tedd.sperl...@gmail.com; php-general@lists.php.net Subject: Re: [PHP] templating engine options Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: I continued the discussion with Nathan. I too have had an off-list discussion with Nathan on this topic, and a productive one at that. which would probably be a good time for me to step back in; having had a nice little inside in to both Robert and Stuarts template systems, and indeed way(s) of doing things. Also thanks to everybody else who made suggestions and gave input - it was all appreciated. I'm far from making a final decision, as I've decided to approach this by setting a few guidelines and a wishlist, then either finding / modifying something to do the job, or creating something from scratch. Both Rob and Stuarts systems were more in common than they may think, focus in both was on performance, and only making set data available to the templates (whether pushing or pulling). The syntax did differ though, and functionality aside this is probably one of the most important aspects (imho). Markup XML sits well with me (and most) because we are web developers and use it daily. PHP syntax also sits well because we also use it daily. The fact remains though that this feels like (and possibly is) a different job which requires something different. Both XHTML and PHP do their job well - just as ecma(java)script and css do theirs. However none of these technologies / languages are suited and dedicated to converting provided data in to specified output; specifically, and only, xhtml. XSL Templates are near perfect, built for the job, and very powerful - but time hasn't favoured them well; and until (if ever) a wide spread adoption happens something else needs to fill the gap. Template Specific Thoughts: Smarty, Stuarts Engine, Robs Engine, PHPLIB and many more had one common theme, they all limited the data available. My terminology of limited perhaps sounds wrong, so maybe make specified selected data available or provide access to the view will make more sense. Inline with layered and tiered application design this makes perfect sense; thus.. A template /should/ only be able to access the data made available to it, nothing else. Whether it requests the data or the data is provided is covered later. If it doesn't have all the data needed then this needs reviewed and the application needs changed to provide it. Not the template engine bastardized to accommodate a limited app. A template ~should~ have unique yet easy to understand syntax, something that complements xhtml and provides all needed functionality. (IMHO it should not be php syntax) A template engine must stick within it's role boundaries, it's not a cache engine, its not php, its not xhtml, its not for implementing functionality - it is simply and purely to do its job - take data, populate an xhtml template with it and return the result - nothing more, nothing less. Push vs Pull. This is a much bigger issue than I thought, and perhaps is the crux of the whole thing. I can see two clear approaches; Firstly, (the common one) - app passes data and a template to the template engine - template engine merges it together and passes back - app does as it pleases with data (sends it to client, caches it, fires it in an email - whatever) Secondly, (uncomment) [think modular] - app provides an api / gateway to views of data - template engine requests view(s) specified in template from app - template engine populates template modules with data sends output to I guess the first is template engine as a Util / Service - and the second is template engine as a Layer / App. There are pros and cons in each design, concentrating on the second design for now - this brings in a lot of scope which seems to fit well both practically and architecturally. The freedom to be able to specify in template that... this is template module latest posts, it is bound to the data view (or data provider) latest posts(8) whilst overall combining template (page) is comprised of modules x,y and z - here, here and here. ...really appeals to me; certainly in this scenario where you request (pull) from the application
Re: [PHP] templating engine options
Andrea Giammarchi wrote: Finally somebody mentioned XSL Transformations. Time is relative because as you need time to learn an API to produce quickly only after a while, thanks to knowledge and confidence, XSL is the same with the advantage that you transform a data structure, rather than work over raw programming language ( portability and re-usability ) I wrote a post in my blog about this long thread, hope you'll get some point: http://webreflection.blogspot.com/2009/05/template-engine-why-bother-xml-xslt.html Best Regards nice post, and nice choice! love xsl, nothing else comes close and if more of my fellow developers and designers used xsl I wouldn't be asking about template engines. IMHO I can't see any reason why _every_ developer (and app) doesn't use xsl. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
At 12:46 PM -0400 5/25/09, Robert Cummings wrote: I'm going to leave this discussion here since it's eating up too much of my time :) Cheers, Rob. Rob: It's always been my experience to listen when you talk. -- so -- when you find some time AND have the inclination, could you prepare a simple example of what you are saying? I know when I'm trying to explain a complex concept to someone I usually can reduce it down to the basics to demonstrate. As it is right now, I get some of what you are saying and then in the next line you lose me. Thanks for your time. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
At 8:13 PM +0100 5/25/09, Stuart wrote: I too have had an off-list discussion with Nathan on this topic, and a productive one at that. -Stuart Great! Now you guys are having a three-some without me. :-) While I wasn't getting it, I was trying. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
On 5/25/09 8:48 PM, Nathan Rixham nrix...@gmail.com wrote:
Sancar Saran wrote:
?php
$content = 'No Comments';
if(isset($comments) and is_array($comments) and count($comments) 0 ) {
$content = '';
foreach( $comments as $index = $comment ) : $content. = a href='.
$comment-link.'.$comment-title./a; endforeach;
}
?
h2Comments/h2
div id=comments
?=$content?
/div
index.php
ob_start();
require('template.php');
echo ob_get_clean();
I'm still do not understand for complex template system requirement.
I just _need_ the two abstracted.
php must have no html in it
html template must contain no php
i can achieve that separation in phplib using blocks, i.e blocks of template
that may be repeatedly replaced, hierarchically if so desired. presumably
smarty has something equivalent. but, naturally, this doesn't meet your
pull requirement.
hoever, i sometimes find that some mixing is inevitable. for example, if i
am listing music recordings but not using a table, just a list. my template
might be (leaving out the classes and ids. and humor me in my old-fashioned
tag preferences):
!-- BEGIN songblock --
lib{artist}/b, {disk} i{label}/i/li
!-- END songblock --
that works but if my database entry for a given disk has no information on
the label then the html output looks a but nasty:
libMika Miko/b, We Be Xuxa i/i/li
which sort of works but offends my sensibilities. since phplib doesn't have
a way to make a chunk of template conditional (other than with a block,
which would become a pita as you can imagine from the above), i sigh, shrug
and move the i/i in the conditional in the script. oh well. purity is
idealistic.
a possible solution would be to define macros in the template, maybe...
{MACRO:label=, i{label}/i}
that would give me an optional comma and get rid of the space if there's no
label data while keeping all html out of the script.
while this achieves the ideal of separation i'm not sure it's really more
practical than the impurity of having some html bits in the script. having
practical experience with just one approach i can only speak theoretically
of the other.
(btw: macros can in fact be done in phplib templates by putting each macro
in a template file of its own, but that doesn't sound too practical in the
long run, does it?)
on another different topic, i would make independence of the output language
a requirement of the template scheme. e.g. besides html, i use phplib
templates to generate plain text emails, sql files, json ajax responses,
whatever...
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
thanks for taking the trouble to write your requirements. it made interesting reading. i've questions on three points below... On 5/25/09 6:44 PM, Nathan Rixham nrix...@gmail.com wrote: XSL Templates are near perfect, built for the job, and very powerful - but time hasn't favoured them well; and until (if ever) a wide spread adoption happens something else needs to fill the gap. i don't know xsl well, but from what i read it seems to be about taking data from one xml document and putting it into another. that sounds reasonable except that the data that i want to combine with my template (either pushing it pulling) is in php variable state, not an xml document. however, it seems that one could write a php template class that takes xslt template files and data from the script? one thing i wasn't clear about with xsl is whether or not there's any output language dependence? could i write a template to produce an sql file, or an email in russian? Push vs Pull. ... The freedom to be able to specify in template that... this is template module latest posts, it is bound to the data view (or data provider) latest posts(8) whilst overall combining template (page) is comprised of modules x,y and z - here, here and here. ...really appeals to me; certainly in this scenario where you request (pull) from the application rather than make it all available. This way you only ever perform the business logic required for the information available. The counter part of making everything available incase it may be used is ridiculous (and makes me think coldfusion for some reason??). Architecturally this appears to be good - it's the presentation tier being a presentation tier, the logic tier knows nothing of the presentation tier and simply serves up what is requested. However thats only on the one side of the tier - on the other side we have a huge gaping hole where functionality should be (cache, compilation, delivery) etc, which would require another, as yet unknown layer (or 2). The abstraction and separation of concerns in this setup really appeals - but practically I'm not sure if the time spent implementing on a small or even medium sized project would be worth it. Still appeals massively though - pull makes more logical sense to me. Meanwhile, we have the first option, the way it's done, push the data - specify a template for that data and let template engine X do the merging. IMHO a clean, simple, lightweight implementation wouldn't be the hardest thing to make, and hundreds of apps are freely available all ready. i don't think i follow you. it seems you're saying that there would be some kind of an intermediate level of data representation that a script can be invoked to produce from which different templates can produce different outputs. but i can't see any difficulty in achieving similar modularity and reuse with available push template schemes and appropriate division of code among include files. one includable script generates the intermediate view while others use various templates to use it in output. so i think i'm missing something in your definition of pull. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
Tom Worster wrote: thanks for taking the trouble to write your requirements. it made interesting reading. and thanks for taking the time to read it! it was a big one. i've questions on three points below... On 5/25/09 6:44 PM, Nathan Rixham nrix...@gmail.com wrote: XSL Templates are near perfect, built for the job, and very powerful - but time hasn't favoured them well; and until (if ever) a wide spread adoption happens something else needs to fill the gap. i don't know xsl well, but from what i read it seems to be about taking data from one xml document and putting it into another. that sounds reasonable except that the data that i want to combine with my template (either pushing it pulling) is in php variable state, not an xml document. yes, transforming one document to another, using templates. works v well. php already implements xsl and its well supported using DOMDocuments and suchlike. however it's also supported on the client side in browser, which is a major selling point as you just send down the raw data formatted as xml and let the xsl stylesheets do all the work in the browser - so much weight off the server / app! to get the raw php data to xml is easy, there are already a tonne of array/object to xml converters available, and you can make one in a snap. however, it seems that one could write a php template class that takes xslt template files and data from the script? no need, http://php.net/xsl fully supported and uses DOMDocuments /DOMXpath the works. its all native to php 5 and above (and in php4 its http://php.net/xslt) one thing i wasn't clear about with xsl is whether or not there's any output language dependence? could i write a template to produce an sql file, or an email in russian? none that I know of - its a w3c recommended standard and imho one of the best written, practically everything you can think of is covered. if you have never tried xsl its really worth taking an hour or two out giving it a go, if you want some starting points just say. +xslt is supported by every major language, and most browsers like firefox, internet explorer, safari etc etc Push vs Pull. ... The freedom to be able to specify in template that... this is template module latest posts, it is bound to the data view (or data provider) latest posts(8) whilst overall combining template (page) is comprised of modules x,y and z - here, here and here. ...really appeals to me; certainly in this scenario where you request (pull) from the application rather than make it all available. This way you only ever perform the business logic required for the information available. The counter part of making everything available incase it may be used is ridiculous (and makes me think coldfusion for some reason??). Architecturally this appears to be good - it's the presentation tier being a presentation tier, the logic tier knows nothing of the presentation tier and simply serves up what is requested. However thats only on the one side of the tier - on the other side we have a huge gaping hole where functionality should be (cache, compilation, delivery) etc, which would require another, as yet unknown layer (or 2). The abstraction and separation of concerns in this setup really appeals - but practically I'm not sure if the time spent implementing on a small or even medium sized project would be worth it. Still appeals massively though - pull makes more logical sense to me. Meanwhile, we have the first option, the way it's done, push the data - specify a template for that data and let template engine X do the merging. IMHO a clean, simple, lightweight implementation wouldn't be the hardest thing to make, and hundreds of apps are freely available all ready. i don't think i follow you. it seems you're saying that there would be some kind of an intermediate level of data representation that a script can be invoked to produce from which different templates can produce different outputs. but i can't see any difficulty in achieving similar modularity and reuse with available push template schemes and appropriate division of code among include files. one includable script generates the intermediate view while others use various templates to use it in output. so i think i'm missing something in your definition of pull. yup, the modularity can be easily achieved using push, but with push you have to effectively send everything that can be needed to the template engine, then the template can either show all of it, some of it or whatever. but with this method of pull, the template would be pre-parsed to see what was required, then the app would generate and provide only what was needed for that specific template. Thus saving you generating a load of unneeded data incase the template might want to use it. clear? if not just say. regards! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
Tom Worster wrote:
On 5/25/09 8:48 PM, Nathan Rixham nrix...@gmail.com wrote:
Sancar Saran wrote:
?php
$content = 'No Comments';
if(isset($comments) and is_array($comments) and count($comments) 0 ) {
$content = '';
foreach( $comments as $index = $comment ) : $content. = a href='.
$comment-link.'.$comment-title./a; endforeach;
}
?
h2Comments/h2
div id=comments
?=$content?
/div
index.php
ob_start();
require('template.php');
echo ob_get_clean();
I'm still do not understand for complex template system requirement.
I just _need_ the two abstracted.
php must have no html in it
html template must contain no php
i can achieve that separation in phplib using blocks, i.e blocks of template
that may be repeatedly replaced, hierarchically if so desired. presumably
smarty has something equivalent. but, naturally, this doesn't meet your
pull requirement.
hoever, i sometimes find that some mixing is inevitable. for example, if i
am listing music recordings but not using a table, just a list. my template
might be (leaving out the classes and ids. and humor me in my old-fashioned
tag preferences):
!-- BEGIN songblock --
lib{artist}/b, {disk} i{label}/i/li
!-- END songblock --
that works but if my database entry for a given disk has no information on
the label then the html output looks a but nasty:
libMika Miko/b, We Be Xuxa i/i/li
which sort of works but offends my sensibilities. since phplib doesn't have
a way to make a chunk of template conditional (other than with a block,
which would become a pita as you can imagine from the above), i sigh, shrug
and move the i/i in the conditional in the script. oh well. purity is
idealistic.
a possible solution would be to define macros in the template, maybe...
{MACRO:label=, i{label}/i}
that would give me an optional comma and get rid of the space if there's no
label data while keeping all html out of the script.
while this achieves the ideal of separation i'm not sure it's really more
practical than the impurity of having some html bits in the script. having
practical experience with just one approach i can only speak theoretically
of the other.
(btw: macros can in fact be done in phplib templates by putting each macro
in a template file of its own, but that doesn't sound too practical in the
long run, does it?)
on another different topic, i would make independence of the output language
a requirement of the template scheme. e.g. besides html, i use phplib
templates to generate plain text emails, sql files, json ajax responses,
whatever...
you know you just reminded me of something..
for the past couple of years I've been working regularly on a huge
website which was made totally and completely terribly, everything about
it was just dire (worst code I've seen)
however, eating my above word here, I've just realised that the mini
custom template engine they used (whilst heavy and crap) actually
implemented pull!
in template they'd have
%user_stories_2%
which would actually mean run function user_stories_2 and place output
here - if the function wasn't defined it just replaced it with ''
(nothing).
so.. that is in fact pull, in a simple way - it doesn't cater for
allowing you to control the html output or suchlike, but the
optimization features and the general process was implemented.
damn I'm having a learning day/week. also noticed yesterday that a v v v
important and big project at the day job (which was going wrong and slow
for ages) has actually been designed wrong - it's implemented an
anemic domain model and a tonne of services, which completely kills
the point of using a domain model - couldn't put my finger on it before
but did today! also realised my own ORM was pants because I'd designed
it wrong using inheritance and created a mess of cross cutting concerns
which means the data layer can't be replaced easily - in short I've
implemented:
$country-saveOrUpdate();
but it should be:
Persistence::saveOrUpdate( $country );
(thus allowing the persistence layer to be swapped out without business
logic or domain model needing to be changed)
sigh but joy!
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
thanks for the pointers on xsl. i'll take a look. On 5/26/09 6:05 PM, Nathan Rixham nrix...@gmail.com wrote: it seems you're saying that there would be some kind of an intermediate level of data representation that a script can be invoked to produce from which different templates can produce different outputs. but i can't see any difficulty in achieving similar modularity and reuse with available push template schemes and appropriate division of code among include files. one includable script generates the intermediate view while others use various templates to use it in output. so i think i'm missing something in your definition of pull. yup, the modularity can be easily achieved using push, but with push you have to effectively send everything that can be needed to the template engine, then the template can either show all of it, some of it or whatever. but with this method of pull, the template would be pre-parsed to see what was required, then the app would generate and provide only what was needed for that specific template. Thus saving you generating a load of unneeded data incase the template might want to use it. clear? if not just say. it seems that you want to put certain parameters that configure the generation of the data that's to go into the output into the actual template files. if those parameters could instead be located in a php file somewhere then push would work as well. right? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
Hi, and then you have the joy of telling the client its 6 months work 6 months vs 1 day... Ka-Ching! :-) -- Richard Heyes HTML5 graphing: RGraph (www.rgraph.net - updated 23rd May) PHP mail: RMail (www.phpguru.org/rmail) PHP datagrid: RGrid (www.phpguru.org/rgrid) PHP Template: RTemplate (www.phpguru.org/rtemplate) PHP SMTP: http://www.phpguru.org/smtp -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
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. Aren't we already using a language (PHP) that parses for place holders for dynamic content within HTML tags? 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. Mike Completely agree. A year ago, we got a IBE project. It based TYPO3 and Templavolia. After completion, it slow like hell. Then some optimization, some TYPO3 tweak. And still slow like hell. Then I realize, we got more than 20 template pieces in a page. (it was something about the travel business you have to show lots of different travel options in landing page). Anyhow, then I found a f*ckin simple thing. ob_start(); require(template.php); $output. = ob_get_clean(); With converting templates to php and opcode cache compatibility (yes your template was a php file so it was stored in the memory). things was become blazingly fast. Then we covert entire thing to php based templates. Things become much more flexible and fast. Of course there where a thin red line. Do not put writer functions in the templates. Other than that. Perfect solution. Except one condition. Your designers must have php enabled. Regards Sancar -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
On Sun, 2009-05-24 at 21:26 +0100, Stuart wrote: 2009/5/24 Nathan Rixham nrix...@gmail.com: LinuxManMikeC wrote: On Sun, May 24, 2009 at 11:09 AM, tedd tedd.sperl...@gmail.com wrote: At 12:01 AM +0100 5/24/09, Nathan Rixham wrote: LinuxManMikeC wrote: I was recently researching template engines for a small in-house project, with a bias toward simple and lightweight. I found this interesting article in my search. I think its worth considering if you don't need all the bells and whistles of the big template engines. Simple and elegant. http://www.massassi.com/php/articles/template_engines/ cheers, it certainly is simple and elegant - however a bit too simple (specifically as it's in template php); gives me immediate visions of a wordpress template - and that's more than enough to scare me off! lol regards, nathan All: Anytime I see embedded style elements within html, that's more than ample warning to make me look elsewhere for the solution -- because IMO that's not a solution. I find it interesting that the articles states the separation of business logic from presentation but then combines content with presentation. I don't see any real gain here. My efforts are always trying to separate content from function and presentation. Make everything as unobtrusive as you can. Place styling in remote css, client-side javascript enhancements unobtrusively, and use server-side php/mysql to create secure and accurate function to generate the proper html and deliver desired content. I can understand someone wanting to simplify their work, but exchanging one problem for another doesn't cut it for me. Cheers, tedd 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. Aren't we already using a language (PHP) that parses for place holders for dynamic content within HTML tags? 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. Mike which is lovely, but then you realise you have business logic tied up in the presentation layer, and the client suddenly wants 3 different web based interfaces and a roaming flash version which calls the system via an api; and then you have the joy of telling the client its 6 months work and huge figure to rewrite the application layer to included an abstracted presentation layer, but it could have been avoided months ago with a days worth of work (or even an hours worth) and a different decision. Using PHP for templates has absolutely no bearing on whether your presentation is tied up with your logic or they are completely separate. Almost every project I work on day-to-day has at least 2 front ends, XHTML and an API. In addition several have mobile versions of the presentation layer. All of them use pure PHP to render output. all in though, hardly matters on a personal site, or a quick client job where, or a.. I guess there's a place for each technology and method; and we could throw scenarios around all night getting no where. IMHO there is only one scenario where using a template engine is justified and that's when you're working with people who insist on using it and you can't talk them round. The inverse can just as easily be argued. I've given good points before as to why a template engine can be useful, good points with no rebuff. Good points where PHP includes cannot compete. I'm not going to bother re-hashing them, since you only remember what you want to remember, similarly you only use what you want to use (and this applies to the PHP IS-A templating language dogma). I use both system where the case presents itself. In fact, I even have templates that create PHP files that use require(). 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
Re: [PHP] templating engine options
On Mon, 2009-05-25 at 09:39 +0100, Richard Heyes wrote: Hi, and then you have the joy of telling the client its 6 months work 6 months vs 1 day... Ka-Ching! :-) That's where your integrity is called into question. 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
Re: [PHP] templating engine options
Sometimes I'm the windshield and sometimes I'm the bug Ha ha! Love that!
Re: [PHP] templating engine options
That's where your integrity is called into question. What's that...? :-) -- Richard Heyes HTML5 graphing: RGraph (www.rgraph.net - updated 23rd May) PHP mail: RMail (www.phpguru.org/rmail) PHP datagrid: RGrid (www.phpguru.org/rgrid) PHP Template: RTemplate (www.phpguru.org/rtemplate) PHP SMTP: http://www.phpguru.org/smtp -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
On Mon, 2009-05-25 at 13:46 +0100, Richard Heyes wrote: That's where your integrity is called into question. What's that...? :-) One of the most important attributes a person can have. It is more important than the person's technical ability. :) 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
Re: [PHP] templating engine options
At 11:11 PM +0100 5/24/09, Nathan Rixham wrote: 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. You can wear the hat provided your head can do the deed. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
At 9:06 AM -0400 5/25/09, Robert Cummings wrote: On Mon, 2009-05-25 at 13:46 +0100, Richard Heyes wrote: That's where your integrity is called into question. What's that...? :-) One of the most important attributes a person can have. It is more important than the person's technical ability. :) Cheers, Rob -- I understand all too well. Fortunately, integrity has always gotten in the way when I saw easier ways to make a buck. I may not be as rich as some, but that's not that important. I sleep great, enjoy life, and have comfort in knowing I've never taken advantage of anyone. It's a good way to live. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
2009/5/25 Robert Cummings rob...@interjinn.com: On Sun, 2009-05-24 at 21:26 +0100, Stuart wrote: 2009/5/24 Nathan Rixham nrix...@gmail.com: LinuxManMikeC wrote: On Sun, May 24, 2009 at 11:09 AM, tedd tedd.sperl...@gmail.com wrote: At 12:01 AM +0100 5/24/09, Nathan Rixham wrote: LinuxManMikeC wrote: I was recently researching template engines for a small in-house project, with a bias toward simple and lightweight. I found this interesting article in my search. I think its worth considering if you don't need all the bells and whistles of the big template engines. Simple and elegant. http://www.massassi.com/php/articles/template_engines/ cheers, it certainly is simple and elegant - however a bit too simple (specifically as it's in template php); gives me immediate visions of a wordpress template - and that's more than enough to scare me off! lol regards, nathan All: Anytime I see embedded style elements within html, that's more than ample warning to make me look elsewhere for the solution -- because IMO that's not a solution. I find it interesting that the articles states the separation of business logic from presentation but then combines content with presentation. I don't see any real gain here. My efforts are always trying to separate content from function and presentation. Make everything as unobtrusive as you can. Place styling in remote css, client-side javascript enhancements unobtrusively, and use server-side php/mysql to create secure and accurate function to generate the proper html and deliver desired content. I can understand someone wanting to simplify their work, but exchanging one problem for another doesn't cut it for me. Cheers, tedd 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. Aren't we already using a language (PHP) that parses for place holders for dynamic content within HTML tags? 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. Mike which is lovely, but then you realise you have business logic tied up in the presentation layer, and the client suddenly wants 3 different web based interfaces and a roaming flash version which calls the system via an api; and then you have the joy of telling the client its 6 months work and huge figure to rewrite the application layer to included an abstracted presentation layer, but it could have been avoided months ago with a days worth of work (or even an hours worth) and a different decision. Using PHP for templates has absolutely no bearing on whether your presentation is tied up with your logic or they are completely separate. Almost every project I work on day-to-day has at least 2 front ends, XHTML and an API. In addition several have mobile versions of the presentation layer. All of them use pure PHP to render output. all in though, hardly matters on a personal site, or a quick client job where, or a.. I guess there's a place for each technology and method; and we could throw scenarios around all night getting no where. IMHO there is only one scenario where using a template engine is justified and that's when you're working with people who insist on using it and you can't talk them round. The inverse can just as easily be argued. I've given good points before as to why a template engine can be useful, good points with no rebuff. Good points where PHP includes cannot compete. I'm not going to bother re-hashing them, since you only remember what you want to remember, similarly you only use what you want to use (and this applies to the PHP IS-A templating language dogma). I use both system where the case presents itself. In fact, I even have templates that create PHP files that use require(). Have I done something to annoy you lately? You seem to be directing a lot of hostility my way recently. Just wondering. 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@lists.php.net/msg242954.html. Let's take a look
Re: [PHP] templating engine options
On 5/23/09 6:21 PM, Nathan Rixham nrix...@gmail.com wrote: Just a quick one, can anybody recommend any decent templating engines other than smarty. i started using phplib template in 2002. since then i've never bothered to revisit that choice. it may not qualify as an engine (all it does is juggle files and string values with regexp replacements) and probably isn't decent. but it offers sufficient flexibility for file, block and variable hierarchy and i find it meets my needs. i sometimes wonder if i am the only person still using it. it's in pear now: HTML_Template_PHPLIB -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
On 5/25/09 10:04 AM, Stuart stut...@gmail.com wrote:
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'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.
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.
revisiting the template question is interesting. i'm grateful for this
discussion.
as far as your question goes, with phplib-template, i'd do:
div class=option {option_class} ... /div
and in the php it is:
$t-setVar('option_class', empty($option_class) ? '' : $option_class);
or some equivalent code. $t is the template object.
the interesting part is trying to explain why i like this better than your
method. perhaps it's because it reduces the page assembly task to a sequence
of regexp replacements and i'm more comfortable with that than i am with
passing variable state to an included php file. why would i be? maybe i'm
more comfortable looking at the world as nothing but strings and in this
world, manipulating them is my job.
there's certainly something i like about not having any php in my html
templates but i can't say exactly what.
i don't think i could come up with better justifications for my current
methods without trying our the alternatives for a decent period.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
On Mon, 2009-05-25 at 15:04 +0100, Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: On Sun, 2009-05-24 at 21:26 +0100, Stuart wrote: 2009/5/24 Nathan Rixham nrix...@gmail.com: LinuxManMikeC wrote: On Sun, May 24, 2009 at 11:09 AM, tedd tedd.sperl...@gmail.com wrote: At 12:01 AM +0100 5/24/09, Nathan Rixham wrote: LinuxManMikeC wrote: I was recently researching template engines for a small in-house project, with a bias toward simple and lightweight. I found this interesting article in my search. I think its worth considering if you don't need all the bells and whistles of the big template engines. Simple and elegant. http://www.massassi.com/php/articles/template_engines/ cheers, it certainly is simple and elegant - however a bit too simple (specifically as it's in template php); gives me immediate visions of a wordpress template - and that's more than enough to scare me off! lol regards, nathan All: Anytime I see embedded style elements within html, that's more than ample warning to make me look elsewhere for the solution -- because IMO that's not a solution. I find it interesting that the articles states the separation of business logic from presentation but then combines content with presentation. I don't see any real gain here. My efforts are always trying to separate content from function and presentation. Make everything as unobtrusive as you can. Place styling in remote css, client-side javascript enhancements unobtrusively, and use server-side php/mysql to create secure and accurate function to generate the proper html and deliver desired content. I can understand someone wanting to simplify their work, but exchanging one problem for another doesn't cut it for me. Cheers, tedd 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. Aren't we already using a language (PHP) that parses for place holders for dynamic content within HTML tags? 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. Mike which is lovely, but then you realise you have business logic tied up in the presentation layer, and the client suddenly wants 3 different web based interfaces and a roaming flash version which calls the system via an api; and then you have the joy of telling the client its 6 months work and huge figure to rewrite the application layer to included an abstracted presentation layer, but it could have been avoided months ago with a days worth of work (or even an hours worth) and a different decision. Using PHP for templates has absolutely no bearing on whether your presentation is tied up with your logic or they are completely separate. Almost every project I work on day-to-day has at least 2 front ends, XHTML and an API. In addition several have mobile versions of the presentation layer. All of them use pure PHP to render output. all in though, hardly matters on a personal site, or a quick client job where, or a.. I guess there's a place for each technology and method; and we could throw scenarios around all night getting no where. IMHO there is only one scenario where using a template engine is justified and that's when you're working with people who insist on using it and you can't talk them round. The inverse can just as easily be argued. I've given good points before as to why a template engine can be useful, good points with no rebuff. Good points where PHP includes cannot compete. I'm not going to bother re-hashing them, since you only remember what you want to remember, similarly you only use what you want to use (and this applies to the PHP IS-A templating language dogma). I use both system where the case presents itself. In fact, I even have templates that create PHP files that use require(). 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
Re: [PHP] templating engine options
2009/5/25 Robert Cummings rob...@interjinn.com: On Mon, 2009-05-25 at 15:04 +0100, Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: On Sun, 2009-05-24 at 21:26 +0100, Stuart wrote: 2009/5/24 Nathan Rixham nrix...@gmail.com: LinuxManMikeC wrote: On Sun, May 24, 2009 at 11:09 AM, tedd tedd.sperl...@gmail.com wrote: At 12:01 AM +0100 5/24/09, Nathan Rixham wrote: LinuxManMikeC wrote: I was recently researching template engines for a small in-house project, with a bias toward simple and lightweight. I found this interesting article in my search. I think its worth considering if you don't need all the bells and whistles of the big template engines. Simple and elegant. http://www.massassi.com/php/articles/template_engines/ cheers, it certainly is simple and elegant - however a bit too simple (specifically as it's in template php); gives me immediate visions of a wordpress template - and that's more than enough to scare me off! lol regards, nathan All: Anytime I see embedded style elements within html, that's more than ample warning to make me look elsewhere for the solution -- because IMO that's not a solution. I find it interesting that the articles states the separation of business logic from presentation but then combines content with presentation. I don't see any real gain here. My efforts are always trying to separate content from function and presentation. Make everything as unobtrusive as you can. Place styling in remote css, client-side javascript enhancements unobtrusively, and use server-side php/mysql to create secure and accurate function to generate the proper html and deliver desired content. I can understand someone wanting to simplify their work, but exchanging one problem for another doesn't cut it for me. Cheers, tedd 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. Aren't we already using a language (PHP) that parses for place holders for dynamic content within HTML tags? 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. Mike which is lovely, but then you realise you have business logic tied up in the presentation layer, and the client suddenly wants 3 different web based interfaces and a roaming flash version which calls the system via an api; and then you have the joy of telling the client its 6 months work and huge figure to rewrite the application layer to included an abstracted presentation layer, but it could have been avoided months ago with a days worth of work (or even an hours worth) and a different decision. Using PHP for templates has absolutely no bearing on whether your presentation is tied up with your logic or they are completely separate. Almost every project I work on day-to-day has at least 2 front ends, XHTML and an API. In addition several have mobile versions of the presentation layer. All of them use pure PHP to render output. all in though, hardly matters on a personal site, or a quick client job where, or a.. I guess there's a place for each technology and method; and we could throw scenarios around all night getting no where. IMHO there is only one scenario where using a template engine is justified and that's when you're working with people who insist on using it and you can't talk them round. The inverse can just as easily be argued. I've given good points before as to why a template engine can be useful, good points with no rebuff. Good points where PHP includes cannot compete. I'm not going to bother re-hashing them, since you only remember what you want to remember, similarly you only use what you want to use (and this applies to the PHP IS-A templating language dogma). I use both system where the case presents itself. In fact, I even have templates that create PHP files that use require(). 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. Time of the month?
Re: [PHP] templating engine options
On Mon, 2009-05-25 at 16:31 +0100, Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: On Mon, 2009-05-25 at 15:04 +0100, Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: On Sun, 2009-05-24 at 21:26 +0100, Stuart wrote: 2009/5/24 Nathan Rixham nrix...@gmail.com: LinuxManMikeC wrote: On Sun, May 24, 2009 at 11:09 AM, tedd tedd.sperl...@gmail.com wrote: At 12:01 AM +0100 5/24/09, Nathan Rixham wrote: LinuxManMikeC wrote: I was recently researching template engines for a small in-house project, with a bias toward simple and lightweight. I found this interesting article in my search. I think its worth considering if you don't need all the bells and whistles of the big template engines. Simple and elegant. http://www.massassi.com/php/articles/template_engines/ cheers, it certainly is simple and elegant - however a bit too simple (specifically as it's in template php); gives me immediate visions of a wordpress template - and that's more than enough to scare me off! lol regards, nathan All: Anytime I see embedded style elements within html, that's more than ample warning to make me look elsewhere for the solution -- because IMO that's not a solution. I find it interesting that the articles states the separation of business logic from presentation but then combines content with presentation. I don't see any real gain here. My efforts are always trying to separate content from function and presentation. Make everything as unobtrusive as you can. Place styling in remote css, client-side javascript enhancements unobtrusively, and use server-side php/mysql to create secure and accurate function to generate the proper html and deliver desired content. I can understand someone wanting to simplify their work, but exchanging one problem for another doesn't cut it for me. Cheers, tedd 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. Aren't we already using a language (PHP) that parses for place holders for dynamic content within HTML tags? 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. Mike which is lovely, but then you realise you have business logic tied up in the presentation layer, and the client suddenly wants 3 different web based interfaces and a roaming flash version which calls the system via an api; and then you have the joy of telling the client its 6 months work and huge figure to rewrite the application layer to included an abstracted presentation layer, but it could have been avoided months ago with a days worth of work (or even an hours worth) and a different decision. Using PHP for templates has absolutely no bearing on whether your presentation is tied up with your logic or they are completely separate. Almost every project I work on day-to-day has at least 2 front ends, XHTML and an API. In addition several have mobile versions of the presentation layer. All of them use pure PHP to render output. all in though, hardly matters on a personal site, or a quick client job where, or a.. I guess there's a place for each technology and method; and we could throw scenarios around all night getting no where. IMHO there is only one scenario where using a template engine is justified and that's when you're working with people who insist on using it and you can't talk them round. The inverse can just as easily be argued. I've given good points before as to why a template engine can be useful, good points with no rebuff. Good points where PHP includes cannot compete. I'm not going to bother re-hashing them, since you only remember what you want to remember, similarly you only use what you want to use (and this applies to the PHP IS-A templating language dogma). I use both system where the case presents itself. In fact, I even have templates that create PHP files that use require(). 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
Re: [PHP] templating engine options
Robert Cummings wrote: On Mon, 2009-05-25 at 15:04 +0100, Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: 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@lists.php.net/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
Re: [PHP] templating engine options
Tom Worster wrote:
On 5/25/09 10:04 AM, Stuart stut...@gmail.com wrote:
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'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.
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.
revisiting the template question is interesting. i'm grateful for this
discussion.
as far as your question goes, with phplib-template, i'd do:
div class=option {option_class} ... /div
and in the php it is:
$t-setVar('option_class', empty($option_class) ? '' : $option_class);
or some equivalent code. $t is the template object.
that's like smarty too
div class=option {$option_class} ... /div
$s-assign('option_class', empty($option_class) ? '' : $option_class);
identical infact - like the way you moved the logic out of the template
in that example though :p
the interesting part is trying to explain why i like this better than your
method. perhaps it's because it reduces the page assembly task to a sequence
of regexp replacements and i'm more comfortable with that than i am with
passing variable state to an included php file. why would i be? maybe i'm
more comfortable looking at the world as nothing but strings and in this
world, manipulating them is my job.
there's certainly something i like about not having any php in my html
templates but i can't say exactly what.
snap - I think it's old sites and big nasty chunks monolithic code
intertwined that any fool or genius could break in a second, but
couldn't read for the life of them.
for this reason purely, a template engine is a good idea as it enforces
the good practise.
i don't think i could come up with better justifications for my current
methods without trying our the alternatives for a decent period.
I've played a lot of template things in the past - the only thing I
thought was great was xsl, but not many people (comparatively) know xsl.
Likewise with actionscript (flash/flex) but not even getting in tot
hat as it's way outside of scope.
i think the test will be the template engine, langauge, syntax, whatever
that can best hand this:
?php
if( isset($comments) is_array($comments) count($comments) 0 ) {
echo 'h2Comments/h2';
echo 'div id=comments';
foreach( $comments as $index = $comment ) {
echo 'a href=' . $comment-link . '';
echo $comment-title;
echo '/a';
}
echo '/div';
} else {
echo 'h3No Comments/h3';
}
?
without any php or escaping in and out of.
I know it's pre-hypertext processor and supposed to spit out html - but
I REALLY don't want to ever spit out a single html element from a php
script ever - nothing but raw data, a raw html template separately and
then *something* in the middle to make the magic happen.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
On Mon, 2009-05-25 at 16:58 +0100, Nathan Rixham wrote: Robert Cummings wrote: On Mon, 2009-05-25 at 15:04 +0100, Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: 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@lists.php.net/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) This was an example. Some sites don't need a CMS, or the CMS handles the content only and not the navigational elements. Also, I created my fraemwork years and years ago. 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?? Most template engines are push engines, you push the data into a template object which the template engine then expands. Mine can work this way, but it also works as a pull engine, where the data exists on the view and the template compiles to PHP that then pulls it off the view. 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. Yes, you can place the data wherever you want. I'm not sure what makes you think you can't. 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. (?) You're missing something here, project based custom tags are about centralization of formatting. To change the way the menus appear I would either change the CSS styling, or change the custom compiler. Either way, I then have the option to change all content across the site in a single location. * 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. Again we get to the issue of content developers. XSL is a language, and in many cases even more
Re: [PHP] templating engine options
2009/5/25 Robert Cummings rob...@interjinn.com: On Mon, 2009-05-25 at 16:31 +0100, Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: On Mon, 2009-05-25 at 15:04 +0100, Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: On Sun, 2009-05-24 at 21:26 +0100, Stuart wrote: 2009/5/24 Nathan Rixham nrix...@gmail.com: LinuxManMikeC wrote: On Sun, May 24, 2009 at 11:09 AM, tedd tedd.sperl...@gmail.com wrote: At 12:01 AM +0100 5/24/09, Nathan Rixham wrote: LinuxManMikeC wrote: I was recently researching template engines for a small in-house project, with a bias toward simple and lightweight. I found this interesting article in my search. I think its worth considering if you don't need all the bells and whistles of the big template engines. Simple and elegant. http://www.massassi.com/php/articles/template_engines/ cheers, it certainly is simple and elegant - however a bit too simple (specifically as it's in template php); gives me immediate visions of a wordpress template - and that's more than enough to scare me off! lol regards, nathan All: Anytime I see embedded style elements within html, that's more than ample warning to make me look elsewhere for the solution -- because IMO that's not a solution. I find it interesting that the articles states the separation of business logic from presentation but then combines content with presentation. I don't see any real gain here. My efforts are always trying to separate content from function and presentation. Make everything as unobtrusive as you can. Place styling in remote css, client-side javascript enhancements unobtrusively, and use server-side php/mysql to create secure and accurate function to generate the proper html and deliver desired content. I can understand someone wanting to simplify their work, but exchanging one problem for another doesn't cut it for me. Cheers, tedd 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. Aren't we already using a language (PHP) that parses for place holders for dynamic content within HTML tags? 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. Mike which is lovely, but then you realise you have business logic tied up in the presentation layer, and the client suddenly wants 3 different web based interfaces and a roaming flash version which calls the system via an api; and then you have the joy of telling the client its 6 months work and huge figure to rewrite the application layer to included an abstracted presentation layer, but it could have been avoided months ago with a days worth of work (or even an hours worth) and a different decision. Using PHP for templates has absolutely no bearing on whether your presentation is tied up with your logic or they are completely separate. Almost every project I work on day-to-day has at least 2 front ends, XHTML and an API. In addition several have mobile versions of the presentation layer. All of them use pure PHP to render output. all in though, hardly matters on a personal site, or a quick client job where, or a.. I guess there's a place for each technology and method; and we could throw scenarios around all night getting no where. IMHO there is only one scenario where using a template engine is justified and that's when you're working with people who insist on using it and you can't talk them round. The inverse can just as easily be argued. I've given good points before as to why a template engine can be useful, good points with no rebuff. Good points where PHP includes cannot compete. I'm not going to bother re-hashing them, since you only remember what you want to remember, similarly you only use what you want to use (and this applies to the PHP IS-A templating language dogma). I use both system where the case presents itself. In fact, I even have templates that create PHP files that use require(). Have I done something to annoy you lately? You seem to be directing a lot of hostility my way recently. Just
Re: [PHP] templating engine options
On Mon, 2009-05-25 at 19:56 +0100, Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: On Mon, 2009-05-25 at 16:31 +0100, Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: On Mon, 2009-05-25 at 15:04 +0100, Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: On Sun, 2009-05-24 at 21:26 +0100, Stuart wrote: 2009/5/24 Nathan Rixham nrix...@gmail.com: LinuxManMikeC wrote: On Sun, May 24, 2009 at 11:09 AM, tedd tedd.sperl...@gmail.com wrote: At 12:01 AM +0100 5/24/09, Nathan Rixham wrote: LinuxManMikeC wrote: I was recently researching template engines for a small in-house project, with a bias toward simple and lightweight. I found this interesting article in my search. I think its worth considering if you don't need all the bells and whistles of the big template engines. Simple and elegant. http://www.massassi.com/php/articles/template_engines/ cheers, it certainly is simple and elegant - however a bit too simple (specifically as it's in template php); gives me immediate visions of a wordpress template - and that's more than enough to scare me off! lol regards, nathan All: Anytime I see embedded style elements within html, that's more than ample warning to make me look elsewhere for the solution -- because IMO that's not a solution. I find it interesting that the articles states the separation of business logic from presentation but then combines content with presentation. I don't see any real gain here. My efforts are always trying to separate content from function and presentation. Make everything as unobtrusive as you can. Place styling in remote css, client-side javascript enhancements unobtrusively, and use server-side php/mysql to create secure and accurate function to generate the proper html and deliver desired content. I can understand someone wanting to simplify their work, but exchanging one problem for another doesn't cut it for me. Cheers, tedd 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. Aren't we already using a language (PHP) that parses for place holders for dynamic content within HTML tags? 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. Mike which is lovely, but then you realise you have business logic tied up in the presentation layer, and the client suddenly wants 3 different web based interfaces and a roaming flash version which calls the system via an api; and then you have the joy of telling the client its 6 months work and huge figure to rewrite the application layer to included an abstracted presentation layer, but it could have been avoided months ago with a days worth of work (or even an hours worth) and a different decision. Using PHP for templates has absolutely no bearing on whether your presentation is tied up with your logic or they are completely separate. Almost every project I work on day-to-day has at least 2 front ends, XHTML and an API. In addition several have mobile versions of the presentation layer. All of them use pure PHP to render output. all in though, hardly matters on a personal site, or a quick client job where, or a.. I guess there's a place for each technology and method; and we could throw scenarios around all night getting no where. IMHO there is only one scenario where using a template engine is justified and that's when you're working with people who insist on using it and you can't talk them round. The inverse can just as easily be argued. I've given good points before as to why a template engine can be useful, good points with no rebuff. Good points where PHP includes cannot compete. I'm not going to bother re-hashing them, since you only remember what you want to remember, similarly you only use what you want to use (and this applies to the PHP IS-A templating language dogma). I use both system
Re: [PHP] templating engine options
2009/5/25 Robert Cummings rob...@interjinn.com: On Mon, 2009-05-25 at 19:56 +0100, Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: On Mon, 2009-05-25 at 16:31 +0100, Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: On Mon, 2009-05-25 at 15:04 +0100, Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: On Sun, 2009-05-24 at 21:26 +0100, Stuart wrote: 2009/5/24 Nathan Rixham nrix...@gmail.com: LinuxManMikeC wrote: On Sun, May 24, 2009 at 11:09 AM, tedd tedd.sperl...@gmail.com wrote: At 12:01 AM +0100 5/24/09, Nathan Rixham wrote: LinuxManMikeC wrote: I was recently researching template engines for a small in-house project, with a bias toward simple and lightweight. I found this interesting article in my search. I think its worth considering if you don't need all the bells and whistles of the big template engines. Simple and elegant. http://www.massassi.com/php/articles/template_engines/ cheers, it certainly is simple and elegant - however a bit too simple (specifically as it's in template php); gives me immediate visions of a wordpress template - and that's more than enough to scare me off! lol regards, nathan All: Anytime I see embedded style elements within html, that's more than ample warning to make me look elsewhere for the solution -- because IMO that's not a solution. I find it interesting that the articles states the separation of business logic from presentation but then combines content with presentation. I don't see any real gain here. My efforts are always trying to separate content from function and presentation. Make everything as unobtrusive as you can. Place styling in remote css, client-side javascript enhancements unobtrusively, and use server-side php/mysql to create secure and accurate function to generate the proper html and deliver desired content. I can understand someone wanting to simplify their work, but exchanging one problem for another doesn't cut it for me. Cheers, tedd 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. Aren't we already using a language (PHP) that parses for place holders for dynamic content within HTML tags? 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. Mike which is lovely, but then you realise you have business logic tied up in the presentation layer, and the client suddenly wants 3 different web based interfaces and a roaming flash version which calls the system via an api; and then you have the joy of telling the client its 6 months work and huge figure to rewrite the application layer to included an abstracted presentation layer, but it could have been avoided months ago with a days worth of work (or even an hours worth) and a different decision. Using PHP for templates has absolutely no bearing on whether your presentation is tied up with your logic or they are completely separate. Almost every project I work on day-to-day has at least 2 front ends, XHTML and an API. In addition several have mobile versions of the presentation layer. All of them use pure PHP to render output. all in though, hardly matters on a personal site, or a quick client job where, or a.. I guess there's a place for each technology and method; and we could throw scenarios around all night getting no where. IMHO there is only one scenario where using a template engine is justified and that's when you're working with people who insist on using it and you can't talk them round. The inverse can just as easily be argued. I've given good points before as to why a template engine can be useful, good points with no rebuff. Good points where PHP includes cannot compete. I'm not going to bother re-hashing them, since you only remember what you want to remember, similarly you only use what you want to use (and this applies to the
Re: [PHP] templating engine options
Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: I continued the discussion with Nathan. I too have had an off-list discussion with Nathan on this topic, and a productive one at that. which would probably be a good time for me to step back in; having had a nice little inside in to both Robert and Stuarts template systems, and indeed way(s) of doing things. Also thanks to everybody else who made suggestions and gave input - it was all appreciated. I'm far from making a final decision, as I've decided to approach this by setting a few guidelines and a wishlist, then either finding / modifying something to do the job, or creating something from scratch. Both Rob and Stuarts systems were more in common than they may think, focus in both was on performance, and only making set data available to the templates (whether pushing or pulling). The syntax did differ though, and functionality aside this is probably one of the most important aspects (imho). Markup XML sits well with me (and most) because we are web developers and use it daily. PHP syntax also sits well because we also use it daily. The fact remains though that this feels like (and possibly is) a different job which requires something different. Both XHTML and PHP do their job well - just as ecma(java)script and css do theirs. However none of these technologies / languages are suited and dedicated to converting provided data in to specified output; specifically, and only, xhtml. XSL Templates are near perfect, built for the job, and very powerful - but time hasn't favoured them well; and until (if ever) a wide spread adoption happens something else needs to fill the gap. Template Specific Thoughts: Smarty, Stuarts Engine, Robs Engine, PHPLIB and many more had one common theme, they all limited the data available. My terminology of limited perhaps sounds wrong, so maybe make specified selected data available or provide access to the view will make more sense. Inline with layered and tiered application design this makes perfect sense; thus.. A template /should/ only be able to access the data made available to it, nothing else. Whether it requests the data or the data is provided is covered later. If it doesn't have all the data needed then this needs reviewed and the application needs changed to provide it. Not the template engine bastardized to accommodate a limited app. A template ~should~ have unique yet easy to understand syntax, something that complements xhtml and provides all needed functionality. (IMHO it should not be php syntax) A template engine must stick within it's role boundaries, it's not a cache engine, its not php, its not xhtml, its not for implementing functionality - it is simply and purely to do its job - take data, populate an xhtml template with it and return the result - nothing more, nothing less. Push vs Pull. This is a much bigger issue than I thought, and perhaps is the crux of the whole thing. I can see two clear approaches; Firstly, (the common one) - app passes data and a template to the template engine - template engine merges it together and passes back - app does as it pleases with data (sends it to client, caches it, fires it in an email - whatever) Secondly, (uncomment) [think modular] - app provides an api / gateway to views of data - template engine requests view(s) specified in template from app - template engine populates template modules with data sends output to I guess the first is template engine as a Util / Service - and the second is template engine as a Layer / App. There are pros and cons in each design, concentrating on the second design for now - this brings in a lot of scope which seems to fit well both practically and architecturally. The freedom to be able to specify in template that... this is template module latest posts, it is bound to the data view (or data provider) latest posts(8) whilst overall combining template (page) is comprised of modules x,y and z - here, here and here. ...really appeals to me; certainly in this scenario where you request (pull) from the application rather than make it all available. This way you only ever perform the business logic required for the information available. The counter part of making everything available incase it may be used is ridiculous (and makes me think coldfusion for some reason??). Architecturally this appears to be good - it's the presentation tier being a presentation tier, the logic tier knows nothing of the presentation tier and simply serves up what is requested. However thats only on the one side of the tier - on the other side we have a huge gaping hole where functionality should be (cache, compilation, delivery) etc, which would require another, as yet unknown layer (or 2). The abstraction and separation of concerns in this setup really appeals - but practically I'm not sure if the time spent implementing on a small or even
Re: [PHP] templating engine options
On Tuesday 26 May 2009 01:44:43 am Nathan Rixham wrote: Stuart wrote: 2009/5/25 Robert Cummings rob...@interjinn.com: I continued the discussion with Nathan. I too have had an off-list discussion with Nathan on this topic, and a productive one at that. which would probably be a good time for me to step back in; having had a nice little inside in to both Robert and Stuarts template systems, and indeed way(s) of doing things. Also thanks to everybody else who made suggestions and gave input - it was all appreciated. I'm far from making a final decision, as I've decided to approach this by setting a few guidelines and a wishlist, then either finding / modifying something to do the job, or creating something from scratch. Both Rob and Stuarts systems were more in common than they may think, focus in both was on performance, and only making set data available to the templates (whether pushing or pulling). The syntax did differ though, and functionality aside this is probably one of the most important aspects (imho). Markup XML sits well with me (and most) because we are web developers and use it daily. PHP syntax also sits well because we also use it daily. The fact remains though that this feels like (and possibly is) a different job which requires something different. Both XHTML and PHP do their job well - just as ecma(java)script and css do theirs. However none of these technologies / languages are suited and dedicated to converting provided data in to specified output; specifically, and only, xhtml. XSL Templates are near perfect, built for the job, and very powerful - but time hasn't favoured them well; and until (if ever) a wide spread adoption happens something else needs to fill the gap. Template Specific Thoughts: Smarty, Stuarts Engine, Robs Engine, PHPLIB and many more had one common theme, they all limited the data available. My terminology of limited perhaps sounds wrong, so maybe make specified selected data available or provide access to the view will make more sense. Inline with layered and tiered application design this makes perfect sense; thus.. A template /should/ only be able to access the data made available to it, nothing else. Whether it requests the data or the data is provided is covered later. If it doesn't have all the data needed then this needs reviewed and the application needs changed to provide it. Not the template engine bastardized to accommodate a limited app. A template ~should~ have unique yet easy to understand syntax, something that complements xhtml and provides all needed functionality. (IMHO it should not be php syntax) A template engine must stick within it's role boundaries, it's not a cache engine, its not php, its not xhtml, its not for implementing functionality - it is simply and purely to do its job - take data, populate an xhtml template with it and return the result - nothing more, nothing less. Push vs Pull. This is a much bigger issue than I thought, and perhaps is the crux of the whole thing. I can see two clear approaches; Firstly, (the common one) - app passes data and a template to the template engine - template engine merges it together and passes back - app does as it pleases with data (sends it to client, caches it, fires it in an email - whatever) Secondly, (uncomment) [think modular] - app provides an api / gateway to views of data - template engine requests view(s) specified in template from app - template engine populates template modules with data sends output to I guess the first is template engine as a Util / Service - and the second is template engine as a Layer / App. There are pros and cons in each design, concentrating on the second design for now - this brings in a lot of scope which seems to fit well both practically and architecturally. The freedom to be able to specify in template that... this is template module latest posts, it is bound to the data view (or data provider) latest posts(8) whilst overall combining template (page) is comprised of modules x,y and z - here, here and here. ...really appeals to me; certainly in this scenario where you request (pull) from the application rather than make it all available. This way you only ever perform the business logic required for the information available. The counter part of making everything available incase it may be used is ridiculous (and makes me think coldfusion for some reason??). Architecturally this appears to be good - it's the presentation tier being a presentation tier, the logic tier knows nothing of the presentation tier and simply serves up what is requested. However thats only on the one side of the tier - on the other side we have a huge gaping hole where functionality should be (cache, compilation, delivery) etc, which would require another, as yet unknown layer (or 2). The abstraction and separation of concerns in this setup really appeals - but
Re: [PHP] templating engine options
Sancar Saran wrote:
?php
$content = 'No Comments';
if(isset($comments) and is_array($comments) and count($comments) 0 ) {
$content = '';
foreach( $comments as $index = $comment ) : $content. = a href='.
$comment-link.'.$comment-title./a; endforeach;
}
?
h2Comments/h2
div id=comments
?=$content?
/div
index.php
ob_start();
require('template.php');
echo ob_get_clean();
I'm still do not understand for complex template system requirement.
I just _need_ the two abstracted.
php must have no html in it
html template must contain no php
Why it have to be very complex system.
Large data array, some conditions, lots of loops, and What else ?
http://www.flytag.de/
http://urlaub-finder.de/
http://airportdirekt.de/
All same system. With different css designs.
yup, did this myself for a long time; here is some very old code I
used to use!
newCage();
$content = cage(include $file);
function newCage() {
ob_start();
}
function cage() {
$includeOutput = ob_get_contents();
ob_end_clean();
return $includeOutput;
}
lol
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
At 12:01 AM +0100 5/24/09, Nathan Rixham wrote: LinuxManMikeC wrote: I was recently researching template engines for a small in-house project, with a bias toward simple and lightweight. I found this interesting article in my search. I think its worth considering if you don't need all the bells and whistles of the big template engines. Simple and elegant. http://www.massassi.com/php/articles/template_engines/ cheers, it certainly is simple and elegant - however a bit too simple (specifically as it's in template php); gives me immediate visions of a wordpress template - and that's more than enough to scare me off! lol regards, nathan All: Anytime I see embedded style elements within html, that's more than ample warning to make me look elsewhere for the solution -- because IMO that's not a solution. I find it interesting that the articles states the separation of business logic from presentation but then combines content with presentation. I don't see any real gain here. My efforts are always trying to separate content from function and presentation. Make everything as unobtrusive as you can. Place styling in remote css, client-side javascript enhancements unobtrusively, and use server-side php/mysql to create secure and accurate function to generate the proper html and deliver desired content. I can understand someone wanting to simplify their work, but exchanging one problem for another doesn't cut it for me. Cheers, tedd -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
i use smarty (a templating engine) for two important reasons... 1. in most of my projects, templates are designed by a third party and i dont want them to access all my php variables. 2. smarty is meant to do html coding and in many cases i can get the job done in single sentence, while it takes 3-4 lines for PHP. why smarty? i dnt find a different template engine with compiling, catching, debugging features, and a vast plugin repository(and i can write one whenever required) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
... For a long time I used require(), simply because I worked in an environment where the web people could either cope with PHP or were programmers. But then I succumbed to the lure and wrote RTemplate (http://www.phpguru.org/rtemplate) - a simple caching template doobry. And now I still use require()... :-/ -- Richard Heyes HTML5 graphing: RGraph (www.rgraph.net) PHP mail: RMail (www.phpguru.org/rmail) PHP datagrid: RGrid (www.phpguru.org/rgrid) PHP Template: RTemplate (www.phpguru.org/rtemplate) PHP SMTP: http://www.phpguru.org/smtp -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
On Sun, May 24, 2009 at 11:09 AM, tedd tedd.sperl...@gmail.com wrote: At 12:01 AM +0100 5/24/09, Nathan Rixham wrote: LinuxManMikeC wrote: I was recently researching template engines for a small in-house project, with a bias toward simple and lightweight. I found this interesting article in my search. I think its worth considering if you don't need all the bells and whistles of the big template engines. Simple and elegant. http://www.massassi.com/php/articles/template_engines/ cheers, it certainly is simple and elegant - however a bit too simple (specifically as it's in template php); gives me immediate visions of a wordpress template - and that's more than enough to scare me off! lol regards, nathan All: Anytime I see embedded style elements within html, that's more than ample warning to make me look elsewhere for the solution -- because IMO that's not a solution. I find it interesting that the articles states the separation of business logic from presentation but then combines content with presentation. I don't see any real gain here. My efforts are always trying to separate content from function and presentation. Make everything as unobtrusive as you can. Place styling in remote css, client-side javascript enhancements unobtrusively, and use server-side php/mysql to create secure and accurate function to generate the proper html and deliver desired content. I can understand someone wanting to simplify their work, but exchanging one problem for another doesn't cut it for me. Cheers, tedd 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. Aren't we already using a language (PHP) that parses for place holders for dynamic content within HTML tags? 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. Mike -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
2009/5/23 Nathan Rixham nrix...@gmail.com: Hi All, Just a quick one, can anybody recommend any decent templating engines other than smarty. I've got no problem with smarty and it does the job - but if there is something newer and lighter out there that I'm missing then I'd be a fool not to at least consider it! can't be part of a framework, (or if it is easily extracted with no framework dependencies), and not xslt (love xslt, but not many designers do!). PHP - this is what it was created for. I've never seen or heard of a good reason to add pointless guff like a templating engine. -Stuart -- http://stut.net/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
Stuart wrote: 2009/5/24 Nathan Rixham nrix...@gmail.com: LinuxManMikeC wrote: On Sun, May 24, 2009 at 11:09 AM, tedd tedd.sperl...@gmail.com wrote: At 12:01 AM +0100 5/24/09, Nathan Rixham wrote: LinuxManMikeC wrote: I was recently researching template engines for a small in-house project, with a bias toward simple and lightweight. I found this interesting article in my search. I think its worth considering if you don't need all the bells and whistles of the big template engines. Simple and elegant. http://www.massassi.com/php/articles/template_engines/ cheers, it certainly is simple and elegant - however a bit too simple (specifically as it's in template php); gives me immediate visions of a wordpress template - and that's more than enough to scare me off! lol regards, nathan All: Anytime I see embedded style elements within html, that's more than ample warning to make me look elsewhere for the solution -- because IMO that's not a solution. I find it interesting that the articles states the separation of business logic from presentation but then combines content with presentation. I don't see any real gain here. My efforts are always trying to separate content from function and presentation. Make everything as unobtrusive as you can. Place styling in remote css, client-side javascript enhancements unobtrusively, and use server-side php/mysql to create secure and accurate function to generate the proper html and deliver desired content. I can understand someone wanting to simplify their work, but exchanging one problem for another doesn't cut it for me. Cheers, tedd 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. Aren't we already using a language (PHP) that parses for place holders for dynamic content within HTML tags? 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. Mike which is lovely, but then you realise you have business logic tied up in the presentation layer, and the client suddenly wants 3 different web based interfaces and a roaming flash version which calls the system via an api; and then you have the joy of telling the client its 6 months work and huge figure to rewrite the application layer to included an abstracted presentation layer, but it could have been avoided months ago with a days worth of work (or even an hours worth) and a different decision. Using PHP for templates has absolutely no bearing on whether your presentation is tied up with your logic or they are completely separate. Almost every project I work on day-to-day has at least 2 front ends, XHTML and an API. In addition several have mobile versions of the presentation layer. All of them use pure PHP to render output. all in though, hardly matters on a personal site, or a quick client job where, or a.. I guess there's a place for each technology and method; and we could throw scenarios around all night getting no where. IMHO there is only one scenario where using a template engine is justified and that's when you're working with people who insist on using it and you can't talk them round. -Stuart and now I'm questioning myself - not on the client scenario based decisions - but on my own personal projects and things only I work on.. why do I use a template engine? habit? some old logical decision I made based on abstraction which somehow ruled out php (the pre-hypertext processor) - I fear I may have implemented some false logic at somepoint a few years ago and never gave it any more sense. a risk of sounding like a complete dick - i wish I could unit test myself and give myself a peer review every now and then. might hire somebody to question every statement it make - (for some reason Mr Sperling comes to mind - question me!) regards -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
At 9:43 PM +0100 5/24/09, Nathan Rixham wrote: and now I'm questioning myself - not on the client scenario based decisions - but on my own personal projects and things only I work on.. why do I use a template engine? habit? some old logical decision I made based on abstraction which somehow ruled out php (the pre-hypertext processor) - I fear I may have implemented some false logic at somepoint a few years ago and never gave it any more sense. a risk of sounding like a complete dick - i wish I could unit test myself and give myself a peer review every now and then. might hire somebody to question every statement it make - (for some reason Mr Sperling comes to mind - question me!) I'm not sure what my father has to do with this (Mr Sperling), but while I (tedd) may be good at understanding the basics of separation of languages (many years of css), I am way below your understand of how to use them. I also consider it a real compliment that you might seek out my advice on such things. As for peer review, that's what I get every time I make a post. Sometimes I'm the windshield and sometimes I'm the bug, but I always learn -- even when I make an ass of myself. Cheers, tedd PS: Your post about Eclipse got me trying php/eclipse again. My only problem is that I am used to having access to the remote (host) file system and then picking/choosing what scripts I want to work on. Eclipse is like a paradigm shift for me. Outside of working a single project, I can't get my mind around how it uploads and runs remote projects. I'll get there. -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
tedd wrote: At 9:43 PM +0100 5/24/09, Nathan Rixham wrote: and now I'm questioning myself - not on the client scenario based decisions - but on my own personal projects and things only I work on.. why do I use a template engine? habit? some old logical decision I made based on abstraction which somehow ruled out php (the pre-hypertext processor) - I fear I may have implemented some false logic at somepoint a few years ago and never gave it any more sense. a risk of sounding like a complete dick - i wish I could unit test myself and give myself a peer review every now and then. might hire somebody to question every statement it make - (for some reason Mr Sperling comes to mind - question me!) I'm not sure what my father has to do with this (Mr Sperling), but while I (tedd) may be good at understanding the basics of separation of languages (many years of css), I am way below your understand of how to use them. I also consider it a real compliment that you might seek out my advice on such things. As for peer review, that's what I get every time I make a post. Sometimes I'm the windshield and sometimes I'm the bug, but I always learn -- even when I make an ass of myself. Cheers, tedd PS: Your post about Eclipse got me trying php/eclipse again. My only problem is that I am used to having access to the remote (host) file system and then picking/choosing what scripts I want to work on. Eclipse is like a paradigm shift for me. Outside of working a single project, I can't get my mind around how it uploads and runs remote projects. I'll get there. it's up to you how you organise you're workflow - don't get confused with svn mate, you can completely ignore it, set your workspace to be the root of your normal sites folder and edit the files in eclipse then simply ftp them up and down as normal :) feel free to completely forget all the project template stuff, unit testing, svn, phpdoc and all of that - ultimately eclipse is better than a text editor and beats dreamweaver code view hands down - that's without using even basic tools like the debugger. regards! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
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. 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. 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. Cheers, tedd * Granted, sometimes I have clients who won't allow me to do what's best for them because they know programming much better than I -- they just have me program because they don't want to waste their time doing such low level stuff. Hey, it pays the same as the high level stuff. :-) -- --- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
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
Re: [PHP] templating engine options
On Sat, May 23, 2009 at 4:21 PM, Nathan Rixham nrix...@gmail.com wrote: Hi All, Just a quick one, can anybody recommend any decent templating engines other than smarty. I've got no problem with smarty and it does the job - but if there is something newer and lighter out there that I'm missing then I'd be a fool not to at least consider it! can't be part of a framework, (or if it is easily extracted with no framework dependencies), and not xslt (love xslt, but not many designers do!). many regards, Nathan -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php I was recently researching template engines for a small in-house project, with a bias toward simple and lightweight. I found this interesting article in my search. I think its worth considering if you don't need all the bells and whistles of the big template engines. Simple and elegant. http://www.massassi.com/php/articles/template_engines/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
On Sat, 2009-05-23 at 23:21 +0100, Nathan Rixham wrote: Hi All, Just a quick one, can anybody recommend any decent templating engines other than smarty. I've got no problem with smarty and it does the job - but if there is something newer and lighter out there that I'm missing then I'd be a fool not to at least consider it! can't be part of a framework, (or if it is easily extracted with no framework dependencies), and not xslt (love xslt, but not many designers do!). eZ Components Use just the template component http://ezcomponents.org Kevin http://phpro.org -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating engine options
Kevin Waterson wrote: On Sat, 2009-05-23 at 23:21 +0100, Nathan Rixham wrote: Hi All, Just a quick one, can anybody recommend any decent templating engines other than smarty. I've got no problem with smarty and it does the job - but if there is something newer and lighter out there that I'm missing then I'd be a fool not to at least consider it! can't be part of a framework, (or if it is easily extracted with no framework dependencies), and not xslt (love xslt, but not many designers do!). eZ Components Use just the template component http://ezcomponents.org Kevin http://phpro.org cheers for that kevin, does look good; kind of smarty++ - will need to give it a try out! -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating
I just wanted to add that Richards technique is a good way to go.
I often use something very similar, the only difference being that I
make the head() and foot() function methods in class (an instance
of the class being created by the global include file for the given site
e.g:
class Page
{
function Page() { /* setup page */ }
function head() { /* show header */ }
function foot() { /* show footer */ }
}
I find that the class has all the benefits of the
structure Richard proposed with the added benefit (my opinion :-)
that you can store page related data in the global 'Page' object
as and when you need to and use that data when you do the output...
the net result means you may probably end up polluting the global
space with less variables.
Richard Lynch wrote:
On Thu, June 22, 2006 6:10 am, Ryan A wrote:
He just needs maybe 5 template
pages, same pages, different color.
For something THIS simple, I truly believe you are Better Off (tm)
with a simple head() and foot() function in a globals.inc file:
function head($title = My Site, $bgcolor = '#ff'){
?
!DOCTYPE ...
html
head
title?php echo $title?/title
/head
body bgcolor=?php echo $bgcolor?
?php
}
function foot(){
?
/body
/html
?php
}
?
Your header and footer are now in one template-like file which makes
it easy to match up tags.
And the 5 pages will look like:
?php
require 'globals.inc';
head('Page One', '#fcfcfc');
?
pPage One specific content here/p
?php
foot();
?
The reason I prefer this to header/footer includes, is that it's too
easy to mess up closing tags in footer/header out of sync with
separate files, but with one file, they're right there and a decent
HTML editor will pick them out for you.
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating
Hi Rich, Thanks for replying. He just needs maybe 5 template pages, same pages, different color. For something THIS simple, I truly believe you are Better Off (tm) with a simple head() and foot() function in a globals.inc file: Sorry, dont know where my brain was that day, what I meant was he needs like 5 template pages, with 5 dynamic spots on them (meaning that php will generate the content for these 5 spots and they are the parts that will be constantly changing depending on the page), and identical pages will be used to serve people with other languages except with a color difference (meaning different colored graphics, not just css) My fault for not explaining it better, sorry. Thanks, Ryan -- - The faulty interface lies between the chair and the keyboard. - Creativity is great, but plagiarism is faster! - Smile, everyone loves a moron. :-) __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating
At 9:57 PM -0500 6/22/06, Richard Lynch wrote: On Thu, June 22, 2006 7:23 pm, tedd wrote: -snip- body bgcolor=?php echo $bgcolor? Well... I prefer to separate the header and footer into two files and load them as needed in my web page. In addition, I would most certainly remove ALL attribute stuff that could/should be controlled by css out of html and php and into a css file. Putting the stuff into CSS is fine with what I did -- I do that all the time. I'm not criticizing. You may do whatever is your custom, but the attribute bgcolor for the body tag is better served in a css format. The whole point of css is to remove attributes from markup. I realize that people have their own ways that work better for them -- nothing wrong with that. And, if you need (for whatever reason) to change the background color of a body tag programmatically, then your way works for you. But for me, I would move it to embedded css -- that way I know where all attributes are (embedded or in a css file) and don't have to go through my markup trying to find why some presentational element isn't working correctly. In between the two body/body tags it's pretty simple to manage the html and keep track of div's. I never have a header or footer that goes beyond the body tags -- so even if there is NO html in between, I still have a valid page. The header and footer frequently contain the logo, site nav, possibly a site-wide context-sensitive nav, maybe a mailing list signup, and then copyright and so on. There's no need to be doing a bunch of include files to hit the HD (expensive) separately for each. The need is in organization. We don't write code in machine language, which would be faster. We write it in whatever language (organization) is our custom, which is expensive. Everything has a price. But, I would guess that the hit to the HD for loading a few extra, but shorter, files would be very minimal as compared to loading one larger file per page. After all, we use includes in php the same way and I don't hear people saying Don't use includes because of the extra hits to the HD -- do we? We do it for organization. It's also all too easy to forget one of the include files on one of the pages and never even notice it... I've done it too many times when I went back to add some fluff page to some ancient site. :-( That's the housekeeping I spoke of. We all have different techniques and manners of organization. Mine works for me. If I forget an include, then that page would simply be missing that feature, but the page would still work and validate. A reasonable amount of the all the same stuff in head() handles all that, and the footer, in one HD seek, with matching tags between head() and foot() in a single file. It's also very easy to call foot() in an error condition to be sure all tags balance. The tags in my includes always balance because I design them that way -- again, that's my organizational manner. The only includes that don't balance are my header and footer includes -- but the header ends, and the footer starts, with a body tag. In short, my organization technique works and I don't have the problems you describe. Cheers, tedd -- http://sperling.com http://ancientstones.com http://earthstones.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating
At 3:37 AM -0700 6/23/06, Ryan A wrote:
Hi Rich,
Thanks for replying.
He just needs maybe 5 template
pages, same pages, different color.
For something THIS simple, I truly believe you are
Better Off (tm)
with a simple head() and foot() function in a
globals.inc file:
Sorry, dont know where my brain was that day, what I
meant was he needs like 5 template pages, with 5
dynamic spots on them (meaning that php will
generate the content for these 5 spots and they are
the parts that will be constantly changing depending
on the page), and identical pages will be used to
serve people with other languages except with a color
difference (meaning different colored graphics, not
just css)
My fault for not explaining it better, sorry.
Thanks,
Ryan
Then within each of the dynamic spots run your php.
?php include('spot1.php');?
tedd
--
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating
Hey Tedd,
He just needs maybe 5 template
pages, same pages, different color.
For something THIS simple, I truly believe you
are
Better Off (tm)
with a simple head() and foot() function in a
globals.inc file:
Sorry, dont know where my brain was that day, what
I
meant was he needs like 5 template pages, with 5
dynamic spots on them (meaning that php will
generate the content for these 5 spots and they are
the parts that will be constantly changing
depending
on the page), and identical pages will be used to
serve people with other languages except with a
color
difference (meaning different colored graphics, not
just css)
Then within each of the dynamic spots run your
php.
?php include('spot1.php');?
That would work of course, but the guys he is working
with know pretty much zero about programming and are
mostly designers, by having a template tag
eg:
{{left_menu}} {{right_menu}} {{content_here}}
{{head_img}}
in a plain html page, they will get the idea much
better and they can move the menu around or whatever
if for whatever reason my pal is no longer with the
company.
Thats why was thinking of a simple
str_replace(array,array)
Cheers!
Ryan
--
- The faulty interface lies between the chair and the keyboard.
- Creativity is great, but plagiarism is faster!
- Smile, everyone loves a moron. :-)
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] templating
Ryan,
I would still recommend Smarty.
It can be as big as you like, but it can also be very simple to set up and
maintain. It has the features should your friend decide to expand his usage
in the future. If you opt now for something with limited features and later
decide to step beyond them, you'll be faced with making another major change
then.
Just my 2p worth.
George in Oxford
-Original Message-
From: Ryan A [mailto:[EMAIL PROTECTED]
Sent: 22 June 2006 12:10 pm
To: php php
Subject: [PHP] templating
Hi,
A pal of mine needed some help on his project, he is
using a header and footer file to template his
project... but its gotten a bit complicated as he has
a few dynamic parts in the header and footer files, so
I told him to go with a proper templating method of
templating the whole page rather than includ()ing the
top and bottom.
After having a better look at his scripts, I am just
not sure if something big (like SMARTY for instance)
would be good for him. He just needs maybe 5 template
pages, same pages, different color.
Searching google I see literally hundreds of
templating solutions can anyone recommend a simple
one or should I tell him to just use str_replace() for
tags like: {{menu_here}} {{header_here} etc?
Something like SMARTY would be like using a nuke to
kill a fly (IMHO) esp since this project will not
expand to anything much bigger or complicated.
Thanks!
Ryan
--
- The faulty interface lies between the chair and the keyboard.
- Creativity is great, but plagiarism is faster!
- Smile, everyone loves a moron. :-)
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating
Ryan A wrote:
Hi,
A pal of mine needed some help on his project, he is
using a header and footer file to template his
project... but its gotten a bit complicated as he has
a few dynamic parts in the header and footer files, so
I told him to go with a proper templating method of
templating the whole page rather than includ()ing the
top and bottom.
This somewhat a religious issue for some, but my personal opinion is
that PHP is often very good at being a simple template system. Just
assign your variables beforehand, and display them with the ?= $var ?
tag. (I do this with entire pages, split up into chunks for various
parts of content.)
I.e. template_head.php:
?php
html
head
title?= $page_title ?
?php foreach ($css_files as $fn) { ?
style type=text/css@import ?= $fn ?;/style
?php } /* end foreach ($js_files) */ ?
/head
body
?
etc...
Then your page would look like:
?php
/* Assign some variables */
...
include('template_head.php');
/* A little workhorse code, assign some more variables */
...
include('template_content1.php');
/* Assign even more variables */
...
include('template_foot.php');
After having a better look at his scripts, I am just
not sure if something big (like SMARTY for instance)
would be good for him. He just needs maybe 5 template
pages, same pages, different color.
Smarty is also excellent. (I still prefer pure PHP though. :-)
Searching google I see literally hundreds of
templating solutions can anyone recommend a simple
one or should I tell him to just use str_replace() for
tags like: {{menu_here}} {{header_here} etc?
Something like SMARTY would be like using a nuke to
kill a fly (IMHO) esp since this project will not
expand to anything much bigger or complicated.
Why kill performance when you don't have to?
jon
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating
At 08:10 AM 6/22/2006, Ryan A wrote:
Hi,
A pal of mine needed some help on his project, he is
using a header and footer file to template his
project... but its gotten a bit complicated as he has
a few dynamic parts in the header and footer files, so
I told him to go with a proper templating method of
templating the whole page rather than includ()ing the
top and bottom.
After having a better look at his scripts, I am just
not sure if something big (like SMARTY for instance)
would be good for him. He just needs maybe 5 template
pages, same pages, different color.
Searching google I see literally hundreds of
templating solutions can anyone recommend a simple
one or should I tell him to just use str_replace() for
tags like: {{menu_here}} {{header_here} etc?
Something like SMARTY would be like using a nuke to
kill a fly (IMHO) esp since this project will not
expand to anything much bigger or complicated.
Thanks!
Ryan
Ryan,
Don't forget, PHP itself is a templating language. Just do a standard page,
with includes for headers and footers, menus, and content.
If he wants to change colour, then load a different stylesheet for a given
page or content section.
This way he can use the tool that's right in front of him, he's not adding
another layer, he does not have to learn another language - the template
system written in PHP, and he hones his PHP skills.
Whew! Hope this is helpful.
Regards - Miles
--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.1.394 / Virus Database: 268.9.2/372 - Release Date: 6/21/2006
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating
On 22/06/06, Miles Thompson [EMAIL PROTECTED] wrote:
At 08:10 AM 6/22/2006, Ryan A wrote:Hi,A pal of mine needed some help on his project, he isusing a header and footer file to template hisproject... but its gotten a bit complicated as he has
a few dynamic parts in the header and footer files, soI told him to go with a proper templating method oftemplating the whole page rather than includ()ing thetop and bottom.After having a better look at his scripts, I am just
not sure if something big (like SMARTY for instance)would be good for him. He just needs maybe 5 templatepages, same pages, different color.Searching google I see literally hundreds of
templating solutions can anyone recommend a simpleone or should I tell him to just use str_replace() fortags like: {{menu_here}} {{header_here} etc?Something like SMARTY would be like using a nuke to
kill a fly (IMHO) esp since this project will notexpand to anything much bigger or complicated.Thanks!RyanI agree with Ryan - here is an example of a simple template I am using on a project at the moment. Stylesheets are used to control look and feel and the body tag is assigned a class so that different pages can use different layout elements. Hope this helps.
-- http://www.web-buddha.co.uk http://www.projectkarma.co.uk
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating
IMHO I would go with Smarty as it has excellent documentation and
would fit almost anything that the project would require. I also
think it would be a cleaner way of templating than using str_replace
() over and over again. For what it's worth, I use Smarty on almost
all of my projects, large and small. I find that once you learn it
you can use it to develop new sites rather quickly.
...and it's not like using a nuke to kill a fly - Smarty only loads
the files it needs as it needs them instead of loading everything -
so it's quite fast really.
- Joe
On Jun 22, 2006, at 7:10 AM, Ryan A wrote:
Hi,
A pal of mine needed some help on his project, he is
using a header and footer file to template his
project... but its gotten a bit complicated as he has
a few dynamic parts in the header and footer files, so
I told him to go with a proper templating method of
templating the whole page rather than includ()ing the
top and bottom.
After having a better look at his scripts, I am just
not sure if something big (like SMARTY for instance)
would be good for him. He just needs maybe 5 template
pages, same pages, different color.
Searching google I see literally hundreds of
templating solutions can anyone recommend a simple
one or should I tell him to just use str_replace() for
tags like: {{menu_here}} {{header_here} etc?
Something like SMARTY would be like using a nuke to
kill a fly (IMHO) esp since this project will not
expand to anything much bigger or complicated.
Thanks!
Ryan
--
- The faulty interface lies between the chair and the keyboard.
- Creativity is great, but plagiarism is faster!
- Smile, everyone loves a moron. :-)
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating
Miles Thompson wrote: Don't forget, PHP itself is a templating language. Just do a standard page, with includes for headers and footers, menus, and content. If he wants to change colour, then load a different stylesheet for a given page or content section. This way he can use the tool that's right in front of him, he's not adding another layer, he does not have to learn another language - the template system written in PHP, and he hones his PHP skills. I agree. I think this would be the best solution for a simple site. Good point about honing PHP skillz. As far as a CMS goes, textpattern is pretty dope. Simple to setup, free, and it has a kick-butt template system. Gl, Cheers, Micky -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating
On Thu, June 22, 2006 6:10 am, Ryan A wrote:
He just needs maybe 5 template
pages, same pages, different color.
For something THIS simple, I truly believe you are Better Off (tm)
with a simple head() and foot() function in a globals.inc file:
function head($title = My Site, $bgcolor = '#ff'){
?
!DOCTYPE ...
html
head
title?php echo $title?/title
/head
body bgcolor=?php echo $bgcolor?
?php
}
function foot(){
?
/body
/html
?php
}
?
Your header and footer are now in one template-like file which makes
it easy to match up tags.
And the 5 pages will look like:
?php
require 'globals.inc';
head('Page One', '#fcfcfc');
?
pPage One specific content here/p
?php
foot();
?
The reason I prefer this to header/footer includes, is that it's too
easy to mess up closing tags in footer/header out of sync with
separate files, but with one file, they're right there and a decent
HTML editor will pick them out for you.
--
Like Music?
http://l-i-e.com/artists.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating
At 6:26 PM -0500 6/22/06, Richard Lynch wrote:
On Thu, June 22, 2006 6:10 am, Ryan A wrote:
He just needs maybe 5 template
pages, same pages, different color.
For something THIS simple, I truly believe you are Better Off (tm)
with a simple head() and foot() function in a globals.inc file:
function head($title = My Site, $bgcolor = '#ff'){
?
!DOCTYPE ...
html
head
title?php echo $title?/title
/head
body bgcolor=?php echo $bgcolor?
?php
}
function foot(){
?
/body
/html
?php
}
?
Your header and footer are now in one template-like file which makes
it easy to match up tags.
-snip-
The reason I prefer this to header/footer includes, is that it's too
easy to mess up closing tags in footer/header out of sync with
separate files, but with one file, they're right there and a decent
HTML editor will pick them out for you.
Well... I prefer to separate the header and footer into two files and load them
as needed in my web page. In addition, I would most certainly remove ALL
attribute stuff that could/should be controlled by css out of html and php and
into a css file.
I usually start my pages off with:
?php include('includes/header.inc'); ?
and end them with:
?php include('includes/footer.inc'); ?
Inside the header, I have the DOCTYPE, html, head (with all the header
stuff including css) and body tags.
The footer has my closing Last Modified, Copyright, and the ending /body
and /html tags.
In between the two body/body tags it's pretty simple to manage the html and
keep track of div's. I never have a header or footer that goes beyond the body
tags -- so even if there is NO html in between, I still have a valid page.
I also use other includes, like for navigation. However, every include file is
complete from its start tag to its finish tag so I never get my tags out of
sync. It's just a matter of good housekeeping.
If I want to control the color of something, then I do it in css. If I have to
do it via php, then I wrap css in php and do it there. But, I always try to
keep presentation out of my code. Besides, I find it's much easier for me that
way because I can do anything to my code and the presentation stays the same --
likewise, I can do anything I want to my css, and my code remains unaffected.
It works for me.
tedd
--
http://sperling.com http://ancientstones.com http://earthstones.com
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating
On Thu, June 22, 2006 7:23 pm, tedd wrote:
At 6:26 PM -0500 6/22/06, Richard Lynch wrote:
On Thu, June 22, 2006 6:10 am, Ryan A wrote:
He just needs maybe 5 template
pages, same pages, different color.
For something THIS simple, I truly believe you are Better Off (tm)
with a simple head() and foot() function in a globals.inc file:
function head($title = My Site, $bgcolor = '#ff'){
?
!DOCTYPE ...
html
head
title?php echo $title?/title
/head
body bgcolor=?php echo $bgcolor?
?php
}
function foot(){
?
/body
/html
?php
}
?
-snip-
Well... I prefer to separate the header and footer into two files and
load them as needed in my web page. In addition, I would most
certainly remove ALL attribute stuff that could/should be controlled
by css out of html and php and into a css file.
Putting the stuff into CSS is fine with what I did -- I do that all
the time.
In between the two body/body tags it's pretty simple to manage the
html and keep track of div's. I never have a header or footer that
goes beyond the body tags -- so even if there is NO html in between, I
still have a valid page.
The header and footer frequently contain the logo, site nav, possibly
a site-wide context-sensitive nav, maybe a mailing list signup, and
then copyright and so on.
There's no need to be doing a bunch of include files to hit the HD
(expensive) separately for each.
It's also all too easy to forget one of the include files on one of
the pages and never even notice it... I've done it too many times when
I went back to add some fluff page to some ancient site. :-(
A reasonable amount of the all the same stuff in head() handles all
that, and the footer, in one HD seek, with matching tags between
head() and foot() in a single file.
It's also very easy to call foot() in an error condition to be sure
all tags balance.
--
Like Music?
http://l-i-e.com/artists.htm
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Templating systems for single developers?
I use Smarty and am the lone developer. Why - Easiest to give an example that I did. I have my site with 7 pages. Each page has a minimum of 4 templates for it (though 6 is the average). Time goes on and I decided I wanted to completely change the look of my site (currently can't handle the increasing amount of data and pages easily) and make it xhtml compliant. Rewrite the CSS and modify the templates to allow for the new changes. Site revamped and xhtml compliant in less then a week. Couldn't do that as quickly if I wasn't on a templating system. Maybe next time I overhaul the site I will work toward making it more accessible. Murray @ PlanetThoughtful wrote: Hi All, Given that templating seems to be a hot topic at the moment, I'm wondering if anyone here uses templating in a single developer environment, and why if so? I've looked at various template systems from time-to-time but I've always come away thinking, 'yep, I can see the point in a team environment, particularly one that mixes designers and coders, but what would be the benefit to a lone developer like me?' So, if anyone out there uses a templating system (ie Smarty, PHPSavant etc) and they don't work in a team environment, I'd love to hear what benefits you derive from so doing. Much warmth, Murray -- Respectfully, Ligaya Turmelle Life is a game so have fun -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Templating systems for single developers?
On Tue, 2005-05-10 at 17:17, Murray @ PlanetThoughtful wrote: Hi All, So, if anyone out there uses a templating system (ie Smarty, PHPSavant etc) and they don't work in a team environment, I'd love to hear what benefits you derive from so doing. I do for as many projects as possible. Nothing like sharing custom tags across projects. Also something you can't do in PHP is include source code with a function definition that has already been defined which as many PHP developers will attest to, causes problems when importing 3rd party code. With custom tags I can override an existing tag of the same space/name with different functionality by assigning the compiler with the tag to override a higher precedence in the configuration. Additionally I can create custom tags that output other custom tags or standard tags since evaluation is recursive (at compile time NOT run-time). Also some of the sites I manage are in the hundreds of pages and having the template engine index the site's searchable content via a custom tag is quite convenient. search:public Blah blah blah blah. /search:public Custom tags aren't just for content replacement as you can see, they can provide meta functionality at arms length. Also I like the convenience and clarity of using static accumulators to accumulate content that will be flushed into a pre-defined position. For instance a template like the following: html head jinn:accumulatorFlush name=javascript/ jinn:accumulatorFlush name=javascript dynamic=true/ /head body Blh. /body /html And then a source file which will be expanded into the above main layout template: jinn:accumulate name=javascript script type=text/javascript language=javascript !-- // /* Some funky javascript or whatever have you. */ // -- /script /jinn:accumulate p Blah blah blah blah. Blah blah. Something funky with javascript. /p As you saw in the main template declaration there were two flushes, one is static and occurs at compile time saving any run-time overhead, the other is dynamic and occurs at run-time (which is useful if your code needs to output javascript). Anyways, there's way more to all this than I can usually think of when people ask. Experience, mine in particular, leads me to prefer the template approach over the PHP approach. And then again my own template approach over the smarty approach :) Cheers, Rob. -- .. | InterJinn Application Framework - http://www.interjinn.com | :: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Templating engines
Mattias Thorslund [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] (On the subject of templating engines, again.) I wonder what you folks think of the following: http://www.massassi.com/php/articles/template_engines/ hi! It is nicely written, but actually, I think completely oposite from you. The way I see it, the statement that template system purpose is to separate bussines logic from presentation, is the biggest missconception about templates :) Not that I think that bussines logic should not be separated from presentation logic, it is only that I think that it shold be separated in your php code design, l, not by the template system. And html, and code should be separated, one is used to model static and visual concepts, and another to model dynamic concepts. And they usually get defined by people with completely different skills and even mindsets. Anyway, I do not think there is One Right Way, of looking at templates. I for one would never be satsfied with fat temlates like they are in Smarty for example. But on the other hand I understand that there are people that would never trade their Smarty templates. So as we do not get to exclusive about how thing must be done, we could get along nicely :) rush -- http://www.templatetamer.com/ http://www.folderscavenger.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Templating engines
rush wrote:
Mattias Thorslund [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
(On the subject of templating engines, again.)
I wonder what you folks think of the following:
http://www.massassi.com/php/articles/template_engines/
hi!
It is nicely written, but actually, I think completely oposite from you. The
way I see it, the statement that template system purpose is to separate
bussines logic from presentation, is the biggest missconception about
templates :)
Nice turn of phrase. It took me a while to see that you didn't misread
the article. :-P
Not that I think that bussines logic should not be separated from
presentation logic, it is only that I think that it shold be separated in
your php code design, l, not by the template system. And html, and code
should be separated, one is used to model static and visual concepts, and
another to model dynamic concepts. And they usually get defined by people
with completely different skills and even mindsets.
I suppose this depends on the situation. If the graphic designers are
allergic to seeing ?=$var;? instead of {$var}, I suppose a
templating engine like Smarty or TemplateTamer is the way to go. Or, if
you wanted to prevent the graphic designer from adding some complicated
PHP code in the code , say because they don't understand how to
structure the code. Or, because the templates will be created and
uploaded by people who shouldn't have access to upload PHP code to the
server.
As for the article, I know the author describes putting even pretty
complicated presentation logic in the template. I agree that that's
probably not such a good idea. But I don't see where the
PHP-as-templating engine concept implies that you couldn't also separate
the business logic from the (dynamic) presentation logic in the php
code, before calling the template. The static layout in the PHP
'template' file is basically HTML only, with placeholders for the
dynamic data - only that the placeholders are also valid PHP, not
yet-another language.
Anyway, I do not think there is One Right Way, of looking at templates. I
for one would never be satsfied with fat temlates like they are in Smarty
for example. But on the other hand I understand that there are people that
would never trade their Smarty templates. So as we do not get to exclusive
about how thing must be done, we could get along nicely :)
Agreed. I don't lose sleep over it :-)
/Mattias
--
More views at http://www.thorslund.us
Re: [PHP] Templating engines
On 4/28/05, Clive Zagno [EMAIL PROTECTED] wrote: What templating engines do you use with php and why? I use eval(). Because it works. -- Greg Donald Zend Certified Engineer http://destiney.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Templating engines
Greg Donald wrote: On 4/28/05, Clive Zagno [EMAIL PROTECTED] wrote: What templating engines do you use with php and why? I use eval(). Because it works. I'm a big fan of include(). ;) -- John C. Nichel ÜberGeek KegWorks.com 716.856.9675 [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Templating engines
Greg Donald wrote: On 4/28/05, Clive Zagno [EMAIL PROTECTED] wrote: What templating engines do you use with php and why? I use eval(). Because it works. Myself, I'm partial to include(). ;) -- John C. Nichel ÜberGeek KegWorks.com 716.856.9675 [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Templating engines
I'm a big fan of include(). ;) Ditto! -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.308 / Virus Database: 266.10.4 - Release Date: 4/27/2005 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Templating engines
At 5:43 PM -0800 4/28/05, Clive Zagno wrote: Hi all, What templating engines do you use with php and why? Ive been using smarty (http://smarty.php.net) I've used include(), and smarty, but now use Expression Engine http://www.pmachine.com. EE which is more of a CMS than just a templating system, but it has a world class templating system; and that rocks. One of are other programs swears by smarty, but I'd go with includes if I wasn't using EE. Alnisa -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Templating engines
(On the subject of templating engines, again.) I wonder what you folks think of the following: http://www.massassi.com/php/articles/template_engines/ I've been using the template class in the example of the article. I think it's easy to use and very flexible, since it uses PHP as the actual template language. I haven't used in a production setting yet, and haven't compared its performance with other template systems. /Mattias P.S. Sorry for hijacking this thread, but it's closely related. OK, I wrote that before I read all the off-topic jokes in this thread. I don't feel sorry anymore :-) -- More views at http://www.thorslund.us -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] templating question
You can always roll your own, it's not that hard at all. Here is an example: ob_start(); include(templateFile); $tpl_file = ob_get_contents(); ob_end_clean(); The contents of your template file are now in the variable $tpl_file and you can you str_replace to input the data. Remember that str_replace handles arrays, so you can do many different replaces at once. I looked into the other templating systems too and they were just more than I needed at this point. On Friday, March 21, 2003, at 02:55 AM, Dan Rossi wrote: i would like to know what good ones out there, fast template uses ereg and is slow , itx screws with the source layout and the output looks shit , smarty wants control of the code , is there anything better than these guys ? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Brent Baisley Systems Architect Landover Associates, Inc. Search Advisory Services for Advanced Technology Environments p: 212.759.6400/800.759.0577 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Templating
On Mon, 2002-02-04 at 18:20, Trent Gillespie wrote: I have a template file that I would like to add the content to no write over it. I want the string $content to be added to my template instead of writing over it. Here is my current script $tutorial = template.php; $fp = fopen($tutorial,w); fputs($fp, $content, strlen($content)); If you need any other info please just ask. And if you dont get my question aske again. Use 'a' instead of 'w' as the file open mode in your fopen() call: $fp = fopen($tutorial, 'a'); This is documented on the fopen() page in the manual, btw: http://www.php.net/fopen Hope this helps, Torben -- Torben Wilson [EMAIL PROTECTED] http://www.thebuttlesschaps.com http://www.hybrid17.com http://www.inflatableeye.com +1.604.709.0506 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Templating solutions?
A great solution for this kind of job is Midgard (www.midgard-project.org). It provides heaps of features oriented to solving all your possible problems -- user control/access; separate content and style templates, manages includes automatically so you don't have to fiddle around tens or hundreds of files in order to add the new php you want to include. So, on the pro side there's much about everything you may wish. On the con side, however, is that if you ever wish to export a site to a server without Midgard you'll have a very hard time doing it because everything that was done automatically by Midgard must be done manually in order to create the php files comprising the site (had this experience recently, and it's a real pain). However, these events are usually forseen, so if you have your own server you don't need to worry about this problem. HTH Bogdan Lauri Vain wrote: Hi there! During the last two weeks or so, I've been bugged by a question deep inside me. It's about various templating solutions used with dynamic web applications. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Templating solutions?
Lauri -- You might want to take a look at: http://www.thewebmasters.net/php/ there's a tutorial located here: http://www.devshed.com/Server_Side/PHP/PHPFastTemplate/page1.html -- David Hi there! During the last two weeks or so, I've been bugged by a question deep inside me. It's about various templating solutions used with dynamic web applications. Oftentimes simply embedding the code into the HTML template does the trick. Othertimes the codeinclude(header.inc);/codeand codeinclude(footer.inc);/code works its magic. There are, however, also moments when such approaches aren't enough and something else is required. What does one do when the templates of most pages within one site differ in look and feel? One possibility would be to specify a template, load it into a variable and replace certain marked spots (a la !--left_navbar--) with the dynamically created code/text using eregi_replace() or something similar. What are the templating solutions available? Pros and cons? How do you solve your templating? Yours, Lauri -- Tharapita Creations [dynamic web applications] [EMAIL PROTECTED] Mobile: +372 53 410 610 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP] Templating solutions?
Woops -- first link is to the site for PHPFastTemplate. Lauri -- You might want to take a look at: http://www.thewebmasters.net/php/ there's a tutorial located here: http://www.devshed.com/Server_Side/PHP/PHPFastTemplate/page1.html -- David Hi there! During the last two weeks or so, I've been bugged by a question deep inside me. It's about various templating solutions used with dynamic web applications. Oftentimes simply embedding the code into the HTML template does the trick. Othertimes the codeinclude(header.inc);/codeand codeinclude(footer.inc);/code works its magic. There are, however, also moments when such approaches aren't enough and something else is required. What does one do when the templates of most pages within one site differ in look and feel? One possibility would be to specify a template, load it into a variable and replace certain marked spots (a la !--left_navbar--) with the dynamically created code/text using eregi_replace() or something similar. What are the templating solutions available? Pros and cons? How do you solve your templating? Yours, Lauri -- Tharapita Creations [dynamic web applications] [EMAIL PROTECTED] Mobile: +372 53 410 610 -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
