I think that system settings should stay in config files, not in the
database; if the goal is to simplify the configuration steps described
in the production setup guide, then there are probably different ways of
addressing this:
a) deliver a separate set of config files already configured for a
"standard" production (cache enabled, verbose logs disabled etc...); we
may also consider to deliver these settings in the release branch, and
maintain the dev settings in the trunk
b) implement an ant-based wizard (to be run during the installation of
OFBiz) that prompts the user for some common settings (http port, https
port, mail server address, db used, db user/password, db url etc...) and
then modify the OFBiz's files (or, we could prapare *one* simple file
where the user can enter all these values, then run the ant script that
places then in all the relevant OFBiz files)
c) clean up the existing config files; for example, the entityengine,xml
contains the settings for a lot of different databases; we could keep
the settings for just one of them and move the others into a separate
file, or create one file per database etc...
Of course, for more complex (real World) setups, you'll have to follow
the steps of the production setup guide... but for simpler ones it could
work.
just my 2 cents
Jacopo
Adrian Crum wrote:
David,
Thank you for the clarification!
I understand your point of view, but the idea that a user could muck up
existing data is true for all of OFBiz. How many emails do we see about product
catalog configuration problems? In addition, a user could delete admin
permissions using the Party Manager component and end up locking themselves out
of the system. The scenario you described could be applied equally to many
areas of OFBiz.
The system level settings could operate just like any other seed data. It gets loaded during ant run-install and from that point on it is managed from the UI.
Maybe we could identify particular areas as "do not touch" and make it clear in the UI
that a user shouldn't change those settings. That's one of the advantages I see in the UI
configuration wizard (or screen) - instead of a simplistic "key=value" setting in a
property file, the UI could explain the setting and the pros and cons of changing it.
If a consultant or systems integrator wanted to prevent a user from altering
consultant-supplied settings, then they could disable the configuration screen.
-Adrian
David E Jones <[EMAIL PROTECTED]> wrote:It doesn't really have anything to do with concurrency, my concerns is
with redundancy and inconsistency. If we put configuration (system or
business level) in the database, which is what this discussion was
originally about, then the initial data will come from XML data files.
If that data is changed in the database but not in the XML files then
they are out of sync, and if anyone changes one without the other and
the XML files are used for a new system or to update an existing
system then strange things may happen (which generally needs to be
done periodically since we are not omniscient are rarely create or
deploy systems that don't change).
Right now system level settings such as http, database, cache, debug,
etc settings are in files and are read from those files; if any of
these are changed through a UI then the changes are in memory only.
Would we really want a setup wizard for these things? We certainly
could, but what is the target audience and intended use process?
Business level settings are done a little differently, and this is
where the biggest inconsistency lies. Some of these are in properties
files and others are in the database. In order to have different
industry-specific or business type specific data sets these that can
be loaded initially when setting up a system these really should be
all in the database and configurable through UIs rather than sitting
in properties files.
I really think the more important things to allow users to configure
are the business level things. The system level things might be nice,
but most of those settings should stay the same for really small
installations where they are using it OOTB. If we did make a config UI
for system level settings in order to make it easier for non-technical
users to change things they just might use it... and that could be
bad! Most of the system level settings require an understanding that
non-technical users wouldn't have, and we shouldn't make it easy for
them to hork their entire system and require someone more technical to
come in and try to figure out what they did, undo any damage (if
possible!) and then tell them NOT to use the fancy UI we built anyway...
-David
---------------------------------
Looking for last minute shopping deals? Find them fast with Yahoo! Search.
