Rails - May 2005 - Including a /lib file within a module doesn't work?

I wrote a little library to factor out some common code in my  
controllers.  When I "include" this code within a plain vanilla  
controller, it''s fine.  But apparently if I use it inside a  
controller within a module, it breaks.

This works:

class BrowseController < ApplicationController
   include MovieSearchBundle
   def list
     @search_title = human_title_from_search_terms(@session 
[''search_text''],
@session[''search_genre_id''])
   end
end

This doesn''t:

class Admin::MoviesController < ApplicationController
   include MovieSearchBundle
   def list
     @search_title = human_title_from_search_terms(@session 
[''search_text''],
@session[''search_genre_id''])
   end
end

The error is as follows:

     uninitialized constant MovieSearchBundle::Genre

And the culprit is right here (inside my MovieSearchBundle module,  
human_title_from_search_terms method):

       title_genre = "in the " + Genre.find(genre_id).name + "
genre "

So, why is it trying to find my Genre model within the  
MovieSearchBuncle module?  I want it to go outside the  
MovieSearchBundle module and find the Genre class, just like it did  
in the BrowseController class (the one without the Admin:: module).

Duane

Does MovieSearchBundle include Genre?


Duane Johnson wrote:
> I wrote a little library to factor out some common code in my  
> controllers.  When I "include" this code within a plain vanilla  
> controller, it''s fine.  But apparently if I use it inside a  
> controller within a module, it breaks.
>
> This works:
>
> class BrowseController < ApplicationController
>   include MovieSearchBundle
>   def list
>     @search_title = human_title_from_search_terms(@session 
> [''search_text''],
@session[''search_genre_id''])
>   end
> end
>
> This doesn''t:
>
> class Admin::MoviesController < ApplicationController
>   include MovieSearchBundle
>   def list
>     @search_title = human_title_from_search_terms(@session 
> [''search_text''],
@session[''search_genre_id''])
>   end
> end
>
> The error is as follows:
>
>     uninitialized constant MovieSearchBundle::Genre
>
> And the culprit is right here (inside my MovieSearchBundle module,  
> human_title_from_search_terms method):
>
>       title_genre = "in the " + Genre.find(genre_id).name +
" genre "
>
> So, why is it trying to find my Genre model within the  
> MovieSearchBuncle module?  I want it to go outside the  
> MovieSearchBundle module and find the Genre class, just like it did  
> in the BrowseController class (the one without the Admin:: module).
>
> Duane
> _______________________________________________
> Rails mailing list
> Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
> http://lists.rubyonrails.org/mailman/listinfo/rails
>


_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

> So, why is it trying to find my Genre model within the  
> MovieSearchBuncle module?  I want it to go outside the  
> MovieSearchBundle module and find the Genre class, just like it did  
> in the BrowseController class (the one without the Admin:: module).
This should have been fixed by http://dev.rubyonrails.com/ticket/1173  
which was applied yesterday and is available in beta gems/svn.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework

On May 20, 2005, at 6:23 AM, David Heinemeier Hansson wrote:
> This should have been fixed by http://dev.rubyonrails.com/ticket/ 
> 1173 which was applied yesterday and is available in beta gems/svn.
Fantastic!  Thanks David.

Although I''ve been with the Rails project for a while now, I''m
still
a bit hazy on the patching process.  It seems there are a lot of  
patches in the queue--is it a manpower factor that makes the patching  
process a slow one?  Or is it intentionally drawn out so as to  
provide time to debate issues?  Is there a way we can communicate  
better with you and the core developers so that patches are more "in  
line" with the vision you have?

I suppose I have a specific motive in mind when calling to mind these  
questions.  Joseph Hosteny and I worked on a patch (#1196) that seems  
like it would be a nice feature for the next release.  It has been  
tested and proven stable, though It''s been in the patch queue now for  
a few weeks.  What might be the hold up on that one?

Keep up the great work, at any rate :)

Duane Johnson
(canadaduane)

_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails

> Although I''ve been with the Rails project for a while now,
I''m
> still a bit hazy on the patching process.  It seems there are a lot  
> of patches in the queue--is it a manpower factor that makes the  
> patching process a slow one?  Or is it intentionally drawn out so  
> as to provide time to debate issues?  Is there a way we can  
> communicate better with you and the core developers so that patches  
> are more "in line" with the vision you have?
There are two kinds of patches. Those I instantly get and like the  
implementation of and those I either need to contemplate further or  
have immediate reservations against. The first kind is usually  
applied as soon as I spot them, the second kind can easily sit around  
until I must make a decision on them (usually just before a release).
> I suppose I have a specific motive in mind when calling to mind  
> these questions.  Joseph Hosteny and I worked on a patch (#1196)  
> that seems like it would be a nice feature for the next release.   
> It has been tested and proven stable, though It''s been in the
patch
> queue now for a few weeks.  What might be the hold up on that one?
I actually had a brief look at it yesterday, but didn''t dig in  
further because it was really long and I didn''t have the mental  
capacity available to follow the thread.

I now see that you guys ended with the :if solution. A way of  
increasing the chances of being applied would be to close the old :on  
=> :virtual and create a new ticket for the :if approach that just  
held the conclusions with a link back to the closed patch.

In general, it''s also a great idea to make many small patches instead  
of one large. That''s not so much a problem of this patch, but others  
have grouped unrelated stuff together. I''m much less likely to apply  
a big ball all at once than many smaller, coherent patches.
--
David Heinemeier Hansson
http://www.loudthinking.com -- Broadcasting Brain
http://www.basecamphq.com   -- Online project management
http://www.backpackit.com   -- Personal information manager
http://www.rubyonrails.com  -- Web-application framework



_______________________________________________
Rails mailing list
Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org
http://lists.rubyonrails.org/mailman/listinfo/rails