On Jun 11, 2014, at 9:34 PM, Pier-Olivier Thibault <poth...@gmail.com> wrote:
> You are right. However, the initializers is not really what's discussed here.
> it's the whole directory structure. Anyway, I think config/ folder still has
> its place( and the initializers for all I care). I think the issue is that
> over the years, the project structure for Rails has grown to have a lot of
> different folder and the meaning of all those folders is not that obvious.
> Initializers were never a part of the discussion anyway until you mentionned
> it.
>
The post I originally replied to (from Joe Fiorini) mentioned the config folder
potentially being unnecessary. That would tend to involve initializers. :)
—Matt Jones
> On Wednesday, June 11, 2014 6:42:52 PM UTC-4, Matt jones wrote:
>
> On Jun 11, 2014, at 3:13 PM, Pier-Olivier Thibault <pot...@gmail.com> wrote:
>
>> On Wednesday, June 11, 2014 3:57:59 PM UTC-4, Matt jones wrote:
>>
>> On Jun 11, 2014, at 12:32 PM, Joe Fiorini <j...@joefiorini.com> wrote:
>>
>>> I actually played with simplifying the structure some time ago, although
>>> for a completely different use case. I didn't end up going further than
>>> posting this PoC on Github, but it does actually boot up a Rails app.
>>>
>>> My changes:
>>>
>>> I moved all application/environment config into a file called
>>> "{APP_NAME}.rb". Inside this file I have a module/class definition for the
>>> application the same as any standard Rails app (looks like I accidentally
>>> made it a class rather than Application class inside APP_NAME module,
>>> oops), but I also added a Ruby DSL for specifying environment configs. IME,
>>> the files under config/environments don't normally get a ton of options, so
>>> having them all in one place would actually be easier.
>>>
>>
>> Would this mean smashing all the files in config/initializers into one file?
>> That would make generators that wanted to create a default initializer (for
>> instance, the Devise InstallGenerator) much more complicated since they’d
>> need to insert code into the singular environment.rb file rather than just
>> drop a whole file into config/initializers.
>>
>> I believe it would be the opposite, people, instead of using the
>> config/initializers/*.rb, they would use mechanics that Rails provides by
>> default - The initializer method that any railtie class have. Here's an
>> example of an application.rb file that would include such
>> initializer:https://gist.github.com/pothibo/a32f686aed0f03729157
>
> In your example, the generator would have to *insert* an additional
> `initializer ‘whatever’ do` block into the existing generator. That’s already
> going to make things more complicated; finding the appropriate place is not
> trivial, especially if the generator needs to play nice with namespaced
> applications, such as:
>
> module MyTopLevel
> module MyProject
> class Application < Rails::Application
>
> initializer 'configure devise' do |app|
> app.config.devise.somethin = 'blabla'
> end
> end
> end
> end
>
> A simplistic strategy (“insert before the 2nd end from the end of the file”)
> will fall down here.
>
> More importantly, the *size* of what’s added is significant. The Devise
> generator alone drops 260+ lines (mostly comments) to help users configure
> things.
>
> The application.rb file seems like it could get quite long, and then somebody
> will propose to split it up into, say, a directory of smaller files… :)
>
> —Matt Jones
>
>>
>> I also haven’t seen much discussion of the “set up the paths but don’t load
>> the whole env” reasoning for boot.rb being separate from environment.rb
>> (mentioned down-thread by Ryan Bigg). Is this still something useful? If it
>> isn’t, how will (for instance) Rake tasks that don’t depend on :environment
>> be switched over?
>>
>> —Matt JOnes
>>
>>
>>
>>> I also removed the "app" folder and put directories that were in that
>>> folder in the root. This change was specific to the particular use case I
>>> was designing this for, API-only apps that don't have as much need for the
>>> "app" distinction.
>>>
>>> Once I started thinking about a smaller Rails structure, the idea of the
>>> "config" folder seemed unnecessary. Anytime I need access to my app's
>>> environment I require "application.rb", so to me the distinction between
>>> that and "environment.rb" doesn't serve much purpose. Given that, why can't
>>> "boot.rb" be in the root and all the environment config be consumed into
>>> "application.rb" with a DSL for creating environments like above?
>>>
>>> On Tuesday, June 10, 2014 6:50:48 PM UTC-4, Pier-Olivier Thibault wrote:
>>> How would you execute the rails binary without using `bundle exec` within
>>> an application? Wouldn't that defeat the purpose of binstubs? Rails isn’t
>>> installed on anything but our development machines outside of bundler.
>>>
>>> I think this is somewhat open to discussion. What is the difference between
>>> 'bundle exec rails server' and './bin/rails server' besides the longer
>>> command, of course?
>>>
>>> I would personally pay the cost of longer commands to see lighter project
>>> file structure as I'm going to spend much more time in the project than I
>>> will executing commands. It's important to note that rake tasks are going
>>> to stay as is.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "Ruby on Rails: Core" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to rubyonrails-co...@googlegroups.com.
>>> To post to this group, send email to rubyonra...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Ruby on Rails: Core" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to rubyonrails-core+unsubscr...@googlegroups.com.
>> To post to this group, send email to rubyonra...@googlegroups.com.
>> Visit this group at http://groups.google.com/group/rubyonrails-core.
>> For more options, visit https://groups.google.com/d/optout.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Ruby on Rails: Core" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rubyonrails-core+unsubscr...@googlegroups.com.
> To post to this group, send email to rubyonrails-core@googlegroups.com.
> Visit this group at http://groups.google.com/group/rubyonrails-core.
> For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: Message signed with OpenPGP using GPGMail
