Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

[Templating] Deprecate the component#21036

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Closed

Conversation

@dunglas
Copy link
Member

@dunglasdunglas commentedDec 23, 2016
edited by nicolas-grekas
Loading

QA
Branch?master
Bug fix?no
New feature?no
BC breaks?no
Deprecations?yes
Tests pass?yes
Fixed tickets#15028
LicenseMIT
Doc PRn/a

Follows#21035.

jvasseur, gesifred, and Simperfit reacted with thumbs up emojiHeahDude, jvasseur, sstok, ro0NL, and Koc reacted with hooray emojirobfrawley reacted with confused emoji
@mickaelandrieu
Copy link
Contributor

@dunglas are you sure ? The Templating component is still useful. I remember the core team wanted to remove it from framework, this didn't mean remove it from organization or deprecate it: am I wrong ?

robfrawley reacted with thumbs up emoji

@scaytrase
Copy link
Contributor

@mickaelandrieu twig is first-level citizen for about two years already. I think the purpose is to remove unneccessary abstraction layer from templating to twig in the future for 4.0

http://symfony.com/blog/new-in-symfony-2-7-twig-as-a-first-class-citizen

@mickaelandrieu
Copy link
Contributor

mickaelandrieu commentedDec 26, 2016
edited
Loading

I agree to remove abstraction from full edition, but I don't think we should deprecate the component as a component: there is life outside of full edition! And regarding the download stats we can already say that the components are more used outside the full edition :)

@wouterj
Copy link
Member

Do we want to deprecate the PHP templating system or the Templating component? Those are 2 very different things. Imo, the templating component/abstraction still makes sense. The PHP templating might be deprecated though, as the general opinion in the community seems to be in favor of removing it.

Koc reacted with thumbs up emoji

@nicolas-grekasnicolas-grekas added this to the3.3 milestoneDec 26, 2016
@mickaelandrieu
Copy link
Contributor

@wouterj 👍 yes, as we didn't use PHP templating anymore, it makes sense to remove every PHP template from FrameworkBundle.

I have a use case in favor of keeping Templating component: actually, PrestaShop project is using both Smarty and Twig engines.

For now, integrators can "only" use Smarty to make their own themes and plugins, but the idea is to migrate everything to Twig, if we can do it smoothly, ie without break all the things again. Note we are still using Symfony2, but this kind of deprecation can stop a future migration to Symfony3.

I guess PHPBB team may have the same needs too.

To sum up what I suggest:

  • remove every use of Templating component from framework
  • keep the component alive
  • Remove/reword some cookbooks

Wdyt ?

@scaytrase
Copy link
Contributor

I think keeping it alive (like it was done withAsseticBundle which is still useful after removing from standard) is good idea in any case

robfrawley reacted with thumbs up emoji

@nicolas-grekas
Copy link
Member

Note that even deprecated, the component will be maintained until the end of 3.4LTS support, that means another 4 years from now.

mickaelandrieu, CoolGoose, apfelbox, and starticketjenkins reacted with hooray emoji

@mneuhaus
Copy link

Just a +1 from a "bystander" for keeping general support for alternative templating engines, i'm currently working on bringing TYPO3's Fluid templating engine to Symfony :)

Simperfit and robfrawley reacted with thumbs up emoji

@dunglas
Copy link
MemberAuthor

dunglas commentedJan 28, 2017
edited
Loading

@symfony/deciders Should we keep this component indefinitely even if it isn't integrated in FrameworkBundle anymore or should we deprecate it?

@mickaelandrieu
Copy link
Contributor

Components have a life outside the framework :)

Regarding the download statistics, the framework only represent10℅ of the Symfony ecosystem.

Also, I've never seen such big effort to maintain this component: so why do you want to deprecate it?

We don't ask new features from Core team, only to keep up to date and report security issues if any :/

@dunglas
Copy link
MemberAuthor

dunglas commentedJan 28, 2017
edited
Loading

As pointed out by@nicolas-grekas, this component will still be supported 4 years. If even Symfony itself doesn't use it, and if it doesn't allow anymore to integrate other template engines with Symfony ; I don't get the point of using this component in a third party project.

@robfrawley
Copy link
Contributor

robfrawley commentedJan 28, 2017
edited
Loading

If I correctly understand the intent of this PR, it is removing the ability to easily integrate other templating engines with Symfony. If thatis the case, this PR is a firm 👎 from me. As I understand it, this component doesn't require a huge amount of overhead in terms of maintenance, so what exactly is the intention or motivation for removal of the component@dunglas?

mneuhaus reacted with heart emoji

@mickaelandrieu
Copy link
Contributor

@dunglas it will be up to component' users to make the bridge with Symfony framework if they want to use it in a "framework context" if the core team doesn't want to support this feature anymore.

But if the component is deprecated, the right answer for "can we use PHP/Smarty/Blade/xXx in Symfony (framework)" will become "no" instead of "yes but need some work".

This is a really big difference from technical & business point of view!

Also, deprecate a component because it's not used in framework may be seen as a very bad news: should we expect a deprecation of every dependency removed from FrameworkBundle?

@fabpot
Copy link
Member

@mickaelandrieu Stop the FUD :)

@mickaelandrieu
Copy link
Contributor

really ? o_O meh do what you want, I'm done.

@javiereguiluz
Copy link
Member

I like the idea of Symfony supporting only Twig out-of-the-box ... and I agree with deprecating this component.

However, just to know how to update the Symfony Docs, could you please tell me if it will be possible to use PHP/Smarty/Blade/... with Symfony after this change and a general overview of how to achieve that? Thanks!

@wouterj
Copy link
Member

Well, as Symfony is 100% DIC based: Create asmarty service and do$this->get('smarty')->render(...) in the controller.

When this component is not deprecated, you would create aSmartyEngine and you can do$this->render(...) in the controller.

*
* @author Fabien Potencier <fabien@symfony.com>
*
* @deprecated The DelegatingEngine class will be removed in Symfony 4.0. You should use Twig instead.

Choose a reason for hiding this comment

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

the annotations should be rewritten as
@deprecated since version 3.3, to be removed in 4.0. You should use Twig instead.
this will make notices raised by DebugClassLoader a bit better/consistent.

@nicolas-grekas
Copy link
Member

Status: needs work

@nicolas-grekas
Copy link
Member

@fabpot can you share some hints about the direction you'd like this to take?

Tobion added a commit to symfony/symfony-standard that referenced this pull requestOct 1, 2017
This PR was merged into the 3.4 branch.Discussion----------Remove templating layer from standard editionAlso works without it as `\Symfony\Bundle\FrameworkBundle\Controller\ControllerTrait::render` will just use twig directly then. Whether we deprecate or not deprecate the templating layer (symfony/symfony#21036) we should still promote not to use it by default.Commits-------c243457 Remove templating layer from standard edition
@fabpot
Copy link
Member

I'm closing this one as I don't think there is a need to deprecate this component, just the integration with framework bundle, which is done in another PR.

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@nicolas-grekasnicolas-grekasnicolas-grekas left review comments

Assignees

No one assigned

Projects

None yet

Milestone

3.4

Development

Successfully merging this pull request may close these issues.

10 participants

@dunglas@mickaelandrieu@scaytrase@wouterj@nicolas-grekas@mneuhaus@robfrawley@fabpot@javiereguiluz@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp