[WIP] Explicitly Declare Twig "Paths", deprecate old syntaxes #13928

weaverryan · 2015-03-15T02:02:11Z

Q	A
Bug fix?	no
New feature?	yes
BC breaks?	no
Deprecations?	yes
Tests pass?	TODO
Fixed tickets	n/a
License	MIT
Doc PR	TODO

Hallo!

Comments warmly appreciated. Actually, that's the whole point of pushing this early :).

Deprecated the AcmeDemoBundle:Foo:default.html.twig syntax.
Deprecated the automatic @AcmeDemo-style Twig namespace functionality
Added a way for bundles to explicitly add a namespaced path. Usage:

use Symfony\Bundle\FrameworkBundle\Bundle\Bundle;

class FOSFooBundle extends Bundle
{
    public function __construct()
    {
        $this->addTwigPath(__DIR__.'/Resources/views', 'FOSFooBundle');
    }
}

then (because this is how Twig paths already work):

// renders @FOSFooBundle/Resources/views/product/list.html.twig
return $this->render('@FOSFooBundle/product/list.html.twig');

This is a lot more flexible than the "automatic" mapping and a lot more clear (because it's explicit) . It still maintains the "fallback" functionality (e.g. put something in app/Resources/AcmeDemoBundle/... to override) and everything works the same if the bundle decides to use a namespace that matches its bundle name.

This is a small step to removing some "automatic" magic that bundles give us. I'd like to see things more explicit in the bundle - e.g. $this->addPublicDirectory(__DIR__.'/Resources/public', 'fos_foo') and even translation resource loading, validation metadata, etc.

TODO

The TemplateFinder (used only by the TemplatePathsCacheWarmer) is currently (before this PR) broken, as it doesn't take into account Twig namespace paths.
These new paths are "stuck" inside Twig. So if I want to get the location of some non-Twig template (fake code $templateLocator->find('@FOSFooBundle/smarty/ohno.tpl') - I can't do that. If we agree, we can move the "path" functionality into some templating service that Twig uses.
Tests
Docs

Thanks!

@fosuser

…() method This is meant to replace the @fosuser Twig syntax AND the FosUserBundle:Register:register.html.twig syntax. Though, those haven't been deprecated yet

henrikbjorn · 2015-03-15T09:56:09Z

👍

wouterj · 2015-03-15T10:06:10Z

src/Symfony/Bundle/FrameworkBundle/Bundle/Bundle.php

+    }
+
+
+}


missing final new line feed :)

wouterj · 2015-03-15T15:24:53Z

Just some thoughts on this PR:

There always should be a default fallback, as it would mean lots of extra boilerplate code.

This again makes me think about Puli, why not integrate that in Symfony? It would bring a nice interface for handling all these things:

class AcmeBlogBundle extends Bundle
{
    public function __construct()
    {
        $this->addResource('/acme/blog-bundle/views', __DIR__.'/Resources/views');
        $this->addResource('/acme/blog-bundle/translations', __DIR__.'/Resources/translations');

        $this->bindResources('/acme/blog-bundle/translations/*.xliff', 'symfony/translations');
    }
}

This approach means things get bound to the Bundle a lot. That's not something I like (in fact, I like the opposite...). This is were Puli can help too btw, as it allows you to define resources in your composer.json file, meaning that it is not required to do this in the Bundle class.

javiereguiluz · 2015-03-16T09:00:39Z

@weaverryan 👍 I like this proposal.

@wouterj I think this proposal is mainly aimed at third-party bundles, so answering your concerns:

There always should be a default fallback, as it would mean lots of extra boilerplate code.

For application bundles we don't need to provide a default fallback because, in the first place, you should store the templates where they suppose to be: app/Resources/views/

Why not integrate Puli that in Symfony?

Currently, my main concern about integrating Puli into Symfony is not technical. Bernhard, our dear Symfony fellow and Puli author, seems to have abandoned the Symfony community. If that's true, this integration cannot happen because Symfony only integrates things if their authors are closely and actively related to Symfony.

This approach means things get bound to the Bundle a lot.

If I'm right and this is mainly aimed for third-party bundles, this is not a problem but a good thing.

wouterj · 2015-03-16T11:28:40Z

Currently, my main concern about integrating Puli into Symfony is not technical. Bernhard, our dear Symfony fellow and Puli author, seems to have abandoned the Symfony community. If that's true, this integration cannot happen because Symfony only integrates things if their authors are closely and actively related to Symfony.

Let's also take into consideration that:

