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 > > >> > > >> > > >> > > > > > > > > > > > > > > > > > > > > >
