Hello,

You brought a very good argument into this discussion. In fact, you just
convinced me of that template system you proposed. Browsing the
templates without apache installed is probably the best way for the
desginer to really design the application, even before any of its PHP
code is finished.

One would have to carefully design the syntax, so the code is both short
to write and not too restricting while showing correctly in the browser.
While being short, the code should also be verbose enough to be easily
learnt and understood by designers without programming experience.

If the syntax is designed from scratch, it could be designed similar to
SQL. For example:

Example:
<div sf:select="Book from Books"> ... </div> (foreach-loop)

The rarely used <var> could be used to display any sorts of text:

Example:
<var sf:display>Name from Book</var> (displays the Name attribute)

A lot of code should be reusable/flexible like in jQuery, where you can
apply the same syntax in different situations. This is usually easier to
learn for people without programming backgrounds.

Examples:
<td sf:display>Name from Book</td>
<a href="#" sf:display>Link from Book</td>

<p sf:translate>My custom paragraph that will be translated by XLIFF</p>
<a sf:translate>My custom link that will be translated</a>
<h1 sf:translate>My translated header</h1>

One could even go as far and merge different options (like in this
example sf:display and sf:translate) and go jQuery-style with context
sensitive options:

<a href="#" sf:display>Link from Book</a>
<a href="#" sf:display>Localized text</a>

Just some thoughts.


+1 for your idea


Regards

Bernhard


Am Mittwoch, den 17.10.2007, 19:27 +0000 schrieb commercemeister:
> Hello,
> 
> I proposed using Flexy on the users group a few weeks ago:
> http://groups.google.com/group/symfony-users/browse_frm/thread/40925697e864a069/6dbc51e67bbfab8f?lnk=gst&q=Flexy#6dbc51e67bbfab8f
> (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
-~----------~----~----~----~------~----~------~--~---

Reply via email to