Re: [PHP] Smarty Summary was Re: [PHP] smarty
Justin Patrin wrote: Jochem Maas wrote: ... Smarty does force that at all; you have to make the distinction and apply liberal self-restraint. I meant 'does NOT force' - thinko! ... PLEASE WORLD: GET BEHIND CSS, AND FREE CONTENT FROM STYLE ON THE CLIENT. why because it allows the structrully mark-uped to be display more flexibly, for diff. display, aural readers, braille etc. removing the styling definitions it also allows you to specify different markup. I want to. I so want to, but I can never get it to make the layout as I want it. I want to take a div and make it vertically or horizontally be practical - if you need to vertical align something and can't get it to work another way use a table. I CSS site that I found really inspiring is http://www.csszengarden.com/ if you really 'want to' then take the time to read it and view all the styles (well not ness. all 247) - take a look at the HTML (and the CSS file for each style), maybe have a go at it yourself. centered in another divif you figure out how to do it with dynamic try to let go of the assumption that you can control the display of your pages (think of the all the platform/hardware/software/user-settings/etc combinations there are.) - you can only guide it. one of the founding ideas of the 'webpage' if that the manner in which it is displayed is upto the user (braille/speech/mobile/PC/Barney). also attempt a site contruction by first creating a bare bones text only site with proper markup (P,H tags etc. prefer XHTML over HTML), the see what you can add. (have a look at the effect is of using different DOC-TYPEs) sizes that is easy and works on all the major browsers, let me know. I've tried for hours, looks on I don't know how many websites, and I still couldn't do it. I went back to tables because it's just so easy. CSS makes my life very hard...it doesn't seem to have the basics needed to create an entire layout. er but it really does (and the trick is to). not to worry I have been hacking css for about 3 years now, in the beginning it was even worse - support is getting better which means documentation often more closely ressembles truth ;-) Make Mozilla/Opera part of your testing kit - they support CSS better (they are not 3+ years old like IE6). instead of approaching it from the view of a print designer - ie fixed, static layout - assume the layout is a liquid (http://www.google.com/search?sourceid=navclientie=UTF-8oe=UTF-8q=liquid+design) to be honest - in this game you really have to study something to truely get a grip on it. I mean, how many scripts have you poured over, how many hours with just one of those scripts to get it to play just right? CSS is no different. That said, I do use lots of CSS for styling (font sizes, colors, images, printable pages, etc.), but fill-page styling via CSS is just beyond my reach. dumping all those style definitions in a seperate file in a good start. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Smarty Summary was Re: [PHP] smarty
Jochem Maas wrote: Chris de Vidal wrote: Jochem Maas said: 1. 'Template Engine' - you can justifyably call PHP a template engine Correct. Seems that Smarty is, for the most part, redundant (see my last post called PHP makes a great templating engine (Was: smarty)). I was not intending to pronounce Smarty redundant; on the contrary if anything - but thats not the point... 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. Tool. Look at it as just another tool. I was seeing it as a must have because I was somewhat ignorant of PHP's native capabilities. It adds complexity and does indeed slow down your program (the Smarty class must load on every page) so keep those in mind. On the other hand, you're the Smarty core is smaller than, for example, PEAR::QuickForm (if you use all the plugins its about 40% larger) - and PEAR::QuickForm is usually used with a Renderer (e.g. Smarty!!), think of it like this: how much do you charge per hour, what does an extra CPU cost how much, if any, time does Smarty save you. (besides which I think its quite easy to develop something in Smarty which does what QuickForm does but more transparently and with alot less hassle - IMHO). Code is code; it might not be perfect but it might scratch an itch. almost forced to separate business and presentation and you gain caching Smarty does force that at all; you have to make the distinction and apply liberal self-restraint. (though native PHP options or Zend are available). So it's a weighty decision. But it is a good tool. Realise that Smarty (usually) only re-compiles the template if it changes. The compiled template are full of generated PHP - there is little overhead in including that. if you use a native PHP option then: a, what is Smarty? (not important!) b, what are the chances that your output code/module/class/etc will not employ similar solutions to something like Smarty? because broadly speaking 3. 'Lock In' I believe Lock In is a big problem unless you document well. For instance, my supervisor is probably going to choose ASP.NET (don't ask why) for our next project. But all along, I plan to document it well in case we hit a stumbling block. With a bit of effort and the source code I can port it to PHP. I've even toyed with the idea of keeping a fully-functional copy written in PHP while he's working in ASP.NET ;-) But I've got better things to do. Limitations are often purely percieved rather than actual I believe that's why I chose Smarty for my last project. I thought PHP limited me to keeping business logic mixed with presentation logic, but it's hardly the case. and funnily enough Smarty is actually a pretty good example of a possible PHP based solution to the problem logic seperation. When you consider that it's just another tool in your box, it works well. It's not the only way to let designers design and programmers program (Jochem is a big believer in CSS for that). Just think of it as another PLEASE WORLD: GET BEHIND CSS, AND FREE CONTENT FROM STYLE ON THE CLIENT. why because it allows the structrully mark-uped to be display more flexibly, for diff. display, aural readers, braille etc. removing the styling definitions it also allows you to specify different markup. I want to. I so want to, but I can never get it to make the layout as I want it. I want to take a div and make it vertically or horizontally centered in another divif you figure out how to do it with dynamic sizes that is easy and works on all the major browsers, let me know. I've tried for hours, looks on I don't know how many websites, and I still couldn't do it. I went back to tables because it's just so easy. CSS makes my life very hard...it doesn't seem to have the basics needed to create an entire layout. That said, I do use lots of CSS for styling (font sizes, colors, images, printable pages, etc.), but fill-page styling via CSS is just beyond my reach. Ever written a print version of a page? why bother when all you need do is specify alternative stylesheet(s) to use for print media. Ever heard you page say 'IMAGE' 'TABLE' 'DATA CELL' 50 odd times as a blind persons screen reader trys to make sense of your pretty new data-driven creation... where the f*** is the menu?! did you know there is even an extensive specification for markup of aural media (e.g. tone of voice, male/female, speed etc etc) In my little world I have officially declared a Good Thing. of course it leaves the problem of how to manage all those stylesheets
[PHP] Smarty Summary was Re: [PHP] smarty
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
Re: [PHP] Smarty Summary was Re: [PHP] smarty
Jochem Maas said: 1. 'Template Engine' - you can justifyably call PHP a template engine Correct. Seems that Smarty is, for the most part, redundant (see my last post called PHP makes a great templating engine (Was: smarty)). 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. Tool. Look at it as just another tool. I was seeing it as a must have because I was somewhat ignorant of PHP's native capabilities. It adds complexity and does indeed slow down your program (the Smarty class must load on every page) so keep those in mind. On the other hand, you're almost forced to separate business and presentation and you gain caching (though native PHP options or Zend are available). So it's a weighty decision. But it is a good tool. 3. 'Lock In' I believe Lock In is a big problem unless you document well. For instance, my supervisor is probably going to choose ASP.NET (don't ask why) for our next project. But all along, I plan to document it well in case we hit a stumbling block. With a bit of effort and the source code I can port it to PHP. I've even toyed with the idea of keeping a fully-functional copy written in PHP while he's working in ASP.NET ;-) But I've got better things to do. Limitations are often purely percieved rather than actual I believe that's why I chose Smarty for my last project. I thought PHP limited me to keeping business logic mixed with presentation logic, but it's hardly the case. When you consider that it's just another tool in your box, it works well. It's not the only way to let designers design and programmers program (Jochem is a big believer in CSS for that). Just think of it as another tool and it's no big deal. /dev/idal -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Smarty Summary was Re: [PHP] smarty
Chris de Vidal wrote: Jochem Maas said: 1. 'Template Engine' - you can justifyably call PHP a template engine Correct. Seems that Smarty is, for the most part, redundant (see my last post called PHP makes a great templating engine (Was: smarty)). I was not intending to pronounce Smarty redundant; on the contrary if anything - but thats not the point... 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. Tool. Look at it as just another tool. I was seeing it as a must have because I was somewhat ignorant of PHP's native capabilities. It adds complexity and does indeed slow down your program (the Smarty class must load on every page) so keep those in mind. On the other hand, you're the Smarty core is smaller than, for example, PEAR::QuickForm (if you use all the plugins its about 40% larger) - and PEAR::QuickForm is usually used with a Renderer (e.g. Smarty!!), think of it like this: how much do you charge per hour, what does an extra CPU cost how much, if any, time does Smarty save you. (besides which I think its quite easy to develop something in Smarty which does what QuickForm does but more transparently and with alot less hassle - IMHO). Code is code; it might not be perfect but it might scratch an itch. almost forced to separate business and presentation and you gain caching Smarty does force that at all; you have to make the distinction and apply liberal self-restraint. (though native PHP options or Zend are available). So it's a weighty decision. But it is a good tool. Realise that Smarty (usually) only re-compiles the template if it changes. The compiled template are full of generated PHP - there is little overhead in including that. if you use a native PHP option then: a, what is Smarty? (not important!) b, what are the chances that your output code/module/class/etc will not employ similar solutions to something like Smarty? because broadly speaking 3. 'Lock In' I believe Lock In is a big problem unless you document well. For instance, my supervisor is probably going to choose ASP.NET (don't ask why) for our next project. But all along, I plan to document it well in case we hit a stumbling block. With a bit of effort and the source code I can port it to PHP. I've even toyed with the idea of keeping a fully-functional copy written in PHP while he's working in ASP.NET ;-) But I've got better things to do. Limitations are often purely percieved rather than actual I believe that's why I chose Smarty for my last project. I thought PHP limited me to keeping business logic mixed with presentation logic, but it's hardly the case. and funnily enough Smarty is actually a pretty good example of a possible PHP based solution to the problem logic seperation. When you consider that it's just another tool in your box, it works well. It's not the only way to let designers design and programmers program (Jochem is a big believer in CSS for that). Just think of it as another PLEASE WORLD: GET BEHIND CSS, AND FREE CONTENT FROM STYLE ON THE CLIENT. why because it allows the structrully mark-uped to be display more flexibly, for diff. display, aural readers, braille etc. removing the styling definitions it also allows you to specify different markup. Ever written a print version of a page? why bother when all you need do is specify alternative stylesheet(s) to use for print media. Ever heard you page say 'IMAGE' 'TABLE' 'DATA CELL' 50 odd times as a blind persons screen reader trys to make sense of your pretty new data-driven creation... where the f*** is the menu?! did you know there is even an extensive specification for markup of aural media (e.g. tone of voice, male/female, speed etc etc) In my little world I have officially declared a Good Thing. of course it leaves the problem of how to manage all those stylesheets effectively. something PHP might be able to help with. my best shot so far at seperating the style from mark and creating something (vaguely) valid (don't think the w3c validator is 100%) crossbrowser compatible (no doubt its not :-S). it quite image heavy - backgrounds, headers, graphic mouse-overs, 'quotes' etc but if you look at the HTML source you'll see its quite devoid of any 'imagery': http://www.oneworldtrade.nl/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
