Dynamic RepositoryServiceProvider from config file

[dpslwk]

As pointed out by @Hodgy in #72 the RepositoryServiceProvider is getting a bit ridiculous already.

I think we could do something with a repository config file and a foreach loop.
other than the LaravelDoctrine\ACL\Permissions\Permission entity they all follow the same pattern

[roberthunt]

My understanding is at the moment we hit the RepositoryServiceProvider class for every request regardless of the actual repositories needed to fulfil that request. For example, I wouldn't expect to need the LabelTemplateRepository when dealing with a request to register a new user.

The way around this seem to be to make use of the defer functionality that Laravel offers for service providers, this does however mean that we can only register a single binding per service provider class as a provides() method needs to be implemented indicating what class the provider binds into the container.

I think this is possible but would mean generating a service provider class per repository. I'm not sure what "cost" is incurred by eagerly binding all the repositories into the container - it may not be something to worry about at this stage but might be worth keeping an eye on.

Either way I think we can do something to simplify the binding of repositories into the container beside the repetitive code we currently have.

[dpslwk]

ok so #152 will solve the issue of a huge file by using a config file array to register our repos but I was not able to also do a dynamic deferred provider

I'm thinking we would have to have a bunch of other service providers that group sensible things together with the main one loading stuff we no is going to be needed in every request no matter what
so we might have some like
BankingRepositoryServiceProvider
GatekeeperRepositoryServiceProvider
ToolsRepositoryServiceProvider
SnackspaceRepositoryServiceProvider
RandomRepositoryServiceProvider

I could get the to work of the same configfile, but each would still have to be added to config/app.php
unless I can wrap it with the AggregateServiceProvider base but theres not docs on that yet

[roberthunt]

I've had another look at how this works and I don't think we need to worry about making the service provider deferred as the bindings themselves are actually lazy. As the actual construction of the repository is done in the closure attached to the binding it will only trigger when something injects the repository. I tested this by adding a dd() in the closure of the MetaRepository and loading /home - the closure wasn't fired, when I loaded /access-codes it was.

A deferred service provider seems to be useful when you're actually doing something expensive in register() or boot() functions. I don't think the actual registration of the bindings is that expensive, I was under the impression that it was also eagerly constructing the repositories as well which is not the case.

[dpslwk]

thats cool, so my PR to cut down the code should be all we need :)