Michael, Very informative article. What are your thoughts on storing user preferences as xml in a user preferences table? I think your approach would work well, but I alreay have code for parsing XML files. Ultimately, I would like the benefits of storing this data in a database (security, scalability, distributable), but also the benefits of XML hierachies (1...* relationships, code generation tools).
Thanks, Julian --- Michael Klaene <[EMAIL PROTECTED]> wrote: > I would say that 'system' level > configurations(applying to all users) could easily > be handled with XML files or properties files. User > preferences, since they are tied to a specific user, > IMO belong in the database, probably in a user > preferences table. I know XML is a popular choice - > you could create a seperate folder, for each user, > to hold user settings (like a preferences.xml file), > or you could store all user info in one monolithic > file. I don't much like either of these approaches. > I prefer to store application-specific > configurations in the database, using 'codelist' > tables. I wrote an article about it a few months > ago, have a look if you want: > > http://www.developer.com/db/article.php/3413151 > > I wrote an app where I stored all preferences in > codelist tables. Then, I had a user_preferences > table that, instead of referencing a preference_id > in a preference table, referenced a preference in a > codelist name which was about 5 characters in > length. > > Mike > > Daniel Perry <[EMAIL PROTECTED]> wrote: > The most common way to store more than one element > in a properties file is > to have more than one entry like the following: > > colour.count=3 > colour.0=red > colour.1=green > colour.2=blue > > So your code loads the property for colour.count and > loops through the other > properties. Not very elegant, but it works. > > Daniel. > > > -----Original Message----- > > From: Julian [mailto:[EMAIL PROTECTED] > > Sent: 17 November 2004 14:08 > > To: Struts Users Mailing List > > Subject: Re: [OT] User Preference System Design > > > > > > Hi, > > > > Thanks for the input. The Properties object is > more > > inline with what I was thinking. The problem with > it > > however, is that there can only be one key/value > pair. > > I see no ability to have one key with multiple > pairs > > other than doing comma delimitation. This is why > XML > > was chosen originally. The problem with it now is > > that it is not stored in an RDBMS, and I am > unaware of > > the scalability of a user preferences system based > on > > XML. Comments/Suggestions? > > > > Thanks again, > > Julian > > > > --- Erik Weber wrote: > > > > > I like java.util.Properties, or, if Strings > aren't > > > good enough, another > > > wrapper for a Map that allows put/get of Objects > but > > > that uses a > > > hierarchical default system like Properties > does. > > > Properties has built > > > in load/save methods that you can use to store > your > > > properties on disk > > > until you move them to a RDBMS. Base user has > colors > > > A, B, C. Next > > > higher user needs to have a different color A > but > > > inherit colors B and > > > C. Create his properties with the Base user > > > properties as the default, > > > then just put the new property A. Works nicely > for > > > that sort of thing. > > > > > > Erik > > > > > > > > > Julian wrote: > > > > > > >Hi, I am a Struts Newbie and would appreciate > if > > > >anyone could give me some pointers on a user > > > >preferences/ configuration system design. > Perhaps > > > a > > > >link to a good resource? I have an ASP system > with > > > >several levels of "users" that are as broad as > an > > > >organization and as fine-grained as an > individual > > > >person with one role. I would like to have a > > > >preference system that can handle configuration > and > > > >preference issues for the different levels of > the > > > >application. The information stored in these > > > >configurations range from font colors and alert > > > boxes > > > >to the availability of various modules in the > web > > > >application. Currently the information is > stored > > > in > > > >xml files on the server's hard disk, but this > will > > > not > > > >suit a distributable environment. Any > suggestions > > > are > > > >greatly appreciated. > > > > > > > >Thanks in Advance, > > > >Julian > > > > > > > >===== > > > >Live simply so others may simply live. > > > > > > > >-Ghandi > > > > > > > >Pluralitas non est ponenda sine neccesitate. > > > >"Entities should not be multiplied > unneccesarily" > > > > > > > >-William of Occam > > > > > > > > > > > > > > > > > > > > > > > > > > > >__________________________________ > > > >Do you Yahoo!? > > > >The all-new My Yahoo! - Get yours free! > > > >http://my.yahoo.com > > > > > > > > > > > > > > > > > > >--------------------------------------------------------------------- > > > >To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > >For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > > > [EMAIL PROTECTED] > > > For additional commands, e-mail: > > > [EMAIL PROTECTED] > > > > > > > > > > ===== > > Live simply so others may simply live. > > > > -Ghandi > > > > Pluralitas non est ponenda sine neccesitate. > > "Entities should not be multiplied unneccesarily" > > > > -William of Occam > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Tired of spam? Yahoo! Mail has the best spam > protection around > > http://mail.yahoo.com > === message truncated === ===== Live simply so others may simply live. -Ghandi Pluralitas non est ponenda sine neccesitate. "Entities should not be multiplied unneccesarily" -William of Occam __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
