Hierarchical levels of configuration storage of custom modules

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

Please do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.

This forum is for discussing mojoPortal development

This forum is only for questions or discussions about working with the mojoPortal source code in Visual Studio, obtaining the source code from the repository, developing custom features, etc. If your question is not along these lines this is not the right forum. Please try to post your question in the appropriate forum.

You can monitor commits to the repository from this page. We also recommend developers to subscribe to email notifications in the developer forum as occasionally important things are announced.

Before posting questions here you might want to review the developer documentation.

Do not post questions about design, CSS, or skinning here. Use the Help With Skins Forum for those questions.
This thread is closed to new posts. You must sign in to post in the forums.
11/30/2009 4:15:33 AM
Gravatar
Total Posts 31
There are 10 kinds of people in the world, those who know binary, and those who don't

Hierarchical levels of configuration storage of custom modules

I am developing some custom modules and as the requirements get more complex, I need to be able to configure these controls on a few more levels.

Out of the box, MojoPortal has functionality for adding settings to features (Advanced Tools > Feature Installation/Configuration > "Feature Name" > Feature Settings) per-instance. I have used this functionality to add features and it serves the purpose well for instance configuration.

Now, I would like to extend the use to add configurations for these cases:
1. A shared configuration setting for all instances of a feature (or multiple features, which may all be written by us) on a web site
2. A shared configuration setting for all sites
3. A setting which is saved per-feature and per-user (and optionally, per-feature, per-user, per-instance)

One of the motivations is to reuse some configuration settings (connection string for custom database comes to mind) and allow personalizing different instances for various users. Ideally, some form of hash table/key-value collections which are per-control and either global, by-site and by-user would do it.

Any extendability in the API:s to get/set serialized properties on these levels or is it necessary to build my own configuration storage?

 

You must sign in to post in the forums. This thread is closed to new posts.