[Rails-core] Re: Handling cases when a timezone isn't applicable

Dave, You can currently opt out of time zone aware attributes for specific attributes like so: class Flight < ActiveRecord::Base ... self.skip_time_zone_conversion_for_attributes = [:departure_time, :arrival_time] ... end With this setup, no time zone conversions will be done for Flight#d

[Rails-core] Re: can't run: rake gems:install if application.rb depends on initializers

Please have a look at http://groups.google.com/group/rubyonrails-core/browse_thread/thread/73f21c47d114b88e I managed to split this thread when changing the subject. On edge, application.rb won't be loaded by default anymore (Matt did give the details), so it's not a plugin issue at all. Best O

[Rails-core] Re: can't run: rake gems:install if application.rb depends on initializers [REPRODUCED]

Thanks Matt, applied to the broken app example and it worked perfectly. Also commented on the ticket. On Tue, Nov 25, 2008 at 7:38 AM, Matt Jones <[EMAIL PROTECTED]> wrote: > Patch is on lighthouse and includes a test for this case: > http://rails.lighthouseapp.com/projects/8994-ruby-on-rails/tic

[Rails-core] Handling cases when a timezone isn't applicable

I've run into the following issue: My app has multiple users from multiple timezones. In the majority of cases, I want datetime columns to take into account the user's timezone. This works fine. However, for *one* particular datetime field, I want users to enter the arrival date & time of a flig

[Rails-core] Re: can't run: rake gems:install if application.rb depends on initializers

I've seen something similar, where application.rb gets required when I'm trying to run rake db:migrate. I guess there's some plugin we're all using. On Nov 25, 1:26 pm, Chris Cruft <[EMAIL PROTECTED]> wrote: > I've seen this behavior as well: my initializers were not being run > during a gem ins

[Rails-core] Re: GemPlugin install scripts

On Tue, Nov 25, 2008 at 20:59, Donald Ball <[EMAIL PROTECTED]> wrote: > > I would guess the > thing to do would be to create a new gems task, gems:plugin:install or > similar, which would invoke the install scripts on all config.gems > that have been tagged with :plugin => true. I agree that the

[Rails-core] GemPlugin install scripts

I'm writing a rails plugin, and figured I'd do it as a GemPlugin to be ahead of the curve. I need to install some assets when the plugin is installed in a rails app, but it would seem there's no mechanism by which this occurs; install.rb is never run for a GemPlugin, unless I'm missing something e

[Rails-core] Re: New CSRF tokens

On Nov 23, 8:07 am, "Michael Koziarski" <[EMAIL PROTECTED]> wrote: > Hey guys, > > I've just committed a change to the way we generate and use CSRF > tokens in rails[1].  Instead of all the stuff involving :secret and > session ids, we simply take advantage of ActiveSupport::SecureRandom. >  This

[Rails-core] Re: can't run: rake gems:install if application.rb depends on initializers

I've seen this behavior as well: my initializers were not being run during a gem install, but application.rb was being required. Inside initializer.rb, the "gems_dependencies_loaded" test was not being met and so the "load_application_initializers" method had no effect. In my case, the initiali

[Rails-core] Re: asset_host, Procs and the request object

I've added a patch with some tests to highlight an issue with asset_host and ActionMailer: rails.lighthouseapp.com/projects/8994-ruby-on-rails/tickets/1394- compute_asset_host-bombs-when-asset_host-proc-and-called-from-a-mailer There's also a patch to fix this problem. I have a question: Doe

[Rails-core] Re: Git repos in vendor/gems

I'm currently implementing some infrastructure for managing plugins, but if could easily support this, too. The relevant parts are in railties/lib/plugin_manager. On Nov 25, 11:27 am, Cristi Balan <[EMAIL PROTECTED]> wrote: > On 25 Nov 2008, at

[Rails-core] Re: Git repos in vendor/gems

On 25 Nov 2008, at 07:57, Matt Jones wrote: > > The discussion on #553 in Lighthouse got me thinking - would it be > useful to enable > vendored gems to be git repos? WIth many gems moving to github, most > have a working > copy of the gemspec in the repo. > > For instance, a trunk copy of, say,