Regarding this page: http://drupal.org/book/view/871
I have been working on template system that allows a DESIGNER to slightly mark up the html and then my PHP code re-factors the design as a PHP class, with the various design elements becoming different methods of the class, even supporting parameter passing.
Well now I've finished I'm working on a back end. Then I read slashdot about drupal
The best part is Drupal USES this sort of class as my code generates.
In other words it wont take much work to fettle to two together.
And the good news is I can use drupal as my backend!
BTW it also supports dreamweaver MX templating, so designers can do dreamweaver MX tempate inheritance to get the visual effect at design time for their benefit (and allowing designer to only edit the editable-area) and we inherit generated classes also.
Read the docs at:
http://www.liddicott.com/templates.html
If there is enough interest I would like to check it in to CVS (under GPL) for integration. I'm supposed to be adding it to PEAR's Flexy::Tempalate with Alan Knowles but I haven't had time yet.
TO be sure you understand, the templating is ready to go and already used in a non-launched site that just needs a CMS backend, now to be drupal I hope
Comments
If you are truly interested
You should install a copy of Drupal, join the developer's mailing list, get a CVS account, and see how it fits with your vision.
The xtemplate theme currently does what you describe (right down to the curly braces), and the resulting .xtmpl file can be edited in Dreamweaver or other graphical tools.
--
Boris Mann
xtemplate not there?
The xtemplate theme at http://drupal.org/drupal/cvs/themes/xtemplate.tgz seems quite empty, no .xtmpl file, certainly.
it contains: readme, red_paisly.gif and warm.css
Sam
Xtemplate is in Drupal core.
Xtemplate is in Drupal core. The files you found are optional replacements for some of the files.
--
Drupal services
My Drupal services
XTemplate is not Complate
The Xtemplate, and Theme module in general is not complete. You can not change forms, the forum, tracker, or many other basic modules looks or markup through the theme system.
For me this is a major weakness for drupal, along with poor documentation. The theme class seems perfectly good, but it is not used enough. All html ouput should be done through the theme class, there should be no divs in the drupal code, except for the theme class.
So if bmann wants to help with this, then that is great.
100%
I'm with you 100% on this. The main thing in my eyes which Drupal is lacking is complete seperation of logic and presentation.
PHPtemplate, anyone?
PHPtemplate, anyone?
macrotags
You might also be interested in the beta macrotags module. This module maps html to php functions, similar to your T:METHOD approach.
Has anyone here considered phpTAL?
I highly recommend folks take a look at phptal.sourceforge.net . It uses tag properties to define behavior, rather than creating additional tags, which is roughly equivalent to custom tags. It is fully internationalized. It is the PHP version of Zope's much admired ZPT template system.
Please comment.
some experiments
Adrian wrote a theme with phpTAL but he found phpTAL to be really slow and abandoned development. Maybe phpTAL has since become faster?
It would be great if someone picked up his theme and continued development. Here are some relevant mailing list posts.
phpTAL not slow
There is a misunderstanding about the speed of phpTAL (and for that matter, Smarty and other complete templating systems). Remember that after the first request the template is compiled to PHP, providing performance similar to PHP code based theming or templating solutions. But phpTAL also provides for caching of all or parts of a page (and, naturally, results of database queries); the result can approach static page delivery times. A non programmer can completely develop the page design, and even stick in (and leave in) dummy data, which gets replaced at compile time. Please do not underestimate this package.
Some tweaks:
phpTAL allows you to plugin your own cache control function. For static page delivery, call the cache before calling phpTAL. If you don't need multilangual support, comment out the i18n related code. With phpTAL, you can eliminate calling the drupal framwork itself for most pages, since most pages are static from one request to another. This is how you can get near static page delivery times, and average website speedup (mix of dynamic and static delivery) of 10X the current drupal performance (already quite good for a fully dynamic system).
Cheers,
pacoit
i think it /is/ slow
some time ago, i did a simple benchmark and found PHPTal - with caching enabled - really slow. and apparently, i'm not the only one thinking so. in this PHPTal evaluation, L. Magnocavallo says PHPTAL is too slow to be used for our applications [...] What I did not expect, however, was the order of magnitude of its slowness compared to what we are using [...].
the same article also questions the architecture of PHPTal. i mostly agree with this. my conclusion was to not use PHPTal but SimpleTAL. this is written in python, which, besides being a language more powerful than php, allows the integrations of nice packages such as docutils and roundup.
I hear you, but...
I had already seen those articles. And I think they failed to look at phpTAL in sufficient depth. I suppose that by proposing SimpleTAL (and by extension, Zope Page Template (ZPT)) you acknowledge the design is compelling? Perhaps your point is that phpTAL is implemented poorly. I can see making some changes, but the implementation is designed precisely to make the changes you may need. For example, you mentioned performance with and without caching. However, phpTAL doesn't come with a cache function, just a hook for you to write your own. You seem to have compared compiled versus non-compiled template performance. With caching you get many hundreds of requests per second.
I don't always agree with OO approach, either. It makes it somewhat harder to intantiate or parse only the minimum code required for a request. But, there are other benefits.
phpTAL not only separates business logic from presentation logic, it also separates virtually all the presentation logic from the layout template. That is the elegance of phpTAL SimpleTAL and ZPT. A non programmer can radically alter the layout of any page and view his work realistically in a browser without any backend connection.
Only if (for some reason) you require all pages to be fully dynamic, and have no use for caching, does it make sense to do with PHP theming system (I wouldn't call it templating, but that's just me) in order to maximize dynamic page delivery performance.
the chameleon theme
The reason i abandoned that version of chameleon was not directly because of the speed problems, i know for a fact that it would be possible to make it all work faster. If not now, then in a few months time with php 5 (i have spoken with the author, laurent about the speed issues, and he said that the object model it generates can be computationally expensive and php5's enhancements should speed it up quite a bit. I stopped working on it originally because i was finding it near impossible to catch all the output at the time. I am sure, that i know a lot more about drupal now , and could make it work.
I however now believe that _any_ templating engine might not be the best idea for a simple theme. I am building a template engineless template based chameleon theme, that uses included php files to do the templating. It also uses the same design principles about multiple css files for each template . to generate wildly different designs from the same html (http://www.csszengarden.com)
> phpTAL not only separates business logic from presentation logic, it
> also separates virtually all the presentation logic from the layout
> template.
I agree with you completely. I absolutely adore the way TAL does things, and I still believe that in many ways it's the CORRECT way to do many things. It is however total overkill for what I need it to do , and the html should not have to be edited in most cases with drupal, yet .. it should be available to be slightly modified.
> Only if (for some reason) you require all pages to be fully dynamic,
> and have no use for caching, does it make sense to do with PHP
> theming system (I wouldn't call it templating, but that's just me)
> in order to maximize dynamic page delivery performance.
My tal theme is still around, and can be used as the base for a new theme. I might even give it another look soon, as i have already got _several_ days worth of work invested in it, the only reason i am not working on it .. is that for _me_ , it's not the right answer for now.
PHPTAL theme engine in Contrib
Hi,
I have built a PHPTAL theme engine and placed it into the Contrib area. It allows the same push/pull approach to templating as PHPtemplate. To my taste, the theme files that go with PHPTAL it are real beauties as compared to the crude mixture of PHP and HTML necessary for the PHPtemplate.
Performance seems not bad at least on my small example installation. Until measured properly however, I would still suggest using PHPtemplate when performance ist key.
Regards,
Olav
--
Olav Schettler
I have installed phptal and
I have installed phptal and the cvs phptal engine. i have created sample.tal
and included these lines,
a sample function was added to *template.php* in libs/phptal/
my *sample.tpl* has these lines,
i couldnt see any output from the function. can i have a example of how to get the output from a custom tal file.