Actually, you can use smarty in a way that solves those issues. Simply do not include the logic features of smarty in your templates. That way, the only thing included in the templates is html, and {$variables}.
Then your web designers don't need to learn anything.
The problem that you'll find with that, is that it means you will have to do more html work in your back end logic to produce the same results.
Yes, it is bound to php, and yes, it has to happen on the application server that gets the call, but if you're using php as your application processing, then why would you need it to be somewhere else.
Smarty is a tool. You can choose to use the tool however you wish. If you have designers that are basic programmers too, then it is very powerful. If not, then you just have to do more of the work.
Personally, I like Smarty very much, because I do both.
Its no different than say java servlets, or xml, or any number of other ways to do it...
Tim.
At 08:38 AM 4/14/2004, Enrico Weigelt wrote:
* pete M <[EMAIL PROTECTED]> [2004-04-14 13:50:19 +0100]:
> Moving our sites to smarty is the best thing we've done at our company... > > > I do the php/database coding (logic) > the html designer does the templates/css > and the graphic designer does his bit.
I really don't like smarty. The idea is simply not right.
The problem is, that smarty itself (or its template-language) also contains imperative process logic. In fact it is not an real template engine, but instead an php dialect which helps a bit on website programming.
Smarty still lets some major problems unsolved:
+ does not separate (imperative) code from layout. it still models process logic + such non-trivial imperative code is not suited for non-programmer's (perhaps graphical) editing tools. + the layouter has still so learn (a subset of) php and so also has to be a programmer + offers no clear borderline between layout definitions and application code. you simply can't give a customer of your application service access to without imposing really serious security problems. + bound to the php-interpreter and cannot be used w/ other languages. + content rendering process cannot be separated from the application server. (still must happen in the same process)
Well, I personally prefer the patTemplate way. And if you wanna see my last two points solved, then my own branch (pTemplate) will offer good help.
cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT services
phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: [EMAIL PROTECTED] cellphone: +49 174 7066481 --------------------------------------------------------------------- -- DSL-Zugang ab 0 Euro. -- statische IP -- UUCP -- Hosting -- ---------------------------------------------------------------------
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
SimpleNet's Back ! http://www.simplenet.com
