On Thu, Jun 12, 2008 at 6:01 PM, Adam Keys <[EMAIL PROTECTED]> wrote: > > On Jun 12, 2008, at 11:40 AM, James Adam wrote: >> >> I guess this boils down to - why generate the Hash, when just writing >> the Hash is pretty much equally readable? Do we get some benefit using >> the block/DSL-style syntax? If not, the implementation could perhaps >> be simpler. >> > > Running it through a proxy makes it easier to yell at the user when > they try to set username/password in production. Also, credentials is > handled differently from the other attributes. One could do all that > with a Hash, but why apply behavior to data when you can bundle the > data with the behavior?
If the behaviour you mean is simply to ensure that production credentials are loaded from an external file, there are surely simpler ways of doing this than building a Ruby DSL (loathe as I am to use that word, but you get what I mean). My concern is that this is *too much solution*, even for the benefits that it claims, and keeping Rails lithe and slim should be a priority. The problems with the current setup need to be much clearer - "database.yml is workable, but its a little weird at this point" isn't sufficient reason to change, IMHO. Weird how? I'm not suggesting that it isn't weird, but we should have some explicit reasons or examples. Likewise, "there is no other instance of YAML configuration in one's app when it runs in production" is a bit misleading: the database is the *only common external dependency* in a Rails application. It is a description of something outside of the Ruby process (unlike any ruby libraries or frameworks you might be loading). If every Rails application had to also interface with, say, Solr, we'd probably have a config/solr.yml file too. As Frederick Cheung points out, another solution to the "DRY" concern is using YAML in a smarter way. Rick suggested that "[it's] a lot harder to read and write, especially for newbies", but we could solve that by providing comments in the file to educate. Making the change to a ruby-based configuration will still confuse newbies, thanks to Google and all the tutorial pages that won't be updated. In a nutshell, lets be sure that we're solving genuine problems and/or providing tangible benefits, before we make the framework that little bit more complicated. -- * J * ~ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" 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/rubyonrails-core?hl=en -~----------~----~----~----~------~----~------~--~---
