I have been following this thread closely and thought I'd summarize a few points:

1. 'Template Engine' - you can justifyably call PHP a template engine, but I think calling Smarty a template engine confuses the issue - it would be clearer call it something like 'Presentation Component' which encapsulates output caching, output string transformation, markup generation, presentation logic security & seperation of (code & possibly human) tasks. viewing it as a component means viewing it as a tool, tools are used when appropriate and according to their capabilities and the scope of the job at hand. in principle a sizeable proportion of all the.

2. 'The Template Language' - basic PHP and Smarty 'languages' are roughly on par in terms of complexity (MMV - were all unique!), personally I feel that Smarty markup looks tidier alongside (X|(X)?HT)ML.

3. 'Lock In' - the lock-in argument is academic. in reality projects you build using Smarty will be decommissioned or rewritten (at which point you can choose to use something else) long before lock-in becomes an issue. Besides being locked-in to Free & Open code doesn't sound too bad - if you don't use somebody elses 'template engine' then you will probably end up writing something similar to perform the related tasks - using somebody elses frees you from dev, maintainance, doc-writing etc

4. 'Limited Interface' -

5. 'Limitations' - when you find Smarty limits you, but you are otherwise convinced its a good tool for the job, subclass it and make it do things your way (or write BadAss(tm) plugins - for which you can achieve fame and glory if you make them available on the Smarty Wiki ;-). any real limitations of Smarty are not of a level which would trouble novice users of PHP, they are simply not yet at the level where they are stretching the capabilities of PHP or components they use. Smarty is limited in 2 ways:
1. because PHPs syntax is very broad and flexible (the fact that
it is typeless is probably no help in this respect), this makes
it extremely difficult to support it all with in the Smarty
constructs -it not only has to work, but it has to work
As Expected(tm).
2. on purpose in order to allow the develop to determine what
interface (functional markup*) designers. Limiting the interface
(and by definition defining an interface) is a Good Thing(tm)
thats why PHP5 supports interfaces for classes - consider them,
like steel-toe-capped boots in the fight against spaghetti code.
Limitations are often purely percieved rather than actual, possibly stemming from the fact that somebody else decided on how (i.e. not _what_) to do something, small price to pay if for a free, well supported component really. And when you look at it you might see that this is a bit like developing in a team, sometimes somebody (has to) make(s) a decision and your stuck with it regardless of whether you think it is correct.


6. 'Designers & Templates' - I use really heavy smarty markup (70% or more is not HTML) for the presentation logic... why because my templates are very generic - they expect php objects of a certain types and the create markup based on the structures within. I don't want any non-programmer anywhere near my templates - styling belongs in CSS, that is what designers should using to change the look and feel of the site - from a deisgners point of view CSS type markup is the future is layout - it almost completely removes the styling from the structural markup (Murphy's Law dictates that some of the designers wishes will mean having to tweak the functional markup templates - but that does not happen constantly.). Are your designers often styling/layout online articles are the like? maybe it time to try a webbased (X)HTML editor - for a couple of $, or even for free, you have an editor to create content with which you can store in files or a DB, even change history if you want and then extract this content and display it in one of your structural templates.

7. 'Why the fuck do we do this?' - for the kick of writing cool code for one, but there are always many tasks in writing an application which are mundane (to say the least) - for me Smarty takes care of a few of these and that makes coding more fun.

8. 'Why use Smarty?' - what a non-question or rather you have to answer it yourself. first determine what it is you need to do now (and possibily in the future) then go and look what best fits the need (read the code and the documentation, make an effort to actually run examples) - if nothing fits write something. if your going judge Smarty do it based on the quality of the code, level of support and the usuability/flexibility of its API.

9. 'php.net' - it possibly says something of Smarty that it is hosted under the PHP banner. Smarty is certainly not the only way, probably not the best way and possibly not the most flexible way. But it provides a free, stable, widely used & well supported framework for seperation presentation from other areas of your application. how bloated is depends on how radical your PHP is, the better you can code, the more you can spot the 'gaffs' in other peoples code. Smarty provides a great learning experiences for those interested in PHP and is for alot of people probably a good example of how to write better code (one of the reasons its up there on smarty.php.net?).

10. 'Smarty is pointless' - only if you look at it in terms of template engine functionality (php wins hands done), but that totally misses the point. 1. _you_ decide whether its relevant to your project (size, scope & complexity are factors - I think Smarty sits in the mid-band of of the low2high scale), 2. Smarty was not created in a void, it arose out of a need, if the need that Smarty fulfils sufficiently covers your requirements then maybe its an option for you. Possibly the 'need' is not yet fully understood (tech & ideas about tech constantly evolve also!) - this is not a reason to dismiss/denounce Smarty or other like tools out of hand, is a Picasso pointless? is it perfect? is it relevant? a group of people put alot of effort into writing Smarty, its rude to disrespect that effort - more so, maybe, considering the user base. Real coding is not about producing the best code, but about always striving, to the best of _your_ ability, to produce better code, Smarty is a good example of this. Smarty is not perfect but then look out of your window. is it pointless? give it try, do you like? judging by the length of the thread on Smarty (and the emails in it!! :-> )


