Added option to create configs with projectname, not storing it as part of foldername #129
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
januszem
force-pushed
the
master
branch
2 times, most recently
from
8a670ee
to
0151940
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Requirements
Description of the Change
I see that there is already similar pull request, but this one add feature as optional part.
The issue no. 1: (copied from @vhil PR)
When having module folders directly inside Include folder, the "Feature" folders are getting loaded before "Foundation" folders, because "e" goes before "o" alphabetically. As long as the number of features/foundations is unknown it is hard to control the order of layer loading.
Resolution: Create parent folders with layer names. Then you can set Layers order in layer.config
The issue no. 2:
Habitat project uses config structure convention as:
App_Config
-Include
--Layer
---FeatureName.ConfigName.config
When coming into this type of solution, using generator-helix for adding new project is time consuming as it not support this convention and after all you have to change it manually.
Resolution: Add option to create configs in habitat style. Then no manual changes are needed.
The issue no. 3:
When you check ShowConfig.aspx you cannot distinguish from where patch is comming, as showconfig displays only name of the config, not the whole path. Few features can share the same name of config like "serialization.config" so in case of huge amount of projects, it can be misleading.
Resoultion: Add FeatureName to config file. Then no confusion when detecting from where patch is comming.
Benefits
Two conventions of storing configs when adding project.
No manual changes needed when project follows habitat.
Less confusion and time spent when detecting config file from ShowConfig.aspx feature.
Can easier control layer loading order.
Less mess inside App_Config/Include folder.
Possible Drawbacks
Can't see any, as feature is optional, and user can follow old style while adding project.