On Jun 10, 2008, at 12:22 PM, Adrian Crum wrote:
David E Jones wrote:
On Jun 10, 2008, at 12:04 PM, Adrian Crum wrote:
David E Jones wrote:
On side note I should mention that the direction has been
discussed and generally agreed on that application level
properties should be done away with (like payment.properties, and
many others) and that information should go into the database.
The main reason behind that is to support differing initial data
for common setups that can simply be loaded into the system when
it is run and you can get started quickly and without having to
dive into files... oh and also that you can maintain things
through a UI instead of through editing properties files.
An interesting idea. Would a single entity be used for that, or
would each application have its own entity?
No one has gone through a modeling exercise yet, so I don't know
exactly what the entities would look like. In essence the each
property in the relevant properties files needs to be considered
and added where it makes the most sense, either to existing
entities or new ones. For payment.properties most of the
information would go in the ProductStorePaymentSetting entity or in
entity(ies) related to it. They would replace the
ProductStorePaymentSetting.paymentPropertiesPath field which is
currently used to refer to a payment.properties file (of a
different name, ie allowing multiple files for multiple payment
processors... a "hack" if you will).
I was thinking we could add a bit of code to the UtilProperties
class that would check a common entity in addition to properties
files. It would be a simple change to make, and applications could
still get their settings through UtilProperties.getProperty(...)
method calls. Screens could be created to manage groups of properties.
I would really like to not see this happen, as it would only be a
slight improvement over what exists now, but it wouldn't be a real
data model and the result would be as disorganized and difficult to
understand and use as the current flat properties file. I guess it's
not too bad, but we don't have to stick to a single flat list of
properties in the database... we have a lot more flexibility there.
Anyway, the data modeling and queries and UIs should be a vast
improvement over what exists now, and I'm thinking well worth the
effort as well.
-David
