Code Configuration vs Properties Configuration

[Tim Perrett]

Chaps,

Just playing around with something at the moment that has a bunch of
global parameters - what are peoples opinions on configuring things
with code vs configuring them with properties files? Pro's and Con's?

What about commons configuration? What's the most /lift/ way of doing
this?

Cheers for any opinions / advice

Tim

[David Pollak]

Tim,

I like a balance between the two.

lift's properties system will pick up different properties based on user, host, and run-mode.  Properties used to define database connections is very helpful.  Properties as things that a sysadmin can change are good.

Testing the properties in Boot is what I typically do and I base the Boot code path configuration on the properties.

Need more?

Thanks,

David

--
lift, the simply functional web framework http://liftweb.net
Collaborative Task Management http://much4.us
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

[Tim Perrett]

> lift's properties system will pick up different properties based on user,
> host, and run-mode.

Yeah looking through the lift source I see that - although as far as
im aware the run modes don't actually do anything yet do they?

> Properties used to define database connections is very
> helpful.  Properties as things that a sysadmin can change are good.

+1... couldnt agree more. Thats why im looking at this to be honest,
so that sysadmins can change things without changing code. Taking your
example of the database configuration, i remember a while back there
was talk of doing a rails style config for the database connectivity
in lift, did that ever happen?

Looking at net.liftweb.util.Props, I see how the properties are being
loaded and what the filename should be etc, but where do they need to
be stored in terms of the maven lift root? Resources?

> Testing the properties in Boot is what I typically do and I base the Boot
> code path configuration on the properties.

Im not sure I follow, when you say you test the properties in boot? Do
you mean you check for their existence?

Cheers

Tim

[David Pollak]

Tim Perrett wrote:

lift's properties system will pick up different properties based on user,
host, and run-mode.
    

Yeah looking through the lift source I see that - although as far as
im aware the run modes don't actually do anything yet do they?
  

lift does little (or maybe nothing) with run modes.  Marius and I have bounced around a few things regarding when resources are loaded and parsed and that'd be run-mode dependent.

 Properties used to define database connections is very
helpful.  Properties as things that a sysadmin can change are good.
    

+1... couldnt agree more. Thats why im looking at this to be honest,
so that sysadmins can change things without changing code. Taking your
example of the database configuration, i remember a while back there
was talk of doing a rails style config for the database connectivity
in lift, did that ever happen?
  

No.  But if you put forward a convention for DB configuration, I'll do the coding.

Looking at net.liftweb.util.Props, I see how the properties are being
loaded and what the filename should be etc, but where do they need to
be stored in terms of the maven lift root? Resources?

  

src/main/resources/props/dpp.horse.props

Testing the properties in Boot is what I typically do and I base the Boot
code path configuration on the properties.
    

Im not sure I follow, when you say you test the properties in boot? Do
you mean you check for their existence?
  

if (Props.getBool("use_postgres")) {...} else {...}

Thanks,

David

Cheers

Tim



  

[Marius]

Hi,

AFAIK lift uses config. properties quite ok, and DB connectivity IMO
is an application concern and not a framework one. Furthermore
typically applications use DataSource's in order to leverage
container's connection pool so DB connectivity would be specified in
container configuration. Indeed some would prefer to not use
DataSource-s in which case the DB configuration is totally an
application concern (IMO).

Br's,
Marius