*I use Smarty purely for functional markup & basic page layout (header, footer, menu, content areas) no design element at all (e.g. all bg/decorative images are defined via CSS).


--
feel free to pass this around, change/correct it, plagurize it, blog it. i.e. no rights reserved.


**************************
**************************
**************************

(mmm.... today was a 'trademark' day)

(mmm.... today was also a 'show-your-subtle-disapproval-of-silly-email-privacy-messages-and- copyright-stuff-in-general' day)

**************************
**************************
**************************

I also offer a copy of a email I sent to Chris de Vidal off-topic which was in relation to this thread...

consider the following:

<?

// BUSINESS LOGIC

$page = 'User Profile';
$name = 'Jochem';
$whereabouts  = 'unknown';

// PRESENTATION LOGIC

?>
<html>
<head>Jochem site:: <?=$page;?></head>
<body>
<h1>User Profile</h1>
<p>name: <?=$name;?></p>
<p>whereabouts: <?=$whereabouts;?></p>
</body>

--
looks pretty templaty don't you think? its valid PHP (= Php HyperText Processor). In my above example the code/text following BUSINESS LOGIC & PRESENTATION LOGIC could be split into seperate files - then 1 can include the other. conceptually thats what a 'templating' engine does.


possibly templating could be considered a design pattern? usually implemented by a 'presentation/output' module (| component / system / widget / thing / wotsit).

read the following article for more info (I don't agree with author but the point that PHP is a template engine, among other things, is correct - he also focuses too much on the things you can do wrong with smarty)

http://www.phppatterns.com/index.php/article/articleview/4/1/1/

I also think its bullshit to allow a 'designer' to write HTML - the templates (files with presentation logic and markup) to me are programs and should be handled by programmers (I have successfully got my dad editing PHP files on a site I made for him - they are simple files but none the less it shows that basic PHP/templateScript should not be a problem for a reasonably intelligent person to pick it up!), visual presentation can be handled purely using CSS - again the program must provide class and/or identifiers (e.g. for all the HTML elements on the output page.) which a designer can associate style/layout definitions with. Data requirements determine what is output, and the decided upon graphic 'look' will to a certain extent determine basic structuring/ordering of elements within templates (because some browser-compatibility hacks can only be provided by going in a doing something f***ed up with the markup, also in practice a _major_ redesign of a site almost always )

the whole idea of giving the designer a safe environment to create in is at once noble yet ultimately futile. IT is a complex business, period - so can writing 'templates' be be it in HTML, javascript, PHP, smarty syntax or whatever. So I don't use Smarty for that, other people do and their requirements obviously make it a useful feature. Whatever you use to glue markup, style, content, logic together (assuming your not using the tossed salad & scrambled eggs approach to coding ;-) it will be something the designer has to learn how to use, besides very generic or complex templates quite often leave little useful on the screen (in FrontPage/Dreamweaver) for the designer to style (...and for instance how do I let a designer specific (bg)colors etc for mouse-over and selected-rows? these element states only occur at run time, oh well can't do it then, ...wait is that a stylesheet I see, stylesheet saves the day)

get designers off templates & onto stylesheets (they cost less per gram ;-) - they are concise syntax for specifying font/color/bg/etc/etc/etc/etc - how easy is it to code something that lets a designer see what

template engine is the wrong word I think; Smarty is a presentation component that allows seperation of tasks between developers and in the code in terms of application and presentation logic. it also provides a uniform 'shorthand' syntax for transforming data, mostly strings for transformation commonly applied to vars prior to output)

I'm currently using Smarty in a project which consists mostly out of completely generic templates (i.e. they have no idea of the details or ammount of data being output only the overall structures, think classes objects) - I have a base (data listing/management) content management which has only 2 templates - the details view template and the list view template - bare in mind the list view is capable of show arbitrary types of 'fields', (char, blob, url, email, phone, postcode, img, etc), including reference, association & many2many relationship field etc, you can reorder columns on the clientside (drag'n'drop) sort most fields, filter the list, the data is paginated (e.g. 50 items on a page) and the number of items is user-setable. you can highlight/select rows (they change colour) and then perform actions (there is a std set of actions like copy, delete, edit & edit-at-once + custom actions that can be defined for specific entities) on the selected rows. you can even hide/unhide arbitrary columns.
All that with 1 template. The template is the meat of the Model part my ModelViewController setup - 1 object handles incoming requests (delete this, show that, edit this) determines whats allowed etc (the Controller), another object to contain and describe the information being shown (the Model) and 1 object to present what ever needs presenting (the View e.g. Smarty - in my case I use a sub-classed custom View object that wraps a custom Page object which is in turn a subclass of the Smarty class - but heh thats another story!)
And how does it all look? well that depends all on the stylesheets - it look nice and tidy now but I will get a designer friend to sketch a new look and colour scheme which in translated into a new set of stylesheets (obviously using the same identifiers.).


- I hope you get the point that its only really seperation of tasks (code and human) and speed of development, for 99% of sites things like performance issues come a distance 2nd.

well it was fun writing that, being still in the process of extending/refining the code mentioned above, its nice to be able to recap.

Angelo Zanetti wrote:

hi all has anyone used smarty before? what do you think of it? I think it's
pretty nice to seperate your script (code) from your design.


<snip>


--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Reply via email to