I have read a lot of statements like "you shouldn't clog your app.config file with custom settings". However, I was under the impression that this was exactly the purpose of the file?
Is it just indeed a preference thing? Or are there any real benefits (other than separation of settings) by using a custom XML file, as apposed to the app.config file? If you need to explicitly separate settings would it better to use a custom ConfigurationSection rather than opting for a custom XML file?
I would like to here other peoples thoughts on this.
Some people tend to go a bit overboard on custom config section handlers, in my humble opinion.
I tend to use them only when I need something that is very structed; and that is used/written by 3rd parties (i.e. I want to do some extravagent validation on it).
I think you can quite happily use app.config/web.config for all relevant settings, and use separate XML files when it is very clear that is a separate component of the app.
Have a look at the Application Settings Architecture, the app.config is for Configration regarding the Application, thats quite a general term though.. So I would suggest you look into the Application Settings Files.
I would not store settings like "load database on startup or not" in the app.config. I would rather use an Alternative Storage like Application Settings for this, don't confuse Application Configuration with Settings, even though you might want to do that, Don't. app.config is supposed to have configration regarding lower level things like Database connection, Membership Provider or any other Application Critic information.
Most settings tend to fall into one of three camps:
Technical settings that affect the internal behaviour of the code, e.g. database connection string, data file path, logging switches, error handling switches, etc.
Business settings that affect the business logic of the product, e.g. "are users allowed to access the CRM Module?"
User-specific profile values, e.g. "is this user allowed to access the CRM Module?".
The natural place for type 1 is in app.config or web.config, and the natural place for types 2 and 3 is in the database.
App.Config are good for configuration that are application specific : path to database is a good example. The rest should be out of it.
One thing you might want to do is to create user-specific files, you can then use custom xml that will be saved into an IsolatedStore.
In my opinion I consider app.config to be good for deployment-time settings such as the location of the database, or an IP address or location of critical data file, etc. User settings like font, color, behavior preferences should go in a different file which you can easily create and save with Xml serialization.
Related
I'd like to manage a bunch of report files directly on a file system directly for easier use, especially when updating or excanging them with newer versions. And to avoid this intransparent document library.
Now i want to read one of these Files directly in liferay to pass them to JasperReports in general (e.g. as a ByteStream). I coudln't find any way to do this or something that discribes any way to handly files.
How is this possible to achieve?
Or do i completely mess around with my idea?
You basically can leverage the powers of the Spring framework, since Liferay makes use of Spring more or less directly.
You need to use some sort of "resource adapter" to open files, which you can do in many ways. It pretty much depends where you put files and how they get there (if provided from outside or generated by a Liferay portlet itself, or provided as deployed resource).
I can recommend searching for the following Spring class to be used:
org.springframework.core.io.FileSystemResource
Nevertheless you should think about storing these files in the database, as this is much safer after all (transaction safety, security, ...).
I am trying to use the Configure class in CakePHP, but I'm not sure if I am using it correctly. I have read through the cook book and the API, but I can't seem to do what I want.
I have created a configuration file: app/config/config.php. I can directly edit this file and set variables in there and access them using Configure::read().
Is it possible to update the values of the configuration file from the application itself, i.e., from a controller? I have tried using Configure::write(), but this does not seem to change the value.
app/config/config.php isn't a file that's automatically loaded by Cake. Either move these variables into app/config/bootstrap.php or tell your bootstrap.php file to load your custom file. You could also put your variables in app/config/core.php, but I'd recommend against that. I tend to like leaving that file alone and adding/overwriting values in bootstrap.php.
According to the API, Configure is supposed to be used "for managing runtime configuration information".
You can use its methods to create, read, update and delete (CRUD) configuration variables at runtime. The Configure class is available everywhere in your CakePHP application and therefore CRUD operations performed on its data in any place, including a controller.
If you are looking for persistent storage, you could consider a database (SQL or NoSQL). I would not recommend using a text file, as it raises a lot of security concerns. Even if security is not an issue, a database is propably a more fitting solution.
More on the Configure class in the Cookbook.
In my WinForms app, I have a few textboxes that the user typed some data into. I want to store the data, but I don't want to use a database. In my stone-age C++ days, I'd just use a .ini. Somehow, app.config doesn't seem like the right place to store this data, though.
What are my other options?
I would say the .config file is the right place. Just be sure to use the User scoped area of the Settings.settings file rather than the Application scope.
This works well for simple data types and when you have fixed values that will need to be saved because you need to define what variables you want to store at design time. So if your textboxes are dynamically created and you don't know many values you need to store it is not very useful.
Using IsolatedStorage might be another good option. You can create your own file in any format you want (keeping any values you need) and store it to the local machine in "IsolatedStorage".
You can create a folder somewhere on the disk and simply write a file in any suitable format (XML, plain text, your choice). You could for instance do this under the path pointed out by Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) or Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData).
I would look into isolated storage. It is easy to set up per-user. And since it requires only partial trust, it will work for any deployment scenario.
Check this introduction.
Depending on how many variables/data you're looking to save the app.config/settings file can be the ideal place.
Check out the Settings Tab in the Project properties and note that you can set both Application settings and User settings. Application settings affect the entire application. User settings are stored per user.
The section of the app.config that contains user settings will be saved to the user directory when they are saved and reincorporated when they restart the app.
Check this url for an introduction to Application/user settings on MSDN and also this SO url for a similiar question.:
You could also look into storing your familiar old .ini files in a per user .ini by checking out the Special Folders enum as per this url.
I believe the proper place to store user settings in WinForms 2.0 would be in the settings file (not the config file). Here's a quick article for explanation.
Create a .config or other data file (e.g. xml) in the application data for the specific user.
use system.environment.specialfolder to get the ApplicationData folder, add a subfolder with your company name, within this a subfolder with your application name, within this your data file for this specific user. Thus,
Environment.GetFolderPath(Environment.SpecialFolder.ApplicationData) + "\\YourCompany\\YourApplication\\YourData.config"
I'm working on a website in JSP (in GWT really, but on the server side, it's really just JSP), and I need to configure my database.
I know HOW to code in the database connection etc, but i'm wondering how/where the database config should be saved.
To clarify my doubt, let me give an example; in PHP, a website usualy has a config.php, where the user configures the database, user, etc (or an install.php generates it).
However, since JSP is bytecode, I can't code this info into my site and have the user modify it, nor can I modify it analogously to an install.php.
How should I handle this? what's the best/most common practice ? I've found NO examples of this. Mainly, where should the config file be stored?
There are several possibilities to do this, what I've seen done include:
Having database credentials in a special file, usually db.properties or some simple XML file that contain the required information (driver, url, username, password, any ORM parameters if needed). The properties file would be placed under WEB-INF or WEB-INF/classes; the downside of this approach is that the user would have to modify the file inside the WAR before deploying it to the application server.
Acquire the database connection via JNDI and expect it to be provided by the application server. This seems to be the most common way of doing this; on the upside, your WAR doesn't have to be changed, however, the downside is that configuring a JNDI data source is different for every application server and may be confusing if your system administrators are not experienced with Java technology.
So, I am working on this web based app following the Repository model, a wannabe DDD dork, using StructureMap.... blah, blah, blah...
One aspect of the application allows users to upload and manage files.
Where, what layer, should be responsible for managing the saving/ deleting of these user files?
The Business Layer,
or the Data Access Layer...?
It, for whatever reason, doesn't seem a straight forward answer...
Historically, I just slapped it in the GUI, but striving to be more programmaticall correct and rethinking what should handle these service. Maybe I just answered my own question...
I create a separate layer "Storage Access Layer (SAL)" .... getting file information from DAL I passed that to SAL and SAL return me the correct file ....so if someday I switch to Amazon web services from web hosting storage , I will just change the classes in SAL , plug the DLL and ready to go ....because the user will upload the file in same way as before so UI is not changed..... business rules are enforced same as before so BLL is not changed....Database has not changed and information of file is saved same as before so DAL is not changed...... only thing changed was the protocol to access the file....so just change the SAL
I would put it in the business layer, though if it were me, I'd end up making calls to the DAL with regards to the files each user has uploaded. I'd keep track in the database of the file names and locations for each file a user uploads.
I put mine in the DAL since we considered the files data in which to update or query, just through a different "protocol" that being System.IO.
More specifically, I made a FileManager class that handled all the basics and even had a couple of constants in place so it was easy enough to change path locations for development and production environments, since they were drastically different.
Dillie-O - Furthermore, if the application ever switched to storing files from the IO to the DB, the DAL is a more logical place. Some flexibility...
It's in DAL full stop.
Business logic should not have IO dependency on your environment.
You put it in business logic, next time you want to use that piece of "logic" but end up on an environment with no file IO permission you'd be toast.