Move error view model generation methods to abstract controller

[fabiocarneiro]

I want those methods to be moved from the AbstractActionController to AbstractController since they're important even if you want to dispatch directly instead of having many actions (which is what i'm doing).

Otherwise, i'll have to create my own extension of AbstractController or a trait and use it in all my project controllers, which would make necessary to have a "base" module.

The tests will still pass because the methods will be still be available in AbstractActionController, since it is an extension of AbstractController. I chose not to move the notFoundAction since it is an action and should stay in AbstractActionController.

With this update, we'll be able to:

@var MvcEvent $e
$e->setResponse($this->createHttpNotFoundModel($this->response));

[Ocramius]

These could actually be moved to controller plugins... Not sure if it represents a BC break though.

[danizord]

We can move implementation to controller plugins and keep the methods as proxies for BC 👍

[Ocramius]

Good hint, @danizord!

[fabiocarneiro]

Should we keep them as proxies in AbstractActionController or AbstractController? I guess they should still be moved since it makes much more sense to have them available in AbstractController implementations.

Going further, if the method will be there, does it really make sense to have it as a controller plugin? since it can't be removed from AbstractActionController anyway?

[Ocramius]

I would keep the change as small as possible. Don't move the methods, just make them proxy through to __call

[fabiocarneiro]

But does it make sense even to move them to separate files? the methods will still be there anyway... y not moving them and forget about the plugins? what advantage would we have by moving them to plugins instead of keeping the methods there, since we can't remove them because of BC?

@Ocramius Also, do you have any code sample for that proxy behavior?

[Ocramius]

what advantage would we have by moving them to plugins instead of keeping the methods there, since we can't remove them because of BC?

The point is that you can override all of them in one shot.

Utility methods in controllers provide great additional flexibility for RAD.

We can't remove them as people may rely on parent::createHttpNotFoundModel(), but moving them and introducing new methods in classes inheriting from AbstractController is also an issue.

[Martin-P]

Could you please update the list of plugins defined in Zend\Mvc\Controller\AbstractController for IDE autocomplete? See: Zend\Mvc\Controller\AbstractController lines 26 - 43. Thanks.

[malukenho]

EOF EOL

[danizord]

👍

[Pittiplatsch]

@Ocramius:

We can't remove them as people may rely on parent::createHttpNotFoundModel()

Accessing parent::createHttpNotFoundModel() via __call() DOES work: http://3v4l.org/Cketp

[Ocramius]

@fabiocarneiro failure is at https://travis-ci.org/zendframework/zf2/jobs/42984956#L1519

[Ocramius]

@Pittiplatsch I'm just worried about subclasses overriding the method. We can remove those methods later on

[Pittiplatsch]

@Ocramius Sry, I don't exactly understand the problem. Overriding is exactly what I did in my 3v4l, isn't it?

[Ocramius]

Yes, but you can't expect the plugin manager to be always the same :-) Anyway, I'm just being very defensive here.

[Ocramius]

Note: should add @deprecated notices to those methods on merge, indicating that they are going to be moved to view helpers and not being part of the controller API anymore.

[Ocramius]

@fabiocarneiro I manually merged this PR after applying some cleanups.

develop: 2e54284