Added presenter mapper

[Budry]

Discusion: http://forum.nette.org/en/19620-better-mapping-configuration#p135799

For easier use custom mapping implementation

with https://github.com/nette/bootstrap/pull/8

[dg]

I am not sure that own mapper is really needed. I agree that mapping can be enhanced for <module> and <presenter> placeholders, but in this case there is no need to use own mapper.

[mishak87]

I for one would use such mapper. It really enables modularity across packages and default implementation can be reused as a fallback for custom implementation.

Now I can have multiple packages sharing same <module> by convention ie. namespace:

<?php $mapping = [ 'shop' => [
    'packageA/src/Shop/Presenters',
    'packageB/src/Shop/Presenters',
// ...
] ]

For now I have to prefix each package, because using multiple directories for same <module> is not possible. From my experience using paths with multiple modules is not really scalable across packages ie. <AModule>/<AdminModule>. Sharing <module> makes things simpler.

[matej21]

:+1: But I would remove the setMapping method in IPresenterMapper interface

[Budry]

I think that use <module> and <presenter> placeholders would be good, but mapper could be usefully. Mapper has no disadvantage, has only benefits in my opinion

[Budry]

@matej21 you are rigth. I removed setMapping from interface

[enumag]

:+1: for this

[Majkl578]

:+1: I like it. It would be possible to create MapperChain, chaining multiple mappers for different modules of application (and even better, it would work greatly addons which use presenters). Maybe it would be the best to add it into Nette as well (it could be done in separate PR later).

[dg]

What is purpose of this PR? To add <module> and <presenter> placeholders? It will not help, because everybody will have to write own mapper. Implementations will be fragmented.

What is the advantage of "split" 2-methods IPresenterFactory into 2-methods IPresenterFactory plus 2-methods IPresenterMapper? Is there really such big need to create your own mappers?

[dg]

ping @Budry

[Budry]

I apologize for the delay, but I lived in the belief that this pull is dead.

Problem is that actual mapping implementation isn't really usable for specific cases. For example (from discussion) with actual mapping implementation I don't use namespaces as App\BlogModule\Account\Presenters\FrontPresenter i'm not sure if it is possible (I think that it is not possible). It would be good to be able to use a placeholder for each module (to see).

Currently I'm not sure if it necessary to change current implementation, but able to use a custom mapper can be very good and it can solved problem with specific requirements for mapping.

I can update this pull if you say that it makes sense

[dg]

To add Mapper means to add two new classes, which will be always autoloaded. Some people scream when you add only one class that is always autoloaded (even it is autoloaded only if you install this package).

To add two classes increases the complexity of the framework. I don't want to increase complexity if it solves use case for only one person. But I want to find any solution, same case as here.

So for your use case is solution to create own IPresenterFactory or descendant of default PresenterFactory.

[xificurk]

I don't want to increase complexity if it solves use case for only one person.

Actually, I would welcome this as well. It would come really handy for overriding generic presenters shipped with installed package by app-specific presenter (see https://github.com/nette/application/pull/56#issuecomment-71458691). Now the choice for us is either re-implement whole PresenterFactory with our own mapping solution, or inherit the PresenterFactory from Nette with unwanted/unused default mapping and hack over it.

[dg]

It this case it would be better to prepare an RFC and open discussion about it and we can implement it in 2.4.

[Budry]

I'm for open discussion :+1:

I don't want to increase complexity if it solves use case for only one person

I understand and I'm not saying that it is necessary implement this, but this is not only my case (for example http://forum.nette.org/cs/17194-jak-nastavit-presenter-mapping-pro-class-name-app-blablamodule-blabla-blablapresenter and were more, but now I don't find it).

This pull is very old and was created from poor application design, but still I think that current mapping implementation is too restrictive.

[dg]

What exactly you mean by "too restrictive"? Yes, it is limited, but extracting it to the new class is not solution - the new DefaultMapper wil be exactly the same restrictive as current PresenterFactory (https://github.com/nette/application/pull/16#issuecomment-48160051).

[Budry]

You are right. Separated mapper into a new class is not solutions. I think that would be better change current mapping implementation and make it less limited. Be able to use a construction similar to this

App\<module>Section\<module>\Presenters\<presenter>Presenter
:Blog:Account:Admin:default => App\BlogSection\Account\Presenter\AdminPresenter

would be very good.

I created this pull because I know a lot of people and project which implement custom PresenterFactory because they need mapping similar to example and I didn't think that implement custom PresenterFactory is good way but change only Mapper yes (it is better way in my opinion), but as I said the best solution would be change mapping implementation and if someone needs more specific way may use their own PresenterFactory

I haven't problem to close this pull and open discussion about better mapping implementation :)

[dg]

To change title is probably sufficient, here is history, or not?

[Budry]

I was not sure if this is pull a suitable place for discussion about new mapping and I wanted to create a topic on the forum

[dg]

https://forum.nette.org/cs/26116-presentermapper-ipresenterformatter-apod

[TomasVotruba]

Seems legit. What needs to be done here?