Forum: Rails Engines Re: Configuration/Initialization question

I too am annoyed by having to restart my server frequently when editing
plugin assets.  You symlink suggestion seems like it would work, but I
have a question.

Doesn't it just end up copying all the plugin asset files on-top of
themselves at server start?  If so, wouldn't it be better to symlink and
then somehow disable the whole copy process all-together?

Trevor Rowe

On Mon, Aug 27, 2007 at 09:50:37AM -0700, Trevor Rowe wrote:
> I too am annoyed by having to restart my server frequently when editing
> plugin assets.  You symlink suggestion seems like it would work, but I
> have a question.
> 
> Doesn't it just end up copying all the plugin asset files on-top of
> themselves at server start?  If so, wouldn't it be better to symlink and
> then somehow disable the whole copy process all-together?

I hadn't really considered that.  It wouldn't be a problem if it did,
IMHO, but let's look at what it really does.
See engines/lib/init.rb, at the bottom of the file in the method
mirror_files_from:

    source_files.each do |file|
      begin
        target = File.join(destination, file.gsub(source, ''))
        unless File.exist?(target) && FileUtils.identical?(file, target)
          FileUtils.cp(file, target)
        end
      rescue Exception => e
        raise "Could not copy #{file} to #{target}: \n" + e
      end
    end

So you see, it will never actually copy the file because it is identical
to itself.  (this method is called in engines/lib/engines/plugin.rb by
mirror_public_assets)

Regards,
Peter Bex
Solide ICT - http://www.solide-ict.nl

Hi,

Is there a special trick to getting observers to work with engines?

Putting config.active_record.observers = :my_model_observer in the
Initializer.run block throws an unitialized constant MyModelObserver
error.

The my_model_observer.rb file is in vendor/plugins/my_plugin/app/models,
alongside the model being observered, my_model.rb.



Tekin

On 8/29/07, Tekin Suleyman <tekin@raid.nu> wrote:
> Is there a special trick to getting observers to work with engines?

You should be able to do this - the observers aren't processed until
after plugins are loaded (check railties/lib/initializer.rb to be
sure).

What this *might* mean is that there's some error in either your model
or your observer file that's causing a silent failure when the class
is loaded. I saw this recently when a model depended on a file that
wasn't required until the bottom of environment.rb - because the
observer caused the model to be loaded before the rest of
environment.rb had been processed, but the code which the model
depended on hadn't been loaded yet, it would silently fall over and
the problem looked like it was in the observer.

Double check that everything your model needs is required before it's
class definition - this might help.

On Wed, Aug 29, 2007 at 11:47:39AM +0100, James Adam wrote:
> What this *might* mean is that there's some error in either your model
> or your observer file that's causing a silent failure when the class
> is loaded. I saw this recently when a model depended on a file that
> wasn't required until the bottom of environment.rb - because the
> observer caused the model to be loaded before the rest of
> environment.rb had been processed, but the code which the model
> depended on hadn't been loaded yet, it would silently fall over and
> the problem looked like it was in the observer.

Yeah, Rails has the nasty habit of sometimes eating up exceptions.
Then everything seems fine until much later when something fails for
some inexplicable reason.

Sometimes running script/console reveals these errors by displaying
a message somewhere.  Other times, it does not.  Try removing the
observer loading statement and run script/console and refer to
the class.  That should trigger it to autoload, and if there's an
error it will show up.  Rails only drops errors in some circumstances,
not in others.

By the way: Please don't start a new topic by replying to another one.
This confuses mailclients that support threading.   (replying causes
your mailclient to set an In-Reply-To header which tells my client
that this is a reply in the previous thread and it displays it as
such)

Regards,
Peter Bex
Solide ICT - http://www.solide-ict.nl

On 8/29/07, Peter Bex <Peter.Bex@solide-ict.nl> wrote:
> Sometimes running script/console reveals these errors by displaying
> a message somewhere.  Other times, it does not.  Try removing the
> observer loading statement and run script/console and refer to
> the class.  That should trigger it to autoload, and if there's an
> error it will show up.  Rails only drops errors in some circumstances,
> not in others.

