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 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.
Logical fallacy: false analogy.These are different knowledge domains. One way or another a user must understand the domain they work with. If someone does understand the technical domain they shouldn't have a problem following the instructions in the technical production setup guide. On the other hand if someone does not understand, and shouldn't be expected to understand, the system level settings they might still trying to play with things there and would complain of lack of documentation for things like JDBC URI strings that I don't think we want to get into documenting for end-users. We certainly could, but do we really want to make that a priority?
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.
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...
-David
David E Jones <[EMAIL PROTECTED]> wrote:It doesn't really have anything to do with concurrency, my concerns iswith 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 (ifpossible!) 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.
smime.p7s
Description: S/MIME cryptographic signature
