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.