You'll need to be careful in this case, because it's the fact that the
observer causes the model to be loaded *before* the rest of
environment.rb has been processed that could be causing the problem.

But, yes, script/console is your friend. You could also try commenting
out anything after the end of the initializer block to see if your
model has any hidden dependencies that it isn't explicitly declaring.

>> Double check that everything your model needs is required before it's

>> class definition - this might help.

I tried again, clearing the model so it was an empty, vanilla
ActiveRecord model and still got the error.

One thing that may or may not be unusual, the error is being thrown
during the loading of the first plugin, which is not the one containing
the observer or the observered model:

loading plugin from script/../config/../vendor/plugins/raid_core with
engine additions
Exiting
/usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support
/dependencies.rb:266:in `load_missing_constant': uninitialized constant
MyModelObserver (NameError)

>> Try removing the observer loading statement and run script/console
and refer to the class.
>> That should trigger it to autoload, and if there's an error it will
show up.
>> Rails only drops errors in some circumstances, not in others.

This was the first thing I tried, both the model and the observer load
fine at the console.


>> By the way: Please don't start a new topic by replying to another
one.
>> This confuses mailclients that support threading.   (replying causes
>> your mailclient to set an In-Reply-To header which tells my client
that this is a reply
>> in the previous thread and it displays it as such)

Apologies, will remember this in future.

On 8/29/07, Tekin Suleyman <tekin@raid.nu> wrote:
> One thing that may or may not be unusual, the error is being thrown
> during the loading of the first plugin, which is not the one containing
> the observer or the observered model:
>
> loading plugin from script/../config/../vendor/plugins/raid_core with
> engine additions
> Exiting
> /usr/local/lib/ruby/gems/1.8/gems/activesupport-1.4.2/lib/active_support
> /dependencies.rb:266:in `load_missing_constant': uninitialized constant
> MyModelObserver (NameError)

At this point, I'd probably recommend throwing puts statements around
every line in the init.rb file of the plugin that causes the error, so
we can trace which line of code is causing the actual problem...

OK, so I thought I'd go back to basics, fresh empty rails app with a
single empty engines enable plugin and still no joy.

With my_model.rb and my_model_observer.rb in app/models, everything
starts up fine. If I move them to vendor/plugins/testplugin/app/models,
I get the same unitialized constant error.

I then tried it without specifying the plugin load order (config.plugins
= ['engines', '*']) and there is no error, despite the plugins loading
in the same order. If I explicitly specify the plugin (config.plugins =
['engines', 'testplugin']), it also works.

Same applies to my app, with the plugin explicitly listed in the config,
it now works.

Is this expected behaviour?

On 8/29/07, Tekin Suleyman <tekin@raid.nu> wrote:
> I then tried it without specifying the plugin load order (config.plugins
> = ['engines', '*']) and there is no error, despite the plugins loading
> in the same order. If I explicitly specify the plugin (config.plugins =
> ['engines', 'testplugin']), it also works.
>
> Is this expected behaviour?

Aaaaah. OK. Here's what's happening.

To support the

  config.plugins = %w(engines *)

behaviour, the engines plugin actually defers loading of any plugins
that weren't specified manually by using the after_initialize
mechanism. You're seeing a problem because, when using that
star-syntax, at the point where Rails is trying to instantiate your
observer your testplugin hasn't been loaded yet.

The solution, for the moment, is to just add your observer-containing
plugins explicitly to config.plugins - that way they will definitely
be available before Rails starts dealing with observers. Another
solution would be to call YourObserverClass.instance at the bottom of
environment.rb, rather than using config.observers - either will work
fine.

>> behaviour, the engines plugin actually defers loading of any plugins
that weren't specified
>> manually by using the after_initialize mechanism. You're seeing a
problem because, when
>> using that star-syntax, at the point where Rails is trying to
instantiate your observer your
>> testplugin hasn't been loaded yet.

OK, that makes sense, thanks.