Re: [vqwiki-dev] Current Status, Task Requests and Project Direction
Status: Abandoned
Brought to you by:
mteodori
From: Martijn v. d. K. <ma...@va...> - 2006-06-08 19:51:08
|
Hi Ryan, You're right about the properties... I simply didn't decide how to work with them yet. My main reason for taking out the default values and putting them into a properties file was so we could change the default values without actually having to recompile and redistribute the system. But that's probably pushing it. Let's drop the default.properties file and put the default values back into the class... I do think we will have to restructure the naming scheme for property names. I'd like to suggest the following: 1. Properties in the Environment class should be CORE ONLY. That means any property related to a module or to a parser belongs in the class of that module or parser, not in Environment. 2. A suggested naming scheme: <property indicator>_<context indicator>_<name> This would give us the following examples: PROP_DIR_HOME PROP_DIR_UPLOAD PROP_DIR_TMP PROP_SEC_ENCODEPWD PROP_PERSIST_TYPE Whatever it becomes, I think some sort of structure or naming system would be very usefull. Sincerely, Martijn ----- Project Lead for the VQWiki Open Source project ----- Original Message ----- From: "Ryan Holliday" <rya...@gm...> To: "A mailing list for the developers of VQWiki." <ver...@li...> Sent: Thursday, June 08, 2006 9:28 AM Subject: Re: [vqwiki-dev] Current Status, Task Requests and Project Direction > Hi Martijn, > > I've just gotten around to trying to build the project to see where the > current issues are, and took some time to review the changes to the > Environment.java class. I very much like how you've simplified the > class, but I do have two concerns about removing the PROPERTY_NAME > constants and moving the property value defaults into a property file. > > First, without having constants for the PROPERTY_NAME values the > implementation will then involve hard-coding the propery names, eg: > env.getValue("some-property"). That creates an instance where something > that might have been caught as a compile error becomes a (harder to > debug) runtime error. For example, env.getValue(PROPERTY_DB_SERVER) > isn't susceptible to typos, but env.getValue("db-server") would be. > > Moving default property values into a property file is something that > I'm less opposed to, although as a programmer I like being able to > easily see what the variables are being initialized to. Also, since > these values are used only to initialize property values, hard-coding > isn't really a problem (it's the same scenario as initializing any other > variable - the value isn't going to be used elsewhere). > > Re-adding each of these items wouldn't complicate the class too much, as > it would simply mean including several constants and adding a static > initializer for the "defaults" properties object. Assuming that these > changes were motivated by a desire to make the properties system more > generic, a plugins.properties file could always be added if needed and > included in the readProperties() method. That would have the additional > advantage of keeping core & third-party properties separate. > > As always, let me know if I've missed something or if you have a > different opinion. Again, I really like how you've simplified the class > - it's vastly easier to read than the previous version. > > Cheers, > > Ryan > > > Martijn van der Kleijn wrote: >> - A default.properties file was introduced with the intention of removing >> hard-coded default values. >> - Major changes in Environment class to match introduction of >> default.properties.... THIS IS CURRENTLY VERY BROKEN > > > _______________________________________________ > veryquickwiki-develop mailing list > ver...@li... > https://lists.sourceforge.net/lists/listinfo/veryquickwiki-develop > |