Bernhard has, by far, wrote the most code after Fabien
Puli currently already has a SymfonyBundle, SymfonyBridge and Puli Symfony Edition. All three actively maintained
Symfony already integrates packages in core of which the authors are not that actively related to Symfoy (egulias/email-validator, ocramius/proxy-manager, doctrine, assetic, monolog).
Puli seems to become the standard to use for resource location. It seems very logical for big frameworks like Symfony to use the defacto standards. In fact, the thing I've always admired about Symfony is the usage of these type of third party libraries.
Puli - just like Assetic, Composer and some more libraries - are created based on discussions in the Symfony community. They all have grown to big libraries and they all are integrated into Symfony

weaverryan · 2015-03-24T01:04:06Z

FYI - I'm pausing on this only so that I can investigate the Puli approach. Puli is trying to solve some of the same problems that we have, and Bernhard has already promised to help let me bother him :). But, I'm very committed to solving how we setup resource paths and overrides before later this year.

Cheers!

webmozart · 2015-03-24T15:10:16Z

seems to have abandoned the Symfony community

Just for the record, I haven't :) I just have been very busy over the last months, otherwise Puli wouldn't be nowhere near where it is now. My original goal was always to build a tool to solve the resource issues we have in Symfony, while fixing the same issues for the PHP community as a whole.

So yes, I will work on Puli's integration in Symfony and I will also return to work on my usual topics. But I could definitely need help, as I'm still just one person. :)

hhamon · 2015-03-24T23:33:43Z

Really nice PR, I like it!

xabbuh · 2015-09-24T06:35:11Z

While I think that it is a good idea to let bundle explicitly register template resources, I am not convinced that removing the existing "magic" is really needed. This would now force most developers to register the "default namespace" again (I guess most people do want to use that).

weaverryan · 2015-09-26T20:08:40Z

@xabbuh yep, this PR is too much. I am still interested in deprecating the FooBundle:Bar:baz.html.twig syntax in favor of something simpler, but I'm not sure right now and this won't make it in for 2.8 anyways.

weaverryan added 4 commits March 14, 2015 20:15

Adding the new Bundle Framework class with a working addTwigNamespace…

31c4eef

…() method This is meant to replace the @fosuser Twig syntax AND the FosUserBundle:Register:register.html.twig syntax. Though, those haven't been deprecated yet

Adding some deprecations

03322b2

Deprecating the @ACMEDemo Twig path namespace for an AcmeDemoBundle

793fc32

Fixing error if the app/Resources override directory didn't exist

0325692

wouterj reviewed Mar 15, 2015
View reviewed changes

src/Symfony/Bundle/FrameworkBundle/Bundle/Bundle.php

}

}

Copy link

Member

wouterj Mar 15, 2015

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

missing final new line feed :)

weaverryan closed this Sep 26, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

[WIP] Explicitly Declare Twig "Paths", deprecate old syntaxes #13928

[WIP] Explicitly Declare Twig "Paths", deprecate old syntaxes #13928

Uh oh!

weaverryan commented Mar 15, 2015

Uh oh!

henrikbjorn commented Mar 15, 2015

Uh oh!

wouterj Mar 15, 2015

Uh oh!

wouterj commented Mar 15, 2015

Uh oh!

javiereguiluz commented Mar 16, 2015

Uh oh!

wouterj commented Mar 16, 2015

Uh oh!

weaverryan commented Mar 24, 2015

Uh oh!

webmozart commented Mar 24, 2015

Uh oh!

hhamon commented Mar 24, 2015

Uh oh!

xabbuh commented Sep 24, 2015

Uh oh!

weaverryan commented Sep 26, 2015

Uh oh!

Uh oh!

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Uh oh!

[WIP] Explicitly Declare Twig "Paths", deprecate old syntaxes #13928

[WIP] Explicitly Declare Twig "Paths", deprecate old syntaxes #13928

Uh oh!

Conversation

weaverryan commented Mar 15, 2015

TODO

Uh oh!

henrikbjorn commented Mar 15, 2015

Uh oh!

wouterj Mar 15, 2015

Choose a reason for hiding this comment

Uh oh!

wouterj commented Mar 15, 2015

Uh oh!

javiereguiluz commented Mar 16, 2015

Uh oh!

wouterj commented Mar 16, 2015

Uh oh!

weaverryan commented Mar 24, 2015

Uh oh!

webmozart commented Mar 24, 2015

Uh oh!

hhamon commented Mar 24, 2015

Uh oh!

xabbuh commented Sep 24, 2015

Uh oh!

weaverryan commented Sep 26, 2015

Uh oh!

Uh oh!

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.