David,
Thank you very much for your comments. I agree with the idea of data model extensions designed
around a particular configuration option.
I was thinking more along the lines of having some of the system-level configuration options stored
in an entity - so we could have a basic system configuration UI. Of course some things could be left
out - like the cache settings you mentioned previously.
I'll put the idea on the shelf for now.
-Adrian
David E Jones wrote:
This is an interesting approach, but very different from what I had
imagined and what has been discussed (though not in a lot of detail).
Rather than creating a generic structure I'd rather continue with the
existing pattern of designing data model extensions according to the
nature of the configuration option.
That approach is certainly more work, but ultimately more valuable and
easier to use and maintain going forward. All options are basically
listed out and can be restricted more using enums as needed, and
structured relative to whatever makes sense like a product store or
organization party or whatever.
This also helps clarify which options should or should not go in the
database. IMO only the business level configuration options should go
in the database and not the "technical", or perhaps better labeled
"system", level ones. If it relates to something in the current data
model, like payment settings for example, then it makes sense to create
a structure for and put it in the database. That particular example
would also allow us to get rid of some hackish things like specifying
the properties file name in an entity field.
-David
On Dec 7, 2007, at 3:42 PM, Adrian Crum wrote:
Now that OFBiz supports XML properties files, I've started thinking
about David's comment that configuration settings and such should be
kept in the database - and how to add that capability to the
UtilProperties class bag of tricks.
Just like the XML properties file idea, I'd like to make it
transparent to the developer. I'm thinking we would need only one
entity, and a little more work on the UtilProperties class.
The entity would be something like:
ResourceProperties
------------------
ResourceName, id-long
PropertyKey, id-long
PropertyValue, very-long
So, if you called UtilProperties.getPropertyValue("MyResource",
"MyProperty") the usual properties files would be checked first, and
if that failed, the ResourceProperties entity would be searched.
UtilProperties would keep the entity version of Properties objects in
the same cache as regular file-based Properties objects.
What do you think?
The only thing I haven't figured out is how to get a delegator
instance. In the example above, there are two String parameters - no
delegator. I know I can call
GenericDelegator.getGenericDelegator(String delegatorName) but what
delegator name do I use? Any ideas on how that would/should work?
-Adrian
