SiteConfigurationElement

Jan 25, 2009 at 9:35 AM
Oxite looks great. Nice project.

While looking at the code - I was interested to see the use of a custom configuration section for site settings.

I've seen a few approaches for configuration - from separate IXmlSerializable based classes that read and write to an Xml configuration file, to the use of custom config sections in App or Web.config (as Oxite does). In the case of a custom configration section, I'm curious to know how you would implement an admin user interface for site settings. I've tried (albeit briefly) to write to custom configration sections back to the Web.config in the past - but wasn't able to get it to work. The MSDN docs describe writing to a configuration section using the Save methods (which in the Web.config would obviously cause the app to re-cycle) but was wondering if this is something that the Oxite team has tried in the past, or is planning for a future release?

http://msdn.microsoft.com/en-us/library/system.configuration.configurationelement.aspx

Kind regards,

Tony
Jan 25, 2009 at 10:15 AM
I'm not on that team but I am qurious on what you mean. I've done quite a lot of config sections in my day.

If you write to the config settings your site will have to be restarted to apply said settings. As far as I know.

Another way to solve that issue is to make a reference from your web.config to another config file and put your custom settings there. Enterprise Library contains functionality for this. You would simply referece in the Microsoft.Practices.Common.dll into your project and (figure out how to) add settings for a separate config file. Don't have a sample right now but I'm sure you can find one in the Ent.Lib. quick starts.

Cheers,

M.

On Sun, Jan 25, 2009 at 11:37, abouch <notifications@codeplex.com> wrote:

From: abouch

Oxite looks great. Nice project.

While looking at the code - I was interested to see the use of a custom configuration section for site settings.

I've seen a few approaches for configuration - from separate IXmlSerializable based classes that read and write to an Xml configuration file, to the use of custom config sections in App or Web.config (as Oxite does). In the case of a custom configration section, I'm curious to know how you would implement an admin user interface for site settings. I've tried (albeit briefly) to write to custom configration sections back to the Web.config in the past - but wasn't able to get it to work. The MSDN docs describe writing to a configuration section using the Save methods (which in the Web.config would obviously cause the app to re-cycle) but was wondering if this is something that the Oxite team has tried in the past, or is planning for a future release?

http://msdn.microsoft.com/en-us/library/system.configuration.configurationelement.aspx

Kind regards,

Tony

Read the full discussion online.

To add a post to this discussion, reply to this email (oxite@discussions.codeplex.com)

To start a new discussion for this project, email oxite@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Magnus Mårtensson
Senior Consultant - Scrum Master - MCSD, MCTS
Dotway AB

Tel: +46 (768) 51 00 36

http://blog.noop.se/
Jan 25, 2009 at 10:30 AM
Hi Magnus. Thanks for the reply.

Was being a bit lazy in asking the question I guess. I've never had any problem creating and reading custom configuration sections - only saving them.

Either way - a quick test (which I should have really done before posting) and  the code below works fine (and causes the AppDomain to reset as well since the Web.Config is being written to)

Configuration config = WebConfigurationManager.OpenWebConfiguration("/");
MyCustomSection mySection= (MyCustomSection )config.GetSection("myCustomSection ");
mySection.CustomSetting1 = "Some New Value 1";
mySection.CustomSetting2 = "Some New Value 2";
config.Save();

For more complex (nested section groups and configuration elements) - I'm assuming they'd all be written/serialised to the section correctly.
Coordinator
Jan 25, 2009 at 4:24 PM
I actually started moving <site> into the database and out of the web.config just last night.  This will make it easier for us to have an admin section for changing it as well as intial setup on first run.
Coordinator
Jan 25, 2009 at 4:59 PM
The path Erik is taking is the best idea, I wouldn't advise writing to the config file from a running web site... it would be too easy to take down your site completely... and even an AppDomain reset can be an expensive side affect in most cases.
Jan 25, 2009 at 7:10 PM
I sort of agree with you though I'm not a big fan of one table in the database with one row in it which sort of tends to be the solution to this cunundrum if you opt for a database approach. Putting som settings in a textfile on the web site or in another folder on the server it if you like is as viable an option in my book. All depends on your situation. That said putting config data that can change from the ui in the web.config is never a good option. I've once put a config xml file in the App_Data folder,

