Configuration Data

[Mark <ma...@xeric.net>]

I have an application that requires a great deal of configuration data
after the app is running and needs to be configurable by the end user
from within the application  This includes things like Facebook admin
id, Twitter account info, Mailchimp api key, etc.

So far I've been just creating objects, storying them in the database
and then accessing them using Hibernate. However this is getting a bit
cumbersome and I'd prefer to use some type of properties file that I
can configure by hand or have the end user update from within the
application.  So it needs to be something where:

1. If the property is changed it gets saved back to the file.
2. Changes can be made at run time without reloading the application.

I like the way you can inject values from Tapestry Symbols, but I
didn't see an easy way to load and save the symbols to/from a
properties file.

My plan was to use the Apache Common's Configuration for this, but I
wanted to make sure I didn't overlook some built in capability and
re-invent the wheel.

Does anyone have any suggestions?

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Configuration Data

[Mark <ma...@xeric.net>]

On Sun, Feb 20, 2011 at 6:34 AM, Vangel V. Ajanovski <aj...@ii.edu.mk> wrote:
> If you already use a database in the project and if the project is depending
> on the operation of the database, than I would say that there is no reason
> that is sufficient to justify the use of a property file beside the
> database. Especially when you have many users which are all configuring
> their stuff.
>
> Reinventing a wheel in such case would be to NOT use the database (you will
> have the problems of multi-user concurent access and file-locking,
> versioning, ACID transactions).
>
> I would also add that you shouldn't split the user profile personal data
> from the user profile configuration data - they are both user personal data
> and according to privacy-related laws should be
> protected. If you split it, than you will have two separate locations to
> deal with and protect (database and file).
>
> Most web applications I have seen that have a lot of user configuration
> data, store it in a single table that will mimic the property file, that has
> a composite key like this:
> (#userid, #property-key, value)
>
> Is this what you're currently doing? Because from what I read, it sounded
> like you are creating separate entity classes for separate properties.

Originally I was using Entity classes which was making things more
complicated than they needed to be and that prompted my original
question. The single table that mimics the property file is what I'm
doing now and I wanted to make sure there weren't any built in
facilities for reading and writing these files or the keys to a
database that I was overlooking.  I started experimenting with Apache
Commons Configuration an it lets me use a properties file, XML or a
database. Changes from the web interface get written to the file and
changes to the file get immediately read back into the web
application.

Thanks for your suggestions!

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Configuration Data

["Vangel V. Ajanovski" <aj...@ii.edu.mk>]

On 19.02.2011 16:36, Mark wrote:
> I have an application that requires a great deal of configuration data
> after the app is running and needs to be configurable by the end user
> from within the application  This includes things like Facebook admin
> id, Twitter account info, Mailchimp api key, etc.
>
> So far I've been just creating objects, storying them in the database
> and then accessing them using Hibernate. However this is getting a bit
> cumbersome and I'd prefer to use some type of properties file that I
> can configure by hand or have the end user update from within the
> application.  So it needs to be something where:
>
> 1. If the property is changed it gets saved back to the file.
> 2. Changes can be made at run time without reloading the application.
If you already use a database in the project and if the project is 
depending on the operation of the database, than I would say that there 
is no reason that is sufficient to justify the use of a property file 
beside the database. Especially when you have many users which are all 
configuring their stuff.

Reinventing a wheel in such case would be to NOT use the database (you 
will have the problems of multi-user concurent access and file-locking, 
versioning, ACID transactions).

I would also add that you shouldn't split the user profile personal data 
from the user profile configuration data - they are both user personal 
data and according to privacy-related laws should be
protected. If you split it, than you will have two separate locations to 
deal with and protect (database and file).

Most web applications I have seen that have a lot of user configuration 
data, store it in a single table that will mimic the property file, that 
has a composite key like this:
(#userid, #property-key, value)

Is this what you're currently doing? Because from what I read, it 
sounded like you are creating separate entity classes for separate 
properties.

Re: Configuration Data

[Mark <ma...@xeric.net>]

Ok thats what I've started  using, but I wanted to make sure there wasn't
some built in Tapestry capability to write back to properties files.  I'd
rather not re-invent the wheel when I don't have to.

Thanks!

Mark

On Sat, Feb 19, 2011 at 2:11 PM, Werner Keil <we...@gmail.com> wrote:

> It's non trivial, but Apache Commons Config worked for us in another
> project (With Selenium2, not Tapestry, but it should work for the web
> container just as well as the Functional Web Test[?])
>

Re: Configuration Data

[Werner Keil <we...@gmail.com>]

It's non trivial, but Apache Commons Config worked for us in another project
(With Selenium2, not Tapestry, but it should work for the web container just
as well as the Functional Web Test[?])

Re: Configuration Data

[Mark <ma...@xeric.net>]

On Sun, Feb 20, 2011 at 5:34 AM, Ulrich Stärk <ul...@spielviel.de> wrote:
> There is a SymbolProvider for properties files in the non-public parts of the API. Have a look at that.

I'm using those in a few places where I need to set a value once
before the app is started.  However, I was wanting something that
would handle automatically writing the values back to the the config
file for configuration data that the end user needs to change.

Is there a way to save changes back to a file using SymbolProvider?

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: Configuration Data

[Ulrich Stärk <ul...@spielviel.de>]

There is a SymbolProvider for properties files in the non-public parts of the API. Have a look at that.

Uli

On 19.02.2011 16:36, Mark wrote:
> I have an application that requires a great deal of configuration data
> after the app is running and needs to be configurable by the end user
> from within the application  This includes things like Facebook admin
> id, Twitter account info, Mailchimp api key, etc.
> 
> So far I've been just creating objects, storying them in the database
> and then accessing them using Hibernate. However this is getting a bit
> cumbersome and I'd prefer to use some type of properties file that I
> can configure by hand or have the end user update from within the
> application.  So it needs to be something where:
> 
> 1. If the property is changed it gets saved back to the file.
> 2. Changes can be made at run time without reloading the application.
> 
> I like the way you can inject values from Tapestry Symbols, but I
> didn't see an easy way to load and save the symbols to/from a
> properties file.
> 
> My plan was to use the Apache Common's Configuration for this, but I
> wanted to make sure I didn't overlook some built in capability and
> re-invent the wheel.
> 
> Does anyone have any suggestions?
> 
> Mark
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org