commercemeister, Thank you for this post -- you have capture the true issue: Many times, our pages are designed in a wysiwyg editor, and we need a method of quickly converting their template into a renderable page. This is not a trivial matter, by any means. The push-back you will get is for those who are not getting their templates from a wysiwyg designer, and who haven't fought this issue. I have faced it, and I agree with this need.
I think you have laid out an excellent strategy, and appear to have sold Flexy pretty well. However, can you describe a bit more what the changes would be to Symfony? Also, when I last looked at PHPTal, it looked very nice. Is LGPL incompatible with Symfony? I haven't reviewed the licensing terms closely. I also found POT: http://pot.sourceforge.net/sf_demo/index.php?page=overview Not too crazy about using the object tag, but maybe a good option. Read the future 1.4 version supporting Javascript, AJAX and DOM... And TinyButStrong: http://www.tinybutstrong.com/description.php#raisons They claim to support wysiwyg, but not via tags. Interesting... I think this is a need that should be pursued. If you can help define the templating system, I'll help collaborate on the project. Mike On Oct 17, 3:27 pm, commercemeister <[EMAIL PROTECTED]> wrote: > Hello, > > I proposed using Flexy on the users group a few weeks > ago:http://groups.google.com/group/symfony-users/browse_frm/thread/409256... > (is this the best way to link?) > > And gave specific reasons why my company needs a templating engine > other than "php as a templating engine" > > The response was lukewarm, at best - and like here, ended up as a > discussion of many different alternatives. > > Since genshi is Python, the proposal I see here is basically "coding > from scratch" in PHP. I'm not sure that makes a whole lot of sense, > unless it is modified to take advantage of PHP + Symfony. > > (See previous posts for my bias: I want my designers, when viewing the > raw template in the browser, to see near exactly what they will get.) > > PHPTal is the closest of the PHP engines other than Flexy I have found > that meet my objectives, from looking at the docs - though I haven't > used it, and and may not for Symfony projects because of the license > terms (LGPL) - I want to stay with licenses that works with the > Symfony license. > > I can, however, see quite a lot that could be done with a Flexy / > PHPTal / Genshi "style" templating engine, that could be "native" to > symphony. > > One consensus I hear is that there is a large group of people that > don't see the need for any templating engine outside of PHP. > > Like vi, I think it is great to have and assume that Symfony will > always support straight PHP as a standard, core engine. I nod to > people with this philosophy, acknowledge the need and say "yes, we > need to keep PHP as a templating engine ... it is extremely useful, > needs to be there, and anything moving forward needs this." > > Another group needs / wants a something more, for various specific > business reasons. > > What I don't want to see happen is for Symfony to fragment again: I'm > already seeing Symfony/Propel being one "framework" that is at least > partly incompatible with Symfony/Doctrine (Doctrine used by the > "experts"?) - and requiring twice the development / support for many > plugins. > > I don't want the same to happen on the templating side. > > (As an aside ... is there any way to have at least a basic ORM > abstraction layer? ...) > > What I would like to see is a "meta" templating engine. Flexy > understands <?php ?> tags. Hence, the Flexy plugin I have kinda > working works with standard auto-generated CRUD, but you can drop down > (move up?) to the alternate tokenized syntax pretty easily. > > To make this truly seamless, though, would require some changes to > either Flexy or Symfony, so I'm not sure simple plugin-integration is > the right way to go. > > If there is, indeed, going to be new development, my partial wishlist > contains: > > - MIT-style license. > > - allow the engine to be part of the core, so I can be sure that I can > use it in distributed plugins <- I realize this is completely out of > my control, and a plugin that can co-exist with other engines is an OK > option. Just don't make it an either / or choice! > > - understanding and allow <?php ?> and current template syntax: and > allow me to turn it off in the controller or config. > > - truly "symfony aware". All templating engines I am aware of have > their own ideas for i18N, l10N, etc. I want it to use Symfony's native > functionality for this .. and any other features symfony has, like > escaping: Flexy + Symfony could escape things twice. > Helpers should be "native" and feel natural to use. > > - the generate crud tasks should be "aware" of the engine (plugin?) > > - compiling/caching of course is a must. > > - Syntax is critical. It is the reason to have an alternate template > engine in the first place, and should be well thought out and > designed. The goal is that I should be able to open up > tempalte.tpl.html in Firefox and see pretty much what I'd get as if I > rendered through the framework. To this end: > > - "tag based" - any of: > -- <tr tal:repeat="myitem myarray"> ... </tr> [PHPTal] > -- <tr flexy:foreach="a,k,v"> ... </tr> [Flexy] > -- <tr py:for="link in reversed(links)"> ... </tr> [Genshi] (though > the py:? namespace is a littler weird in php ...) > Is ok > > NOT Smarty-style, which screws up rendering and breaks lots of stuff: > <tr>{foreach item='nav' from=$navigation} ... {/foreach}</tr> > > - reasonable defaults for rendering in the editor: > <flexy:include src="header.html">Header goes here</flexy:include> > which will display "Header goes here" when you edit the template in a > WYSIWG editor - and disappears when compiled.. > > - url-rewriting: (From Flexy docs): > "When compiling the template flexy can rewrite <img src, <script src, > <a href and xul stylesheet urls. The format is "match/original:new/ > url, match/another/original:new/url" each combo is seperated by a > comma, and the colon seperates the pair. This helps previewing > templates without using the engine. > > - support for theming and sensical searching of paths within each > theme. I've seen code-snippets and a plugin(?) that provides some of > this, but haven't explored fully. The engine should address this > natively, not only for "look and feel" but taking into account the > device type as well (mobile, etc). This needs to be seriously thought > out. > > The list above is by no means exhaustive, it does cover most of the > core features that I believe are necessary in an additional symfony- > based templating engine. > > Benefit: I have 1 project with about 20+ pages. I have the site in a / > mockup/ folder for local editing, and symlinks to various templates/ > indexSuccess.html files. By carefully handling routing and image > rewriting (compiled, so production performance is not an issue), one > can browse the site in /mockup/ (statically) and /web/frontend_dev.php > and get a site that "works" in both places - without broken images, > with correct links to other files ... it just works. > > That type of rendering is what I'm after. > > I am willing / able to contribute resources to a sub-project that > meets these goals, whether it is an integration plugin for an existing > templating engine or new development. > > Regards, > > Nick > > On Oct 16, 7:22 am, "Lucas Stephanou" <[EMAIL PROTECTED]> wrote:> Hello dev's, > > > I'm here to start a thread about template system. > > > Today symfony doesn't use natively a template system to render presentation > > layer. > > IMHO, the genshi project[1], used in trac 0.11[2], is more efficient output > > generator and I'm working with it in some plugins to internal use here in my > > job. > > All php options( OPT, Smarty, Haml port) that I knew isn't simple, clean, > > and powerful, this in my opinion. > > > Well, What you think about? Is PHP a equivalent option? Start a similar > > genshi project in PHP? > > > [1]:http://genshi.edgewall.org/ > > [2]:http://trac.edgewall.org/milestone/0.11 > > > -- > > Lucas Stephanou --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/symfony-devs?hl=en -~----------~----~----~----~------~----~------~--~---
