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).
-David
