Hi,
I moved this from twig mailing list: I went through the documentation
and I am now thinking about the best
way to integrate Twig to be used with Symfony. I have these ideas:
1) Rendering templates:
I am thinking about two ways of integrating template rendering.
a) Change the default way of rendering all symfony actions using
filters or extending sfView.
b) Use $this->renderText($twig->render(... at the end of each action
or component
a) would give me better comfort, but is also more time consuming and
more code to test. b) gives backward compatibility, better control of
rendering (or setting sandbox properties) and a good chance to work
even when project is migrated to symfony 2. Also I can use some object
wrapper to shorten a bit the rendering repetitive code.
2) Storing templates:
Templates would be stored in:
apps/[app_name]/templates
plugins/[plugin_name]/templates
and named [module_name].[action_name|_component_name].html that way I
can search quickly these files in PDT IDE. I can't see any advantage
if I store templates in module/templates directory. Only disadvantage
is more letter to write when creating new template file, but I believe
I can create a macro in IDE to help with this.
3) Caching:
I would like to add caching feature to the template loader. At the
beginning of each actions would be a cache control method which would
take sfWebRequest parameters and sfUser session and cookie attributes
to decide if cached version of the template exists and render
accordingly. My idea is something similar to this:
public function executeIndex(sfWebRequest $request)
{
TwigLoader::getInstance()->useCache(array(
'category_name' => $request->getParameter('category_name'),
'order_by' => $this->getUser()->getAttribute('order_by')
), 3600);
}
This way I can control cache validity and lifetime for each action.
My idea is to have default templates in plugin directories and then
allow to overwrite the templates through backend administration, which
is for me the biggest feature of using templating engine. So the extra
code is mainly because of the security reasons and deterministic
caching.
Frantisek Troster
On 9 říj, 16:26, Fabien Potencier <fabien.potenc...@symfony-
project.com> wrote:
> Annis McKenzie wrote:
> > Hey all,
>
> > as Fabien already offered to help getting the development of a
> > sfTwigPlugin started, I'd like to ask him: What would be necessary to
> > develop this kind of a plugin? I don't know where to start, do we have
> > to write a new view layer class?
>
> > Would there be a huge difference with the programming to support sf1.2
> > AND 1.3?
>
> The view in symfony 1.2 and 1.3 is, as far as I remember, exactly the
> same. So, the plugin will work with 1.2, 1.3, and 1.4.
>
> If we need to make some simple changes to support Twig more easily in
> the symfony view system, that's also possible, but only if it does not
> break BC. That should be done fast as the feature freeze is targeted for
> the end of next week.
>
> Fabien
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
