josevalim / inherited_resources
- Source
- Commits
- Network (27)
- Issues (0)
- Downloads (1)
- Wiki (1)
- Graphs
-
Branch:
master
Pledgie Donations
Once activated, we'll place the following badge in your repository's detail box:
Inherited Resources speeds up development by making your controllers inherit all restful actions so you just have to focus on what is important.
-
Since updating inherited_resources from 0.9.3 to 0.9.4, all actions are getting two flashes -- one with :notice and one with :success. Issue is reproducible in base Rails app.
Comments
-
There are some problem areas where exceptions are being silently discarded only to lead to errors further on that are hard to track down.
E.g. class_methods.rb:306 gets the resource class but rescues and returns nil if my model definition has an error, leading to an exception in the IR code later on when it calls find on nil.
There are also "rescue nil" lines in the controller methods that have caused me problems.
Will fork and try to patch in Jan, but if there are any particular reasons for these or no one else experiences this I'd be interested in hearing about it.
Thanks!
Comments
-
I have a resource that has some accessors created within an after_initialize method...
class Project < ActiveRecord::Base def after_initialize # create method... end ...In the controller I have the "new" action automatically created with inherited resources. However, the resource is nil when it hits the "after_initialize". However, if I explicitly add the new method, everyone works fine...
def new @project = end_of_association_chain.new endShouldn't the resource being automatically created with inherited resources also be using end_of_association_chain.new?
BTW - I do have :new listed as an action in the controller, and inherited resources works splendidly almost everywhere
Best regards,
David BaldwinComments
Yeah, that definitely should work. Can you please add a failing test case?
carlosantoniodasilva
Wed Dec 09 02:36:56 -0800 2009
| link
Are you using after_initialize inside private declaration in your model? after_initialize only works if its protected/public.
-
Running into bug using inherited_resources with DataMapper
2 comments Created about 1 month ago by bnoguchiI am trying out inherited_resources with DataMapper. I found that mimes_for_respond_to resolves to nil. Based on my debugging, I think this is because inherited_resources assumes developers are using the class inheritable attribute methods from ActiveSupport, while DataMapper provides a subset of those methods with a different implementation using the Extlib gem. This results in data being stored using ActiveSupport's write_inheritable_attribute method, but that data can't be accessed because inherited_resources ends up using Extlib's class_inheritable_reader, resulting in mimes_for_respond_to resolving to nil. Not sure how to do a work-around gracefully without messing up other libs that depend on DataMapper's Extlib and ActiveSupport.
Comments
jeroenvandijk
Wed Dec 02 01:47:02 -0800 2009
| link
I can confirm InheritedResources (0.9.3) is not working with Datamapper (10.1)
I have quickly tried to redefine the write_inheritable_attribute method, but that didn't work.
-
Update Responder to contain latest Rails Edge changes
1 comment Created about 1 month ago by josevalim -
changing flash messages based on response format
2 comments Created about 1 month ago by blakechambersI still get flash notices when updating a model using js. I may have missed it in the docs, but is there a way to turn that off?
Comments
blakechambers
Tue Nov 24 22:12:10 -0800 2009
| link
BTW, here is my update function currently:
def update update! do |success, failure| success.js { flash.discard(:notice) render @todo } end end -
When I add actions as follow:
> actions :index, :show, :new, :edit, :create, :update and try to delete it's delete the field in database. So, it's a bug! I don't want to delete anything.But, when I add actions like:
> actions :all, :except => [ :destroy ] and try to delete it doesn't delete. So, it's correct because I don't want to create destroy action.Thanks,
Comments
Sorry, I could not understand the issue. Can you please explain it again?
Então vai em português mesmo.
Dentro de um controller se eu dizer as actions que quero tipo:
actios :index, :show
ele ainda aceita outras actions como por exemplo update e destroyQuando eu faço via actions :all, :except => [:updater]
aí funciona. -
It would be nice if in addition to "parent_url", there was "edit_parent_url". Additions/updates to children may often redirect to the edit page of the parent rather than the show. (at least in my apps, but maybe I'm doing it wrong)
Best Regards,
David BaldwinComments
-
acts as tree support (self association)
2 comments Created about 1 month ago by sobrinhoHello,
I tried to use inherited resources with acts_as_tree without success. An example:
class Page < ActiveRecord::Base acts_as_tree end class PagesController < ApplicationController inherit_resources respond_to :html actions :all belongs_to :parent, :optional => true end map.resources :pages, :has_many => :pagesWhen I access http://localhost:3000/pages/3/pages the filter doesn't work.
I got the same behaviour of http://localhost:3000/pages/
You can verify that?
Comments
-
How does IR behave with has_many :through association?
1 comment Created 2 months ago by millisami -
should not assume a parent if belongs_to is specified
1 comment Created 2 months ago by aaronchiI have an invitations controller that I would like to use both nested as well as unnested. The controller is set up like this:
class InvitationsController < ApplicationController
inherit_resources
belongs_to :league
endand I am accessing the controller both from /leagues/{id}/invitations and /invitations
Since inherited_resources always assumes a parent if belongs_to is defined, it throws an error trying to find the parent league when I access the unnested route. Instead, it should check for the presence of the parent_id first and only load the parent if it exists.
Comments
-
Hi,
This thread: http://groups.google.com.au/group/formtastic/browse_thread/thread/9bb5d808d2a9adbf talk about cancel button.
I write a method that I'm using into a initializer file (is a monkey patch in really) but do the proposed feature.
I know that's obstrutive solution using
window.history.back()orwindow.location = url;but the unobstrutive solution aren't greater IMHO (create a inline form reseting all css properties of this form elements using action to proposed url and get method).This sounds to a bad workaround.
The dev will be advised about obstrutivity and I guess that's not a problem considering dev can make the unobstrutive solution by yourself if really needed.
You will use the cancel_button method:
- form.inputs do = form.submit_button = form.cancel_button = form.cancel_button admin_pages_path = form.cancel_button admin_pages_path, { :button_html => { :class => 'pretty_button' } } = form.cancel_button admin_pages_path, 'Cancel updates' = form.cancel_button admin_pages_path, 'Cancel updates', { :button_html => { :class => 'pretty_button' } }The default url is :back, this means, window.history.back() and the default button text is I18n.t('formtastic.cancel', :default => 'Cancel').
If you specify a url, this will be "window.location = #{url.to_json}"
I guess this solve 99.9% of cancel button cases.
See the code: http://paste.pocoo.org/show/145765/
Comments
-
Seeing as how Github no longer supports building gems, can you add this gem to gemcutter? I am currently unable to find it there as I migrate all my old github gems to their gemcutter counterparts.
Comments
-
In my app, I'm using Clearance as my Auth purpose. I'm trying to use IHR.
For the model association,
#user.rb has_many :masterpieces, :dependent => :destroy #masterpiece.rb belongs_to :user
Masterpiece controller:
class MasterpiecesController < ApplicationController before_filter :authenticate, :except => [:show, :index] def index @masterpieces = Masterpiece.all end def new @masterpiece = current_user.masterpieces.build end def create @masterpiece = current_user.masterpieces.build(params[:masterpiece]) respond_to do |format| if @masterpiece.save flash[:notice] = 'Masterpiece was successfully created.' format.html { redirect_to(@masterpiece) } format.xml { render :xml => @masterpiece, :status => :created, :location => @masterpiece } else format.html { render :action => "new" } format.xml { render :xml => @masterpiece.errors, :status => :unprocessable_entity } end end end def show @masterpiece = current_user.masterpieces.find(params[:id]) end endNow when I replace this controller with this version using IHR:
class MasterpiecesController < InheritedResources::Base before_filter :authenticate, :except => [:show, :index] respond_to :html, :js belongs_to :user protected def begin_of_association_chain current_user end endAnd I go to /masterpieces/new
I get the following error:
NoMethodError in MasterpiecesController#new undefined method `users' for #
Comments
carlosantoniodasilva
Thu Oct 08 08:06:40 -0700 2009
| link
Hello!
Actually I think you don't need to declare "belongs_to :user" in your controller, since "begin_of_association_chain" already tell masterpieces will be filtered only by the current_user. Please try removing this belongs_to.
Carlos.
-
Move parent, parent_type and parent_class helpers to belong_to
0 comments Created 2 months ago by josevalimAnd allow parent to be created using association_chain.
Comments
-
make_resourceful adds many methods as action_methods, that is public methods available via web.
I forked this project (http://github.com//jo/make_resourceful/) with a commit to hide those methods (http://github.com/jo/make_resourceful/commit/68e3e4a229e9363eba04388540818e68220194db)
Maybe on finds a better solution for that.
Comments
-
begin_of_association_chain : A small issue, but it's bugging me.
5 comments Created 3 months ago by paulcaShoot me down if I'm being pedantic, but this is Ruby!
I'm wondering if there's any reason for naming "begin_of_association_chain" as such ... it's not correct English, and I feel it sticks out in an otherwise very solid implementation.
I'd hazard that it should be 'beginning_of_association_chain" or "start_of_association_chain"
What do you think? Is this too anal?
Paul
Comments
My bad! :P
Of course it has low priority, but I will change for end_of_association_chain when I have some time! ;)
begin_association_chain, end_association_chain would make sense in Ruby. It's the "ofs" that make it awkward. An alias of start_of_assocation_chain would also make sense.
@dan Agreed, but I think "begin_association_chain" changes the meaning sufficiently to hide the intent ... specifically that this is the first item in the association chain. I think it's just a coincidence that 'end' is a verb and 'beginning' isn't!
to me 'beginning_of_association_chain' is more expressive than 'start_of_assocation_chain' ....
@jose I think it would be wise to alias it as Dan suggests, or at least deprecate for a point release!
Hey Paul, I've tried to do the change, non trivial. I will give up on this, unless you want to provide a patch yourself. Thanks!
-
Hi,
I was trying out inherited_resources today and got it working really well with a test controller in an admin/ namespace ... The controller worked great in Safari, but not so much in Firefox (3.5) ... claiming that the template was not present...
... appending ".html" to the URL makes it work, so I suspect that there's no defaulting to .html in the plugin, perhaps a reliance on the Accept header?
Paul
Comments
Same behaviour when I use respond_to :html within the controller ... I'm using Rails 2.3.4
Could you please reproduce the error in the test suite or through a sample app?
Hmmmm ... it works fine with a similar arrangement in a fresh app ... I'll have to dig about and figure out what's different in this case.
Been using and loving the plugin on a few other projects since this. I'm really not sure what was causing it in the other app, I'll come back to it if it crops up again.
-
Ruby 1.9 mime responder issues (together with AuthHelpers)
4 comments Created 3 months ago by grimenTypeError ({:with=>#} is not a symbol): /Users/jonas/.ruby_versions/ruby-1.9.1-p129/lib/ruby/gems/1.9.1/gems/inherited_resources-0.9.1/lib/inherited_resources/legacy/respond_to.rb:100:in `block in retrieve_response_from_mimes' /Users/jonas/.ruby_versions/ruby-1.9.1-p129/lib/ruby/gems/1.9.1/gems/inherited_resources-0.9.1/lib/inherited_resources/legacy/respond_to.rb:100:in `each' /Users/jonas/.ruby_versions/ruby-1.9.1-p129/lib/ruby/gems/1.9.1/gems/inherited_resources-0.9.1/lib/inherited_resources/legacy/respond_to.rb:100:in `retrieve_response_from_mimes' /Users/jonas/.ruby_versions/ruby-1.9.1-p129/lib/ruby/gems/1.9.1/gems/inherited_resources-0.9.1/lib/inherited_resources/legacy/respond_to.rb:56:in `respond_to' ...Note: I run a slightly modified version of InheritedResources, but only touched rake/tests so far.
Comments
GitHub stripped parts of the output, but it's an instance of a Account that is returned (while calling confirmations_controller/new in my case):
Processing Accounts::ConfirmationsController#new (for ::1 at 2009-09-11 03:31:30) [GET] Parameters: {"controller"=>"accounts/confirmations", "action"=>"new"} ...I believe so; I never got it to work but I'm not running Ruby 1.9 in production anyway so can't tell - was some time ago I was exploring this. I remember I didn't do any hocus-pocus, it was kinda easy to raise that error with Authlogic + AuthHelpers.
-
$ rake test --trace (09-04 03:44) (in /Users/Jonas/Development/examples/inherited_resources) ** Invoke test (first_time) ** Execute test /opt/local/bin/ruby -I"lib" "/opt/local/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake/rake_test_loader.rb" "test/aliases_test.rb" "test/association_chain_test.rb" "test/base_test.rb" "test/belongs_to_test.rb" "test/class_methods_test.rb" "test/customized_belongs_to_test.rb" "test/defaults_test.rb" "test/flash_test.rb" "test/has_scope_test.rb" "test/nested_belongs_to_test.rb" "test/optional_belongs_to_test.rb" "test/polymorphic_test.rb" "test/redirect_to_test.rb" "test/respond_to_test.rb" "test/singleton_test.rb" "test/url_helpers_test.rb" DEPRECATION WARNING: has_scope :key is deprecated, use :as instead. (called from has_scope at /Users/Jonas/Development/examples/inherited_resources/lib/inherited_resources/class_methods.rb:131) /opt/local/lib/ruby/gems/1.8/gems/activesupport-2.3.3/lib/active_support/dependencies.rb:105:in `const_missing': uninitialized constant Test::Unit::TestResult::TestResultFailureSupport (NameError) from /opt/local/lib/ruby/gems/1.8/gems/test-unit-2.0.2/lib/test/unit/testresult.rb:28 from /opt/local/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'While searching for info on this I found:
You can't use Test::Unit 2.0 with old Test::Unit.
Call 'gem "test-unit"' before 'require "test/unit".Comments
-
The syntax:
def create create!{ another_url } endDoes not work with Rspec controller specs if integrate views is false because that template is executed just if a template is not found. Since rspec hacks all templates to be found on integrate_views equals to true, the code is never executed. The solution is to use success and failure blocks:
def create create! do |success, failure| success.html { another_url } end endComments
-
When the exception is raised because no polymorphic association is found, the exception text contains #{polymorphic_symbols.inspect}. It throws another error because polymorphic_symbols doesn't exist.
if key.nil?
raise ScriptError, "Could not find param for polymorphic association. The request params keys are #{params.keys.inspect} and the polymorphic associations are #{polymorphic_symbols.inspect}." unless polymorphic_config[:optional] nilComments
I'm getting this also even with a basic sample similar to the one in the README.
I get the same error with 0.9.0 still... Did I miss something?
Have you restarted your server? I no longer get that error after the update.
-
Encapsulate behavior into parent, so it does not depend on end_of_association_chain
0 comments Created 4 months ago by josevalimComments
-
Consider also adding child_url and sibling_url.
Comments
I don't understand how the github votes works, i tryed to vote +1 but this get -1, damn!
I guess the child_url are a great option to add to inherited resources. Like that:
class MyController < InheritedResources::Base belongs_to :model endchild_url(:model)Can you do this? :)
Sorry, my suggestion in really are:
children_url(:model)Or really is child_url? I don't know, but you understand the feature that I requested :)
-
I've got a controller like this:
class BrandsController < InheritedResources::Base before_filter :authenticate, :ensure_brand_manager actions :new, :create belongs_to :sponsor protected def ensure_brand_manager sponsor = Sponsor.find(params[:sponsor_id]) unless sponsor.brand_managers.include?(current_user) flash[:failure] = "Permission denied" redirect_to root_path end end endThe line I'd like to push off to Inherited Resources is:
sponsor = Sponsor.find(params[:sponsor_id])On this controller, I'd like there to be protected methods available to me that do:
sponsor = Sponsor.find(params[:sponsor_id]) brand = Brand.find(params[:id])and/or:
parent = Sponsor.find(params[:sponsor_id]) resource = Brand.find(params[:id])Making these available in all Inherited Resources controllers would save me a line in about all of my controllers while maintaining readability.
What do you think?
Comments
Dan,
Currently you can call "resource", that will set both the @sponsor and @brand instance variables.
But currently, there is no way to ask inherited resources to load one specific parent. With resource, your example could be rewritten as:
unless resource.sponsor.brand_managers.include?(@current_user)If that does not solve your issue and you have to keep the filter, I would recommend to cache @sponsor in the instance variable, so Inherited Resources would check for it and do not query the database again:
@sponsor = Sponsor.find(params[:sponsor_id]) unless @sponsor.brand_managers.include?(current_user) flash[:failure] = "Permission denied" redirect_to root_path endInherited Resources always check for the instance variable before querying the database.
Okay, that's a good call. Ran it by a couple of guys at work. They pointed out I should be using a finder to return 404.
class BrandsController < InheritedResources::Base before_filter :authenticate, :authorize_brand_manager_belongs_to_sponsor actions :new, :create belongs_to :sponsor protected def authorize_brand_manager_belongs_to_sponsor @sponsor = Sponsor.find(params[:sponsor_id]) @sponsor.brand_managers.find(current_user.id) end endThis is looking better. I'd like to be able to use the resource.sponsor style but that's not available in before_filters, right?
I'd like to kill the before_filter if possible.
This would be an awesome option, too:
def begin_of_association_chain current_user endLooks like it tries to do current_user.sponsors, though, instead of current_user.sponsor.
I think that would be ideal, though:
current_user.sponsor.find(params[:sponsor_id])Is this a potential improvement to IR? If so, any tips on where to patch?
The resource is a controller method, that said, it's available in before_filter.
Good use of begin_of_association_chain. But wasn't it supposed to do:
current_user.sponsors.find(params[:sponsor_id])If you are doing a find, you need sponsors and not sponsor.
The relationship is:
User belongs_to :sponsor
Sponsor has_many :brand_managers, :class_name => "User"
Sponsor has_many :brandsSo, in script console, I can do things like:
user.sponsor user.sponsor.brandsI guess begin_of_association_chain isn't the right fit here?
Also, I think the problem with "resource" I was having in the before_filter was because I'm working with new and create actions where there is no resource established. In that case, I'll always get:
ActiveRecord::RecordNotFound: Couldn't find Brand without an IDIf an user belongs to sponsor, I guess you don't need to send the sponsor_id. So you can you have routes like:
/sponsor/brandsAnd your controller:
class BrandsController < InheritedResources::Base protected def begin_of_association_chain current_user.sponsor end endWith that kind of url, you ensure that a user cannot access other users resources.
For new and create you can use build_resource, it's resource twin brother for new and create. :)
Jose,
Simplifying the routes into a flatter structure was exactly the right move. Great call!
I'm also now successfully using the begin_of_association_chain approach for access control on another controller that belongs_to :sponsor. Finding it to be very clean, very few lines of code, and easy to test. It also forced me into a nice delegation in the models, keeping my future Law of Demeter violations to a minimum!
Awesome! Yes, after those months using Inherited Resources, I realized it helps a lot in the code design, including with the use of nested controllers, as you guys from Thoughtbot wrote about some time ago.
I keep the logic in the model, which is easy to test, and define well the responsibilities and routes.
And talking about testing, I do not test controllers anymore (rspec controller tests which are done with mocking), except those controllers that does not follow Inherited Resources pattern.
Controller and different conditions are very well tests in Inherited Resources and all changes we do through Inherited Resources API (like changing the redirection url) are verified in integration specs.
Can I close this ticket? :)
Absolutely! I tried clicking "Comment and Close" after my last one. I wrote up a blog post about this as well, promoting IR a bit. Queued it up, should go live sometime in the next few days.
-
Ensure that dual blocks can not be given to destroy
3 comments Created 6 months ago by josevalimComments
May I ask why this should not be allowed? In my case, the destroy method is invoked via AJAX and in order to distinguish a failed destroy from a successful one, I am setting a different status code in the failure block causing a different callback to be executed on client side.
-
Create hook to allow everyone to create *_resource_url
1 comment Created 6 months ago by josevalim -
Comments






Setting "DO_NOT_SET_DEPRECATED_FLASH" fixes it. Its being set in set_flash_message! (base_helpers.rb). I don't understand the point of having this behavior in the base gem, and the deprecation warning in the log/readme doesn't make sense. Perhaps I'm missing the point somewhere?
Yeah, fixed.
Sweet. Thanks for the quick fix!