What could be even more intereting is to add a dynamic way to load a property in the schema you proposed.
For instance SAP xMII usse a such scheme for dynamic i18n (which is not our concern since we have xml file for that) http://help.sap.com/saphelp_xmii115/helpdata/en/Localization/Localization_Overview.htm Excerpt: <<Dynamic user localization is performed in a similar manner as Java resource bundles but uses custom code. User localization changes are dynamic and take effect immediately. These files are located in the Properties directory. Unlike Java resource bundles, the language is used to identify the various files only, rather than the full locale information.>> My 2 cts Jacques From: "Adrian Crum" <[email protected]>
I have been thinking about Properties handling too, not from a multi-tenant perspective, but from a convenience perspective. It seems to me the way we handle properties right now could be simplified. Instead of calling a static utility method to get a property or using a special mini-language element, the service or screen rendering context should contain a Map called "properties" - which provides a convenient means of accessing all configuration properties. So, instead of: <property-to-field resource="general.properties" property="currency.uom.id.default" field="rateCurrencyUomId"/> you would use: <set field="rateCurrencyUomId" from-field="properties.currency.uom.id.default"/> and in Java, instead of: String currencyUom = UtilProperties.getPropertyValue("general.properties", "currency.uom.id.default"); you would use: String currencyUom = dctx.properties.get("currency.uom.id.default"); Configuration Properties files could be read in at startup via an ofbiz.component.xml element or elements. The properties Map is read-only after startup. When all of the configuration properties are handled in a centralized way, then extending the design to use the entity engine as an additional configuration property data source will be trivial. The SystemProperty entity you proposed needs to be simplified: SystemProperty -------------- propertyKey, id-vlong-ne* propertyValue, very-long Properties file entries contain only key+value pairs, so the entity should do the same. -Adrian On 1/27/2012 6:40 AM, Hans Bakker wrote:Problem: ------------ 1. If you would like to have different tenants on your system and want to have different property settings for each tenant laike language or currency etc, that is currently not supported. 2. the properties are not very well organized, to say the least. Proposal: ------------ 1. create the following entity SystemProperty with fields: systemPropertyId(key) parentSystemPropertyId description ofbizPropertyName(index) systemPropertyValue Initially load the systemPropertyid from the ofbiz propertyId so accounting.fixedasset.autocreate=Y will have 3 records using the parent id but only the lowest level will have the accounting.fixedasset.autocreate name and value=Y when we have this working we can slowly reorganize these records without having to change the programs. 2. add the delegator parameter to the getPropertyValue method and change the method system wide. the getPropertyValue method will first look in this entity with the provided delegator and when the property is null or not found, use the properties file property as currently is done. 3. resolve anywhere where this method is called and where the delegator is not available. 4. add a webtools option to set the properties. Please provide comments or counter proposals...... Regards, Hans
