Support configuration sources other than System.ConfigurationManager

[dontjee]

Windows Azure applications use CloudConfigurationManager instead of System.ConfigurationManager to read configuration values. It would be nice if there was a way to inject a different setting provider (like the Azure one) to be used with Formo. It would also allow for mocking out config values in unit tests.

I'd be happy to help provide a pull request, I'm just not sure how you'd like the code to be structured. This feature could be accomplished via an interface and injected into the Formo Configuration object at some point. There could also be multiple versions of the Formo package, one for regular configuration manager, one for Azure, etc.

[ChrisMissal]

Here's what I'm thinking:

The Configuration class just drops the "Manager" part. What about a CloudConfiguration class? The GetValue(string name) method could be changed to virtual protected and drop the static. Then have CloudConfiguration override that method?

Just thinking out loud at this point.

[dontjee]

Yup I think that could definitely work. Biggest problem I see is introducing the dependency on the WindowsAzure.Configuration nuget package. It's going to be unnecessary for the majority of people using Formo.

[ChrisMissal]

Good point. A separate Project (and NuGet package) could live alongside. I want to keep "base" Formo dependency free.

[ChrisMissal]

Here's a branch with the cloud project: https://github.com/ChrisMissal/Formo/tree/cloud - thoughts?

[dontjee]

Code looks right to me, you beat me to it :smile:

Should it reference Formo via nuget instead of a project reference? That way the Formo.Cloud package has a dependency on Formo. The way it is now it's a project reference, and I'm not sure the nuget package for Formo.Cloud would work.

[ChrisMissal]

Good catch! I'll get that fixed.