Refactoring nette/application dependencies
This RFC proposes to split nette/application into 4 packages and reduce their dependencies.
Currently the nette/application contains the following responsibilities:
- Routing (
- Application life-cycle (
- UI layer (
- Micro framework (
Among the dependencies is
Note that the dependency on
nette/di will be entirely
nette/routing package will be moved to new namespace
This RFC targets Nette
Impact on backward compatibility
This breaks all packages which depend on
and require anything from UI layer. We can possibly workaround this by creating
one more package but I recommend not doing so.
- You can use routing independently.
- You can use micro-framework without installing tons of stuff you do not need
- Cleaner dependencies
- Names of the 3 new packages.
- New name for
- Updated “Proposed state” section to mention impact on namespaces.
- Added new open question regarding new name for
Last edited by Jan Tvrdík (2014-11-02 14:52)
@Milo Good question! A general rule of DI is that nothing should depend on DI container.
Presenter has already been refactored by @DavidGrudl to
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
- Mapping between
Application\Request::getPresenterName()and class name.
- 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
Last edited by Jan Tvrdík (2014-11-02 12:47)
- Generous Backer | 731
Application\Request really be part of routing? I think
the general router should map between
Http/Request and some bag
(array?) of parameters. Then there would be some bridge between routing and
application that would map these parameters (among them method, presenterName,
2015 Summer Status Update
PresenterFactoryno longer (since Nette 2.3) depends on DIC. Good job!
- All presenters are now (since Nette 2.3) registered in DIC. Good job!
- It is currently being discussed whether presenters (in general) can and should be autowired.
- RFC now targets Nette 2.4
This is still something I want to do. I once again work on a web application without HTML interface. Therefore I need to have installed the following packages even though they are useless for me.
nette/application-ui(as part of
nette/micro-fw(as part of
@DavidGrudl Would you accept this for Nette 2.4 or do we need to wait for 3.0?
- David Grudl
- Generous Backer | 7166
Routing should be moved to new package
nette/routing, but it
must be independent on
nette/application should depend on
not vice versa. Routing can IMHO operate with simple array.
UI can be moved to new package, but it is not so easy, because there are some
To create package
micro-fw that will contain only
MicroPresenter.php is useless.
nette/reflection exists only for back
compatibility, due to
I'd like to remove it in future, but it is BC break.
nette/security will be needed (maybe) due to https://github.com/…ation/pull/4.
The fact that you need to have installed packages that you don't need is (unfortunately) normal. NPM installs tons of packages. After splitting into more packages you will have installed less number of packages (for you very rare usecase, application without UI), but majority will have to install more packages for standard use.
ad 2.4 vs 3.0: currently I have no release plan.
Routing can IMHO operate with simple array
Why not move
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()) );
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.
Dependency on nette/reflection (…) I'd like to remove it in future, but it is BC break.
As long as users can override
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
- Generous Backer | 7166
ad router: only
$params are needed. The
can be extracted from
Everything else is direct copy from
Nette\Http\Request. So routing
can be really only about Http\Request → params and params → URL.
nette/router should somehow solve current shortcomings, like
$refUrl parameter, using modules, enabling https, etc.
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
could be created, but more realistic is to have
ad merge: of course I would merge it.
- Nette Core | 1039
David Grudl wrote:
nette/applicationis closely tied to HTTP, so it is not suitable to be used in CLI. It could be renamed to
nette/cli-applicationcould be created, but more realistic is to have
I'd love to have
cli-application. It could be next generation of framework based on
simple commands. Just nette way.