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

More "id" => type hints / autowiring changes#7883

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

Merged
weaverryan merged 1 commit intosymfony:masterfromweaverryan:more-types
May 10, 2017
Merged

More "id" => type hints / autowiring changes#7883

weaverryan merged 1 commit intosymfony:masterfromweaverryan:more-types
May 10, 2017

Conversation

@weaverryan
Copy link
Member

Hi guys!

I'm going through the docs to update things to the 3.3 features: autowiring, serviceresource loading, etc. This is just another step in this fairly significant change, so thoughts are warmly welcomed (and review is needed!)

Thanks!

GuilhemN reacted with thumbs up emoji
Copy link
Contributor

@GuilhemNGuilhemN left a comment

Choose a reason for hiding this comment

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

First quick review ☺

And then configure ``twig.exception_controller`` using the controller as
services syntax (e.g. ``app.exception_controller:showAction``).
$$container->autowire(CustomExceptionController::class)
Copy link
Contributor

Choose a reason for hiding this comment

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

Typo

http://symfony.com/schema/dic/services/services-1.0.xsd">
<services>
<defaultsautowire="true"autoconfigure="true" />
Copy link
Contributor

Choose a reason for hiding this comment

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

Autoconfigure should be enabled in the yaml file or removed here imo

use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\HttpFoundation\Response;
use Sensio\Bundle\FrameworkExtraBundle\Configuration\Route;
use AppBundle\Service\HelloService;
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't use statements be ordered ?

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

I actually don't know, I didn't see anything (looked quickly) in the docs contributor page, but I could be wrong

Copy link
Contributor

Choose a reason for hiding this comment

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

Me neither but I often see them ordered in symfony's code.

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

Ah, theydo follow that standard in core. I suppose we could do, but I'll worry about that later ;)

GuilhemN reacted with thumbs up emoji
# ...
AppBundle\ArgumentResolver\UserValueResolver:
# arguments is not needed if you have autowire above under _defaults
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't we have a_defaults section then ?

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

This is the balance I'm thinking about a lot. We have some options:

  1. Assume the user has the out-of-the-box_defaults settings, withautowire andautoconfigure. In that case, all code examples like this one are super simple

  2. Don't assume the user has the correct_defaults, and show it at the top of every code block (or, add some comment like this one).

This is really a global decision to make - I'm already solving it slightly different in different places, as I'm not 100% sure.

Copy link
Contributor

Choose a reason for hiding this comment

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

I personally prefer having it everywhere, this would limit situations hard to debug for new comers.

Copy link
Member

Choose a reason for hiding this comment

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

A while ago I agreed with Ryan's idea ... but lately I'm aligning with Guilhem's idea.

Imagine that you land in this page and you see that message:

"arguments is not needed if you have autowire above under _defaults"

Well ... which "above" are we talking about? Which "_defaults" (whatever that is) are we talking about? etc.

This is truly critical because it's not only for newcomers ... but also for"newcomers to the new DI features" (I'm one of those 😊 ).

But of course Ryan is right and we can't add this continuously ... at least not by hand. Would some global include or custom directive help us automating this?

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

