On Wed, Jun 27, 2012 at 5:33 PM, Mark Ratjens <[email protected]> wrote:
> The reason we've gone down the metadata track is we want users to be able > to build as much of it as possible, rather than relying on developers > writing DSL. We're pragmatic though, and recognise some things are just > worth 'hardening' a bit more: a developer would prefer to work closer to > the code. So I see out two approaches as being applicable, depending on the > context and complexity of the varieties required. > > That sounds cool. But how do you deal with the problems that come with having lots of configuration in the database, a la Drupal (or Wordpress with ACF, or MODx, or RadiantCMS, or even Spree sometimes)? Previous experience with this sort of setup has lead to: - A lot of pain moving "configuration" data between development, staging, live (and the other way, or between two development systems). Wordpress has an XML dump, Drupal has things like Aegis (?) or Export module, and MODx and RadiantCMS just have pain and horror. - Losing the benefit of tooling that code versioning brings. Even if you have something like Mongo or CouchDB that versions documents, how do you do things like branching when you're working on features? (Seed files and export dumps everywhere?) I'm not trying to be difficult, sorry, but I haven't yet seen this done in a way that isn't really painful. I'm happy to learn about any alternate approaches you or the list might suggest. - Rob H -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
