I wonder if any of you got a suggestion on how to easy change different setup when using different ConnectionStrings (and possibly other settings too). Currently, when debugging with different ConnectionStrings, I uncomment/comment the one I want to use/don't want to use.
Is there a way to group a collection of settings and use a single value to determine which settings to use?
I don't meen the possibility to have a nested web.config, as Release.web.config and a Debug.web.config, because I HAVE TO use the Debug configuration.
Your application could have a single class responsible for handing out connection string values. Given a parameter it would pull the appropriate string from the .config files.
IMO you should be doing this anyway in case you change the connection string name - if you encapsulate what can change within a class the app is easier to manage.
I don't think you can add some conditional logic directly to the .config files to do this for you.
Related
What would be a proper way to handle global "settings" in my sailsjs application? The user will want to change those settings via the web front of my app.
I imagine I could use a new model "GlobalSettings" with only one item, but I don't really know if it's a good "MVC" practice.
Since it is based on user input, it has to be stored in a database and therefore storing it in model seems like a right choice to me.
Having just 1 row/collection is completely ok in my opinion, especially in the no-SQL field. But for more reusability and scalability, you might want to consider to actually store each setting in invididual row, that might give you space to expand the usability of it in the future.
In my own opinion, I always find as a web app develops, you will start to realize there are more and more fields that you want the user to setup as their preference, as a good practice to relax the application.
For me I usually setup a meta_data model with name, value, criteria, and some other fields.
For example, when viewing your web page, 'Alice' may want a background color of black, 'Bob' may want a background color of green. Then you can let them modify or insert row into this meta_data collection. Then in your database, you will have
name value criteria
background_color black user_name='Alice'
background_color green user_name='Bob'
and it can be all kinds of values.
of course if you just have one value that can be changed by all of your users, it is probably a good idea to know who updated them. For this you would want to create a trigger, (if you are using a sql database)see trigger in mysql, so that every update on the table will trigger a function that stores what was changed and who changed it in another table
So yes, to answer your question, it is totally ok to have a model to store a value, and don't worry about only have one row, you will have more as you develop your app.
The config/globals.js file seems to be a good place to place a global configuration setting.
For convenience, Sails exposes a handful of global variables. By
default, your app's models, services, and the global sails object are
all available on the global scope; meaning you can refer to them by
name anywhere in your backend code (as long as Sails has been loaded).
Nothing in Sails core relies on these global variables - each and
every global exposed in Sails may be disabled in sails.config.globals
(conventionally configured in config/globals.js.)
Sailsjs.org Documentation - Globals
Alternatively you can use the sails.config object.
Custom Configuration
Sails recognizes many different settings, namespaced under different top level keys (e.g. sails.config.sockets and
sails.config.blueprints). However you can also use sails.config for
your own custom configuration (e.g.
sails.config.someProprietaryAPI.secret).
From the docs
There is also services which is global by default.
Overview
Services can be thought of as libraries which contain functions that you might want to use in many places of your application. For example,
you might have an EmailService which wraps some default email message
boilerplate code that you would want to use in many parts of your
application. The main benefit of using services in Sails is that they
are globalized--you don't have to use require() to access them.
It really depends on what kind of global you are wanting.
As a developer of an HttpModule that is used in over 150 countries, I want to make sure I'm doing the right thing by making all web.config data culture-invariant. This means any date/time values, floating-point, or integers specified in Web.config should be parsed with the invariant culture (generic english).
Is this the correct convention to follow? Extensive googling didn't turn up an answer.
I recommend that you use the invariant culture for all configuration settings in Web.config, because that is the convention followed by ASP.NET. Your users will probably find it confusing to have to specify invariant data in certain places and localized data in other places.
(ASP.NET relies on the functionality in System.Configuration to parse configuration data. The internal ConfigurationProperty.ConvertFromString method calls TypeConverter.ConvertFromInvariantString to convert a string to a typed value. You too can use System.Configuration; see the MSDN Library documentation.)
I am not sure that there even is a convention for this. Come to think of it I'm not sure what I would expect. I would probably be surprised if the module didn't behave as expected because a setting was parsed in an unexpected culture.
But let's say for the sake of argument you want to do follow a different convention (not invariant by default). I think it would be most logical to read the <globalization> settings and use the culture setting (not the uiCulture because that is for loading resources).
This way it is configurable for your customers. Of course you need to take care to use an IFormatProvider based on the culture setting to parse the settings:
string setting = ConfigurationManager.AppSettings["size"];
IFormatProvider format = CultureInfo.GetCultureInfo(configSection.Culture).NumberFormat;
float size = float.Parse(setting, format);
I'd say it would be good to cache the configuration setting in HttpContext.Application the first time it's read. If web.config changes the app domain will be reloaded anyway.
A possible downside is that when you want to document your library you will have to educate users that they can't just copy-paste configuration values since their environment may have a different culture setting and thus they may encounter errors that could be hard to understand.
PS. Looking at the configuration documentation for your module, I noticed the <cleanupStrategy> element. That looks unusual to me. I would expect to specify its values in seconds or some other integer value, like <sessionState timeout="number of minutes">.
Resource file generated from Tools--> Generate Local Resources creates respective keys having the suffix "Resource1".
Is there a way to get rid of the suffix "Resource1" and make it use the exact control name for the resource key?
It's described in this issue. The Resource suffix is to help prevent name clashes between controls. Without it, it would break in some circumstances.
Is it purely the code generation you want to customize? You could always use a Custom Resource Manager to remap the resource keys to your own convention (without suffix). It does mean creating your own implementation to pull out the resources created from RESX, but I've done it this in the past with some help (copy/paste) from reflector.
It would allow you to use shortcuts (no suffix) in your syntax when referring to resources, but it wouldn't affect the code gen side of things. A find and replace fixes that, or a custom tool.
I have been trying to get culture specific resources to work on an asp.net mvc 3 application.
If I have a LanguageResources.resx and a LanguageResources.en-UK.resx in my App_GlobalResources folder then I get an error "The namespace 'Resources' already contains a definition for 'LanguageResources'"
This is the end of a long line of issues that I have had with trying to get culture specific resources to work. I must say, I'm not impressed with the documentation Microsoft provide for using this feature.
I'm considering using a database table to store my culture specific strings instead, then I can just build a dictionary of all the values that will be available to my controller and views.
Has anyone else made such a decision, or have any direct knowledge on performance issues related to using a database for culture specific strings?
Has anyone else given up on resources too?
I must admit, I tried to reproduce your defect and I was successful. It looks like, Visual Studio generates additional class when you add something.en-UK.resx. Strange. It should not allow you to add anything like this in the first place for there is no such culture.
How to resolve the problem? Just add LanguageResources.en-GB.resx and delete
LanguageResources.en-GB.resx. That helps.
I would not use database for storing language-related resources, unless they are changing very frequently or must be entered by end users (i.e. there are some kind of templates).
Using the database hurts Localizability and requires much effort. It is hard to design correctly (I have seen a lot of mistakes in that area). Don't go that road unless you really have to.
I need to design a configurable content system for all of the text in our web application that will tie together our need for Translation with the ability for Groups of users, Subgroups of users, and single Users to configure what a given label, Error Message, or piece of system text says.
Because everything needs to be configurable through the interface, resource files don't seem like the solution.
I don't expect to find something like this out of the box. How would you go about designing something like this, or what would you begin to configure in order to get this functionality?
I have achieved the type of functionality you are looking for by creating a database backed custom resource provider, and setting the <globalization> tag in the Web.Config to point to your custom provider. see: http://msdn.microsoft.com/en-us/library/aa905797.aspx
Then within your pages and code, you can refer to GetGlobalResourceObject or GetLocalResourceObject to get localized resources.
Whilst this is primarily designed for multiple languages, I have used it in combination with custom locale functionality to provide different labels, error messages and text to different groups of users.
Create a simple table along the lines of:
table Resources {
language varchar(100)
label varchar(100) /* you might consider a different key type, but this would be easiest on coding */
value varchar(max)
}
You might simply cache the whole table on the web server to perform the look ups locally and simply expire the cache when a value is changed.
It's a relatively easy thing.