Big config refactoring

[wouterj]

This time, I added the real Xml and Yaml FileLoaders (will be moved to Testing component tonight). This resulted in some errors when using XML: symfony/symfony#8630

This PR fixes all those errors and with that, it also refactored the complete navigation:

• added a route_stacks/route_stack node to content_path
• put options in options

This will also help to move to the config suggested by @dantleech: #35 (comment)

To see how the current XML and Yaml config files look, take a look at the files.

Q	A
Bug fix?	yes
New feature?	no
BC breaks?	yes
Deprecations?	no
Tests pass?	yes
Fixed tickets	-
License	MIT
Doc PR	tbd

[dantleech]

This is a route stack (singular) - I think

[wouterj]

no, it's a list of stacks. It's only one stack, yes, but it's still a list. :) Using route_stack would require putting the classname in a node 'class'

[dantleech]

Well to be exact its a list of "Build Unit" configurations: https://github.com/symfony-cmf/RoutingAutoBundle/blob/master/AutoRoute/RouteStack/BuilderUnit.php

[wouterj]

The docs talk about a content_path which has route_stacks, so that's were I took the name from.

Do we want to change it to build_units?

[dantleech]

Naming stuff was a real challenge with this bundle. Alot of the logical names were already taken by other CMF things.

BuilderUnits might make more sense, but again I would prefer to wait until after refactoring before changing anything like that.

[dantleech]

Not sure if this is a good idea at this moment --

• I intentionally inlined the options to make it less verbose (they are represented internally as you have PRed here). They were originally as keys as in this PR.
• I guess there is an XML reason to add "route stacks" - and I have considered adding something similar for practical reasons (other than XML) but have not decided the form it will take yet.

In brief -- I plan to refactor this quite soon to realise some of the original use cases of this bundle, and it may or may not correspond to what you have added here - so we would risk BC breaks twice in a row :(

Would there be any value in removing the BC breaks?

[wouterj]

I intentionally inlined the options to make it less verbose (they are represented internally as you have PRed here). They were originally as keys as in this PR.

There are two disadvantages of inlining the options: It's hard to validate in the ConfigTree and it's a hacky use of the ConfigTree. Using the prototype, the Config component thinks we are defining multiple providers or (not_)exists_actions, but in fact we are defining one provider (or (not_)exists_action) with multiple options.

I guess there is an XML reason to add "route stacks" - and I have considered adding something similar for practical reasons (other than XML) but have not decided the form it will take yet.

Yes, there is. Otherwise, when having multiple route stacks in the content_path, it will look like:

<content-path name="pages">
    <provider name="specified">
        <option name="path" value="/cms/routes/page" />
    </provider>
    <exists-action strategy="use" />
    <not-exists-action strategy="create" />
</content-path>

<content-path name="namespace">
    <!-- ... -->namespace
</content-path>

And I don't like that, because you don't have multiple content_paths, you have multiple route_stacks (or builder units).

In brief -- I plan to refactor this quite soon to realise some of the original use cases of this bundle, and it may or may not correspond to what you have added here - so we would risk BC breaks twice in a row :(

We can build that into this PR. If I understood you correctly, you wanted to use multiple providers/(not-)exists-actions. It's easy to implement with the current config tree.

Besides that, I think we can do 2 things with this PR:

1. Remove BC breaking stuff, but keep the things to get the Xml working. This will look somewhat uggly when writing XML.
2. Create a beforeNormalization which turns the previous config (inlined) into the current config. This means we get the advantage of automatic validation, the config component understands what we are doing, we keep the good support with XML and when one wants to use the more semantic options style, they can do that.

[dantleech]

I agree with your comment on the XML having multiple "content-path" elements, not good.

I will hopefully have a chance this weekend to have a closer look at the refactoring required by #34 - I think when that is clerer we should revisit this PR.

[wouterj]

superseded by #38