I was just thinking at webmin as an example, like Windows registry is another bad one. It's bad because if the file (yes it's all in one file !!!) is corrupted you just have to pray that its backup is not (and be able to understand what it takes to recreate it). Else you can reinstall Windows. I was always able to use the backup, but it's really frightening. Actually Windows is something behind game consoles and real systems :o)
Jacques De : "Chris Howe" <[EMAIL PROTECTED]> > Almost nine months ago: http://www.nabble.com/Xindice-td9662303.html#a9662303 > ;-) > My major issue reason for abandoning looking into webmin as a solution was > that you need to know additional scripting languages to accomplish it. This is a barrier to entry for me, but more importantly, it would be a barrier of entry to someone wanting to customize the configurator in OFbiz. > > ----- Original Message ---- > From: Jacques Le Roux <[EMAIL PROTECTED]> > To: dev@ofbiz.apache.org; Jacques Le Roux <[EMAIL PROTECTED]> > Sent: Saturday, December 15, 2007 8:30:16 AM > Subject: Re: OfBiz System Configuration Wizard > > > Mmmm... : > > http://www.nabble.com/What-does--22OOTB-front-end-accessibility-22-mean-to-you--to8138284.html#a8155140 > > Almost one year ago... > > Jacques > > De : "Jacques Le Roux" <[EMAIL PROTECTED]> > > > > Sorry for misinterpretation David. Actually I was thinking about > Chris's idea and at this time it was not even clear in my mind > that > > we spoke only about system parameters as Adrian repeated. > > > > For me it's clear that business level parameters should all be/stay > in DB and should only be accessed through the UI of their (and > > only their) respective components (to keep components independent). > There should be as less as possible exceptions to this rule. I > > have already expressed my opininon about that in the past (I did not > then understand that there was not only accouting periods set > > in Webtools/Custom time periods) > > > > I like the idea to have an UI to set system parameters. I was > thinking about something like Webmin http://www.webmin.com/. Of > course > > this parameters could stay in properties files. > > But if I can try an analogy we are currently using some sort of > Windows 3.1 ini files (webmin too). Remember(?), Windows 95 has > > introduced the concept of registry to replace those cluttered files. > > This is what I think Chris is really talking about, a centralised > place where all parameters are "easily" accessible and safe. For > > the framework it's not a problem to centralise since it is monolithic > (you need every pieces to make it works) > > > > Both these approach have pro and cons (properties files are easy to > manipulate, but as Chris insisted you can't ensure > consistency). > > Having an UI to, for instance, set ports concurently sounds like > promising, isn'it ? > > We have already enough things to think about (most of the time I > forget the url.properties file, ok it's not a big deal as I know > it > > exists, and in such a case a newbie should read the setup doc) > > > > Maybe it's sledge hammer to kill a fly, tough ? Is anybody really > ready to do the work ? Chris ? > > > > Jacques > > > > > > De : "Chris Howe" <[EMAIL PROTECTED]> > > > I'm not suggesting an actual change of ports while running, just > changing the configuration files. There would be an ofbiz > reset > > involved. Just when it comes back up, if it's not changed > concurrently, it won't be accessible. > > > > > > ----- Original Message ---- > > > From: David E Jones <[EMAIL PROTECTED]> > > > To: dev@ofbiz.apache.org > > > Sent: Saturday, December 15, 2007 12:38:42 AM > > > Subject: Re: OfBiz System Configuration Wizard > > > > > > > > > > > > Wow, I didn't even realize we were considering something to change > > > ports on the fly. Has anyone even done a proof of concept to see if > > > the various infrastructure pieces we're using even support that? I > > > guess in theory they should, but you're getting into a LOT more > than > > > just reading and writing files or something... you may have to > unload > > > and reload different objects and everything that depends on > them.... > > > Beyond a proof of concept that would also have to be tested a lot > > > because those tend to be error prone sorts of things, especially > when > > > the infrastructure was not originally written with that in mind. > > > > > > -David > > > > > > > > > On Dec 14, 2007, at 10:58 PM, Chris Howe wrote: > > > > > > > To use the http port setting again. If you're using the UI to > > > > change the port and you only change one of the files, you likely > > > > will have to go back and change the file by hand after a restart > > > > because the UI won't be accessible. Whereas if it were changed > in a > > > > > > > transactional manner it either fails and you're presented with > the > > > > same UI or it passes and the new settings take effect properly. > > > > > > > > Also in the case of conflicting changes. Beanshell, email, http, > > > > etc all need to be running on different ports. If you happen to > > > > have them running on a port that Ofbiz already has in use, you > > > > likely won't be able to get back to a UI to correct the mistake. > In > > > > > > > a transactional manner, you're able to run a service to verify > such > > > > things before committing it back to the file system. > > > > > > > > ----- Original Message ---- > > > > From: David E Jones <[EMAIL PROTECTED]> > > > > To: dev@ofbiz.apache.org > > > > Sent: Friday, December 14, 2007 11:35:33 PM > > > > Subject: Re: OfBiz System Configuration Wizard > > > > > > > > > > > > > > > > The transactional nature sounds wonderful, but what problem does > it > > > > actually solve? > > > > > > > > -David > > > > > > > > > > > > On Dec 14, 2007, at 10:32 PM, Chris Howe wrote: > > > > > > > >> d) Load the config files into an XML database (Apache Xindice) > > > >> manipulate with a UI/wizzard to your heart's content, verify the > > > >> structure against an xsd, flush it to the original filename. > The > > > >> benefit of using an xml database as opposed to just > reading/writing > > > >> the original file is that you're able to make the changes in a > > > >> transaction manner. For instance changing the http port, you > can > > > >> change url.properties and ofbiz-containers simultaneously. > > > >> > > > >> ----- Original Message ---- > > > >> From: Jacopo Cappellato <[EMAIL PROTECTED]> > > > >> To: dev@ofbiz.apache.org > > > >> Sent: Friday, December 14, 2007 11:08:01 PM > > > >> Subject: Re: OfBiz System Configuration Wizard > > > >> > > > >> > > > >> 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 > > > >> > > > >> > > > >> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