I don't mind putting it everywhere :). I just want the absolute best message. My last commit - sha:ab4de02 - gives a uniform handling of this (for the files in this PR).
The big risk of confusion now is people thinking that they need to add_defaults to their file (e.g. so they have 2_defaults) or make their_defaults look exactly like our's (so, removepublic andautoconfigure). I'm interested in using thediff type for this (there's not aton of highlighting), but I really want#7806 first (if my new comment is possible, it would be AMAZING!). I haven't seen@wouterj in a bit though... I'm trying to ping and bother him :)

And then configure ``twig.exception_controller`` using the controller as
services syntax (e.g. ``app.exception_controller:showAction``).
$$container->autowire(CustomExceptionController::class)
setArgument('$debug', '%kernel.debug%');
Copy link
Contributor

Choose a reason for hiding this comment

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

Typo

instance. Using the Service Container, you can configure Symfony to construct
a ``HelloService`` object properly:
Next, make sure that your new class is registered as a service. If you use
:doc:`autowiring</service_container/autowiring>` (enabled by default), this is easy:
Copy link
Contributor

Choose a reason for hiding this comment

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

I would precise that it's "enabled by defaultin the standard edition"

WSDL document can be retrieved via ``/soap?wsdl``.

..code-block::php
request. BEcause ``indexAction()`` is accessible via ``/soap``, the WSDL document
Copy link
Contributor

Choose a reason for hiding this comment

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

Typobecause


// src/AppBundle/FileUploader.php
namespace AppBundle;
// src/AppBundle/Service\FileUploader.php
Copy link
Contributor

Choose a reason for hiding this comment

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

Typo


// ...
public function newAction(Request $request)
public function newAction(Request $request, FileUploader $fileUploader)
Copy link
Contributor

Choose a reason for hiding this comment

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

What about adding a use statement forRequest too?

class:Acme\SoapBundle\Services\HelloService
arguments:['@mailer']
_defaults:
# be sure autowire is enabled
Copy link
Contributor

Choose a reason for hiding this comment

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

autowiring?

public function findOneByIdJoinedToCategory($productId)
use Doctrine\ORM\EntityManagerInterface;

public function findOneByIdJoinedToCategory($productId, EntityManagerInterface $em)
Copy link
Contributor

Choose a reason for hiding this comment

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

This one should be reverted, it's a repository 😉

<services>
<serviceid="my.listener"class="AppBundle\EventListener\SearchIndexer">
<!-- ... --
Copy link
Contributor

Choose a reason for hiding this comment

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

missing closing>


use Doctrine\Common\Persistence\ManagerRegistry;

class UserController extends Controller
Copy link
Contributor

Choose a reason for hiding this comment

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

Shouldn't we begin usingAbstractController?

Copy link
MemberAuthor

Choose a reason for hiding this comment

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

I've been usingController everywhere to ease the transition to the "type" based model. I think if we switch to it too fast, we'll have problems with people doing$this->get('...') while reading blog posts, README's, etc and it not working. And there's really not much profit in usingAbstractController.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ok 👍

// ...
$storageDefinition = new Definition(PdoSessionHandler::class,array(
$container->register(PdoSessionHandler::class)->setArguments(array(
Copy link
Contributor

Choose a reason for hiding this comment

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

I would add a line break here

// ...
$storageDefinition = new Definition(PdoSessionHandler::class,array(
$container->register(PdoSessionHandler::class)->setArguments(array(
Copy link
Contributor

Choose a reason for hiding this comment

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

same here

use Symfony\Bundle\FrameworkBundle\Controller\Controller;
use Symfony\Component\HttpFoundation\Request;
use Symfony\Component\Security\Core\Encoder\UserPasswordEncoderInterface;
use Doctrine\ORM\EntityManagerInterface;
Copy link
Contributor

Choose a reason for hiding this comment

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

order?

# be sure autowire is enabled
autowire:true
# load services from the Service directory
Copy link
Member

Choose a reason for hiding this comment

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

Not sure, but:

# load services from the Service directory

-->

# add Service/ to the list of directories to load services from

If your methods are *not* called when an exception is thrown, double-check that
you're:ref:`loading services<service-container-services-load-example>` from
the ``EventSubscriber`` directory and have:ref:`autoconfigure<services-autoconfigure>`
enabled. You can also manually tag with ``kernel.event_subscriber``.
Copy link
Member

Choose a reason for hiding this comment

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

[...] tag with ``kernel.event_subscriber``

-->

[...] add the ``kernel.event_subscriber`` tag.

I know both look the same, but to me the second is easier to understand what should I do to fix this issue.

# ...
AppBundle\ArgumentResolver\UserValueResolver:
# arguments is not needed if you have autowire above under _defaults
Copy link
Member

Choose a reason for hiding this comment

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

A while ago I agreed with Ryan's idea ... but lately I'm aligning with Guilhem's idea.

Imagine that you land in this page and you see that message:

"arguments is not needed if you have autowire above under _defaults"

Well ... which "above" are we talking about? Which "_defaults" (whatever that is) are we talking about? etc.

This is truly critical because it's not only for newcomers ... but also for"newcomers to the new DI features" (I'm one of those 😊 ).

But of course Ryan is right and we can't add this continuously ... at least not by hand. Would some global include or custom directive help us automating this?

# be sure autowire is enabled
autowire:true
# load services from the Service directory
Copy link
MemberAuthor

Choose a reason for hiding this comment

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

I like your's better... at the very least because it has the important word -Service earlier.

public function findOneByIdJoinedToCategory($productId, EntityManagerInterface $em)
public function findOneByIdJoinedToCategory($productId)
{
$query = $em->createQuery(
Copy link
Contributor

Choose a reason for hiding this comment

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

Should be fixed now 😉

@weaverryanweaverryan merged commite1d36e6 intosymfony:masterMay 10, 2017
weaverryan added a commit that referenced this pull requestMay 10, 2017
This PR was merged into the master branch.Discussion----------More "id" => type hints / autowiring changesHi guys!I'm going through the docs to update things to the 3.3 features: autowiring, service `resource` loading, etc. This is just another step in this fairly significant change, so thoughts are warmly welcomed (and review is needed!)Thanks!Commits-------e1d36e6 Going through more chapters to use types and autowiring
@weaverryanweaverryan deleted the more-types branchMay 10, 2017 09:57
Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@javiereguiluzjaviereguiluzjaviereguiluz left review comments

+1 more reviewer

@GuilhemNGuilhemNGuilhemN left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

No one assigned

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@weaverryan@javiereguiluz@GuilhemN@carsonbot

[8]ページ先頭

©2009-2025 Movatter.jp