As PHPView remains a embedded engine accessible via a simple option, the "template versus plain PHP" is meaningless.
The real question in my opinion is : "why Twig ?" OK, we know why, it's because Symfony's team (or Fabien only ?) wrote it and wants to use it. OK, that's a point. But why don't you rely on a already-made engine ? Like Smarty, TinyButStrong, PHPLib, or any other aged template engine that has proven its reliability, power, extensibility, or whatever is the main criteria to decide which engine to include. Twig is nice and everything, but it will never be as powerful as Smarty (including community-plugins), neither will it be wysiwyg- compatible as TBS, or lightweight as PHPLib+cache. The use of a template engine is fully positive in my opinion, but it's just like the Mailer engine, it should be a third-party library. On 22 sep, 14:24, Fabien Potencier <fabien.potenc...@symfony- project.com> wrote: > On 9/22/10 1:13 PM, Jordi Boggiano wrote: > > > On 22.09.2010 12:51, Stefan Koopmanschap wrote: > >> But again, the option to switch to plain PHP (or another template > >> engine, for those that want/need another template engine) should still > >> exist for the more advanced users. > > > A decent option maybe for maximized performance, would be to have a > > Twig-only view layer replacing the current Templating component, and > > then keep the Templating component in the sources so it can be just > > enabled via config value, and that one would still default to php > > templates or allow any renderer to be used.. > > > But that could mean you would lose the ability to use most of the > > Bundles that come with templates. > > Why? If you want to use PHP as your templating engine, you will need to > use a *different* templating service; you won't *replace* the Twig one. > So, all bundles will still work as expected. The only thing is that if > you have a *global* layout for all bundles (in your app/ directory), you > will need to have two versions of it: one for Twig and one for PHP. > That's the only downside I can see. > > Fabien > > > It's clear looking at the past that > > > > > the default engine is what will drive 99% of the opensource code, shared > > plugins etc. So it becomes very difficult to avoid it, much like it's > > tricky to use non-PHP templates in sf1 (afaik). > > > Cheers -- If you want to report a vulnerability issue on symfony, please send it to security at symfony-project.com You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to symfony-devs@googlegroups.com To unsubscribe from this group, send email to symfony-devs+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en