It allt depends on your situation really. If you're fine with a "table" that has one row or entry rather that's all good. I wouldn't necessarily go so far as to say it's "the best" approach!

Cheers,

M.

On Sun, Jan 25, 2009 at 18:59, Duncanma <notifications@codeplex.com> wrote:

From: Duncanma

The path Erik is taking is the best idea, I wouldn't advise writing to the config file from a running web site... it would be too easy to take down your site completely... and even an AppDomain reset can be an expensive side affect in most cases.

Read the full discussion online.

To add a post to this discussion, reply to this email (oxite@discussions.codeplex.com)

To start a new discussion for this project, email oxite@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Magnus Mårtensson
Senior Consultant - Scrum Master - MCSD, MCTS
Dotway AB

Tel: +46 (768) 51 00 36

http://blog.noop.se/
Coordinator
Jan 25, 2009 at 8:17 PM
I'll go so far as to say it is a best practice to not allow the web.config (or app.config in a windows forms app) to be edited from the UI... that is not its intent. So... if it turns out you have settings in there that you need the user to be able to modify, then you should move them to *something* else. It doesn't have to be the DB, but the DB is there and you need it for the site to run... so why not?

You could go with an settings dictionary style table instead of a one-row table, we use that on C9 now, a table with "Name"/"Value" rows in it...
Coordinator
Jan 25, 2009 at 9:05 PM
Edited Jan 25, 2009 at 9:10 PM
Also, just because there is usually one row in it, doesn't mean that there can't be more.  In fact, that's why a table for site is very appropriate.  Oxite is designed to allow more than one site to exist in the same application.  This is mostly designed around hour our team does things, but we thought it might be useful to others as well.  If there's only one site in most Oxite instances, so be it.  It doesn't mean it's a bad design.
Jan 25, 2009 at 9:09 PM
Oh absolutely! It is all very context related! I like the fact that the db does support multiple site instances. Solid design.

M.

On Sun, Jan 25, 2009 at 23:05, ErikPorter <notifications@codeplex.com> wrote:

From: ErikPorter

Also, just because there is usually one row in it, doesn't mean that there can't be more. In fact, that's why a table for site is very appropriate. Oxite is designed to allow more than one site to exist in the same application. This is mostly designed around hour our team does things, but we thought it might be useful to others as well. If there's only one site in most Oxite instances, so bet it. :)

Read the full discussion online.

To add a post to this discussion, reply to this email (oxite@discussions.codeplex.com)

To start a new discussion for this project, email oxite@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Magnus Mårtensson
Senior Consultant - Scrum Master - MCSD, MCTS
Dotway AB

Tel: +46 (768) 51 00 36

http://blog.noop.se/
Coordinator
Jan 25, 2009 at 9:10 PM
Thanks!  :)
Jan 25, 2009 at 9:39 PM
Edited Jan 25, 2009 at 9:41 PM
Ok - so I guess what I'm seeing above is that the Web.config or App.config should really be reserved for framework or application-wide settings that are not going to be changed (at least not frequently) at runtime.

As for configuration settings that might be user editable, or changes to a site that don't require an AppDomain restart - then maybe this is a job for the strategy pattern - an abstract ConfigurationStrategy - persisted wherever is best (the DB, an Xml file, or even as a wrapper around a user scoped Settings class).
Jan 25, 2009 at 9:42 PM
That about sums it up for me! ;~)

On Sun, Jan 25, 2009 at 23:39, abouch <notifications@codeplex.com> wrote:

From: abouch

Ok - so I guess what I'm seeing above is that the Web.config or App.config should really be reserved for framework or application-wide settings that are not going to be changed (at least not frequently) at runtime.

As for configuration settings that might be user editable, or changes to a site that don't require an AppDomain restart - then maybe this is a job for the strategy pattern - an abstract ConfigurationStrategy - persisted wherever is best (the DB, and Xml file, or even as a wrapper around a user scoped Settings class).

Read the full discussion online.

To add a post to this discussion, reply to this email (oxite@discussions.codeplex.com)

To start a new discussion for this project, email oxite@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com




--
Magnus Mårtensson
Senior Consultant - Scrum Master - MCSD, MCTS
Dotway AB

Tel: +46 (768) 51 00 36

http://blog.noop.se/