[RFC] Narrow the bundle responsibilities

[phansys]

With this RFC I want to propose to narrow the bundle responsibilities in order to keep them focused on what I think is its main goal: scheduling commands.
IMHO, all other responsibilities like providing an web UI (routing, controllers, views, etc) must be moved outside this bundle in order to keep its purpose as clean as possible. Obviously, these pieces of code could be handled with a new dependency which could be listed at "suggest" directive in composer.json.
The reasoning and the concern behind this proposal is to avoid installing dependencies when they are not actually required, allowing the users to be in control of what they really need. By instance, why should I install "symfony/security-bundle" if my application isn't secured? Even, the model could be not implemented here with its entities. This implementation should be responsibility of the consumer. While this bundle could provide a base model to ease the implementation on the consumer side, the only restriction should be the one exposed by its interfaces.

I'd like to hear about your opinions and concerns.
Thank you in advance.

[j-guyon]

Hi,

Thank you for this thread, which will allow me to give you my opinions on these topics.

let's separate the two mains topics:

Remove model implementation from the bundle (provide Interface or SuperMappedClass only)

This topic has been requested a few times (especially in #11).
I would rather favor this change, with an approach similar to FosUserBundle.

However, I have not push this as a priority because unlike FosUserBundle, the notion of "commands" is further away from the business layer, and then wont require any customization on most projects.

If someone is willing to work on a PR (and its unit tests ;) ), I'm interested.

Separation of task and interface management

I agree on the principle, but I am not sure that this approach is relevant on a bundle of this size.

The two mains features of the bundles are currently the interface and the management of the execution priorities.
I think it will needs more features in these two parts to justify such a separation.

Actually, I'm not sure that someone who does not need the user interface will have enough utility to this bundle.

That beeing said, I agree that we must minimize the dependencies of the bundle to make its installation easier.

Note that in the next release, the following dependencies have been removed from composer.json or moved to "require-dev":

• sensio/framework-extra-bundle
• symfony/security-bundle

[wasinger]

I would like to have the possibility to manage (list/add/edit/remove/enable/disable) cronjobs by console commands, similar to how it works in cron/cron-bundle.

A first step towards this would be to refactor the ScheduledCommand entity handling code from the Controller actions into a new ScheduledCommandManager service class. Both Controller actions and commands would then just call the methods of the manager class. This would also lead to a looser coupling of the Web UI (and possible future split of the web UI into a separate bundle).