RFC: Refactoring nette/application dependencies

I was thinking about using Presenters & Controls with a different routing library. No support for that?

No. The IRouter interface is very general, use adapter pattern if necessary.

@Milo Good question! A general rule of DI is that nothing should depend on DI container.

Presenter has already been refactored by @DavidGrudl to have DI\Container as optional dependency only. We may remove the dependency entirely or keep it as optional.

PresenterFactory is a bit tricky. It currently has two responsibilities:

1. Mapping between Application\Request::getPresenterName() and class name.
2. Creating presenter instances

The first responsibility is OK, only the second one causes trouble. What PresenterFactory should receive instead of DI\Container is a list of factories / callbacks (one for each presenter). Building of the list will be responsibility of someone else. In our case it will be most likely a compiler extension. And yes, that would require all presenters to be registered as services. We may probably figure out some way to keep the registration optional. Although I'm not sure whether we really want to make it optional (registering it has multiple advantages).

Last edited by Jan Tvrdík (2014-11-02 12:47)

I've updated the RFC to mention impact on namespaces.

Last edited by Jan Tvrdík (2014-11-04 22:56)

@HonzaMarek Yes. The problem is that PresenterFactory does not creates the instances itself but delegates the responsibility to DI container. Which is wrong.

Last edited by Jan Tvrdík (2014-11-03 13:15)

@JanTvrdík actually, I think we should go even further and not even create instances using DIC (by the createInstance method), but have all presenter registered in DIC and then have them created using the DIC properly.

I would love to see this RFC going somewhere!

Routing can IMHO operate with simple array

Why not move Nette\Application\Request to nette/routing as suggested in the original proposal? Because it's too closely related to Nette\Application? It seems a bit strange to replace this

return new AppRequest(
	$presenter,
	$httpRequest->getMethod(),
	$params,
	$httpRequest->getPost(),
	$httpRequest->getFiles(),
	array(AppRequest::SECURED => $httpRequest->isSecured())
);

with this

return [
	'presenter' => $presenter,
	'method' => $httpRequest->getMethod(),
	'params' => $params,
	'post' => $httpRequest->getPost(),
	'files' => $httpRequest->getFiles(),
	'flags' => array(AppRequest::SECURED => $httpRequest->isSecured())
];

UI can be moved to new package, but it is not so easy, because there are some dependencies in LinkGenerator or Application etc.

That's why I wanted LinkGenerator to look more like Nextras LinkFactory.

Dependency on nette/reflection (…) I'd like to remove it in future, but it is BC break.

As long as users can override getReflection() in BasePresenter it is easy to fix.

To create package micro-fw that will contain only MicroPresenter.php is useless.

I disagree with it being useless, although it is currently not as important.

NPM installs tons of packages.

NPM is bad example. It's problem are not small packages (which result in having a lot of them), but having tons of packages which do pretty much the same. So every time you install some NPM package, you end-up with multiple promise implementations, multiple process abstraction, tons and tons of utils packages and even more packages that I don't even understand why they exist in the first place.

you will have installed less number of packages (for you very rare usecase, but majority will have to install more packages for standard use.

Yes, that is good point. Although I would say that not using Application\UI is not that rare and we should educate people (this RFC is one of many steps) to not use Application\UI (e.g. for API or CLI) more.

ad 2.4 vs 3.0: currently I have no release plan

I don't care as much about the version number as about the probability that it would be merged if I started working on this.

David Grudl wrote:
ad application: nette/application is closely tied to HTTP, so it is not suitable to be used in CLI. It could be renamed to nette/web-application and new nette/cli-application could be created, but more realistic is to have nette/application and symfony/console.

I'd love to have web-application and cli-application. It could be next generation of framework based on simple commands. Just nette way.