views:

33

answers:

1

Being the one always trying to boil things down to common patterns, I'm having a hard time figuring out the best and/or recommended ways of managing all those random properties throughout an application. I am looking for some SO wisdom.

What are the random properties I'm talking about? Here's a small list:

  • favicon
  • alt text for random but common icons like the logo and social icons
  • menu titles and nested menu titles
  • copyright info
  • form and button labels
  • default text in form fields
  • tooltips
  • text like "Leave a Comment" or "Send us an Email" or "Click here to cancel reply."
  • featured posts
  • author name

The first big project I worked on was customizing the Spree eCommerce System (I'm a Rails guy), and they keep a lot (not all) of that config stuff in deeply nested yaml files which they use in their html templates like <h1>t('checkout_steps.payment')</h1> for example. Then there are things like settingslogic and others which work in similar ways. I like those approaches, but it's still not clear to me if that's the best way to go...

I'm (more than) wondering, how do you, the SO reader:

  • Organize your code to effectively manage the upwards of 200+ random settings?
  • What kind of system do you have in place? What kind of patterns do you use?
  • Do you let your client customize these in some way?

Looking for a nudge in the right direction. Starting out learning how to program, you learn about code separation and explicitly defining classes, and not wiring things together so they become a mess. But custom/random settings/configuration don't seem to follow any of those rules, and they're completely left out of the picture. So I'm just wondering how you think about them. I don't feel like going through the code and changing values throughout a set of HTML templates is the best option....

In short: WTF is a "setting", and how do we use them correctly?

Looking forward to your insight.

A: 

Dont mix what is considered configuration to what is considered trenslation. In your application you should have the following:
1. Core config vars. variables that must be configured so your app would start. Theese are for most apps database parameters, ldap parameters etc. Theese are mostly stored in yaml files, under /config dir.
2. Global config vars. variables that can be configured after your app starts, may have a UI in the app. theese are mostly stored in yaml files, under /config dir. or a special DB table.
3. UI text translations and localization. Theese are mostly stored in yaml files, under /config/locales dir.

clyfe
thanks for drawing these distinctions, could you elaborate on how you might say "this is a setting, this is a model", or how you let the user modify these things? Or even better, how many configuration variables do you have in your applications? Or even BETTER, a github link to your application with an example.
viatropos