The @View annotation can be used on class level without breaking functionality.
Or is there a particular reason we have to annotate each action?
This PR widens the scope of the annotation to allow @View on Class level for all actions.
added CLASS to @View annotation scopes
it's not quite so simple I fear. toy then also need to actually read the class level annotation and decide how that works in case of overlapping definitions
The annotation scope has been added in ef8f6cd.
This was an undocumented BC break for functionality which had been there for a while :-)
Logically the behavior should be:
This is how it already works out of the box with the widened scope.
Can you construct an example where this is not working?
I tested every combination that came to my mind and found all method-/class-level combinations working as described above. Only returning a FormTypeInterface overwrites class-level templateVar to 'form' for the method which is nice.
I came across this while updating an older project which was using Tag 0.11.0 of FOSRestBundle where i accidently annotated the class with @View aswell as all my methods in a controller. But didn't notice until now ..
After updating to master i faced this Exception:
[Semantical Error] Annotation @FOSRest\View is not allowed to be declared on
class Vendor\MyBundle\Controller\PersonController. You may only use this
annotation on these code elements: METHOD.
Turns out just adding CLASS to the scopes and annotating a class ( not every single method ) with @View . already magically provides the expected behavior and i was able to ommit a lot of method-annotations:
A quick example - automatic route generation, implicit resource names
* @FOSRest\View(templateVar="testdata", statusCode=201)
class PersonController implements ClassResourceInterface
public function newAction()
// template: Person/new.html.twig , template variable is 'form' , http status: 201
public function helloAction()
// template: Person/hello.html.twig, template variable 'testdata' , http status: 201
* @FOSRest\View("AnotherBundle:Person:get", templatevar="person")
public function getAction(Person $person)
// template: AnotherBundle:Person:get , template variable is 'person' , http status: 201
* @FOSRest\View("AnotherBundle:Person:overview", templatevar="persons", statusCode=200)
public function cgetAction()
// template: AnotherBundle:Person:overview , template variable is 'persons' , http status: 200
This can potentially really slim down controllers!
What needs to be done to get this merged ? Please provide some information.
Some functional tests?
btw Travis build failed due to Composer being older than 30days - no unit tests failing.
This is not only a great enhancement in terms of slim controllers and DRY - it has already quietly been working before 0.11 :)
ok .. i wasnt aware that things worked like this.
can you add a test case for this so that it doesnt get broken again and a doc example?
will do - currently on vacaction, gonna tackle it next week! :)
back in the game :)
maybe we should discuss wether scope-widening more annotations would make sense.
i.e. controller's having more @NoRoute methods than @Route methods could benefit.
I'm not sure wether the http method annotations ( @Get, @Put , etc... ) on class-level could make sense in some rare cases aswell. Imagine a controller handling only post requests i.e.
What's your oppinion?
If it works, then I guess its ok to widen the scope and if we do, then ideally we do it for an entire "group" of annotations and not just for some.
I don't think NoRoute makes sense at the controller level. If you don't want any route on the controller, don't import it as type rest
I think the point is whitelisting vs. blacklisting.
@stof adding NoRoute to a class having i.e. only one or two routes to be exposed but a large number of methods to be excluded would prevent having to add NoRoute to all of these methods.
I think this would come in handy sometimes.
general question - how should we test the class-level annotation behavior most intelligently? suggestions?
@nifr well you just need to add relevant classes to the Fixtures. btw class level @NoRoute only makes sense if its possible to override this with a method level annotation.
btw .. i would like to tag 0.13.0 ASAP .. so it would be great to wrap this up.
added CLASS to @View annotation scopes