David E Jones wrote:
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.
I agree that having a data model would be better. But still, an hour or
two of coding and we could have configuration screens for the existing
properties.
-Adrian
