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.
-Adrian
