David E Jones wrote:
On Dec 14, 2007, at 9:42 PM, Adrian Crum wrote:
Thank you for the clarification!
Glad it helped... though I'm still left wondering why you're trying so
hard to argue with every point I make... is my thinking fundamentally
flawed somewhere? The idea of "making things easier for the user" is
one I totally agree with, but I don't see how this does that, ie
looking at the details seems to make the whole thing fall apart...
I'm not really trying to argue with every point you make. As you can tell from the response to this
thread (and previous threads on the same subject), there is a desire in the developer community to
implement some type of UI for system configuration. Other developers have responded with suggestions
on how to make it work. You have expressed your doubts. I'm trying to find a way to address your
concerns while still considering the possibility of having a system configuration UI.
Please don't take my efforts to effect a compromise as some kind of attack on your comments. I'm
agreeing with your concerns, but at the same time I'm trying to come up with ideas for making this work.
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.
Oh yeah, how? Nearly ALL of the system level settings are used before
it can even talk to the database... including the cache, debug,
database connection, entity AND service engine settings, etc. One of
the few exceptions is the app server (HTTP, etc) setup, but those are
still needed for startup and don't really do anything without
restarting some or all of OFBiz, and for those and other reasons I just
don't see how the settings being in the database actually HELP us.
You're right - I hadn't thought of that! Then the settings should remain in
properties files.
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.
I'm seeing more arguments for disabling it than for having it... I
still haven't seen a target audience or end-user scenario that points
to this being useful...
There have been scenarios presented already. It seems you have overlooked them.
-Adrian
