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
