Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow procs for menu parent #2397

Closed

Conversation

simonc
Copy link

@simonc simonc commented Aug 7, 2013

Hi,

I got an error trying to pass a proc for menu :parent option. The error happens in Menu::MenuNode#normalize_id because Proc is not supported.

Is there a particular reason to disallow proc usage for parent ?

Thanks

nebirhos and others added 15 commits August 1, 2013 13:31
Conflicts:
	activeadmin.gemspec

undoes 1d29474, to apply the full fix
#### Removed outdated version-checking conditions
Modules affected:
+ CSV parser
+ asset registration
+ class reloading in development

#### Removed 99% of our custom class reloader in favor of Rails reloading
Note: I removed the code that purges `app/admin` from Rails' `eager_load_paths`
since there were no bad effects of doing so. Only the code that does this for
Rails' `autoload_paths` seems necessary.

#### Gemspec dependencies updated
+ fastercsv removed
+ coffee-rails added
+ sass replaced by sass-rails
Adds conditionals to the admin user generator, and to the AA Comments
model & controller to handle both Protected Attributes and Strong Paramaters

Also updates dependencies so the test Rails 4 app will at least bundle
Note that while Ransack renames many query methods ("predicates"), this
commit creates aliases for the more plain-english predicates so they
still work as expected.

To see the full list of Ransack predicates, check out
`lib/ransack/constants.rb` in the Ransack source code.

This commit also removes polymorphic foreign keys from the default
list of filters for a resource, since Ransack seems to barf on them. We
don't have a good filter UI for them anyway, so it's not a huge issue.
+ asset generator now creates a CoffeeScript file
This substition was being made twice by the `install` generator,
resulting in two config parameters. Now we only add the config
if there is none already.
For some reason, Formtastic checks if a constant is defined first, which doesn't play nicely with autoloading of custom inputs. This brings Formtastic's implementation back to pre formtastic/formtastic#783
@simonc
Copy link
Author

simonc commented Aug 7, 2013

Here is tiny patch that seems to be working. What do you think ?

@seanlinsley
Copy link
Contributor

It's disallowed because it's difficult to coordinate between multiple children what the parent is. For example, would you want to copy & paste the proc between multiple AA registrations? Or have a global proc that can be accessed? What if the proc returns something different sometimes, so some children aren't property namespaced under the parent?

A better option is to define your complex menu structure in the initializer (or some other file) like described in the docs. That way this is possible:

ActiveAdmin.setup do |config|
  config.namespace :admin do |admin|
    admin.build_menu do |menu|
      menu.add label: ->{"Foo"} do |foo|
        foo.add label: "Bar", url: "http://github.com"
      end
    end
  end
end

@simonc
Copy link
Author

simonc commented Aug 7, 2013

Ok, if I understand correctly, if I have several resources to put under a parent menu it would like this ?

# app/admin/students.rb
ActiveAdmin.register Student do
  menu false
end

# app/admin/teachers.rb
ActiveAdmin.register Teacher do
  menu false
end

# config/initializers/active_admin.rb
ActiveAdmin.setup do |config|
  config.namespace :admin do |admin|
    admin.build_menu do |menu|
      menu.add label: ->{ I18n.t(:users) } do |m|
        m.add label: ->{ Student.model_name.human }, url: [:admin, :students]
        m.add label: ->{ Teacher.model_name.human }, url: [:admin, :teachers]
      end
    end
  end
end

@seanlinsley
Copy link
Contributor

Yes, that's how it should work. Though to be honest, I haven't tried it myself.

@simonc
Copy link
Author

simonc commented Aug 8, 2013

I can tell you it works ;)

@simonc
Copy link
Author

simonc commented Aug 8, 2013

My bad, it doesn't. My patch was still active.
The following line is failing with the same error (Proc isn't supported as a Menu ID):

menu.add label: ->{ I18n.t(:users) } do |m|

And even when fixing this line the next one gets the error

m.add label: ->{ Student.model_name.human }, url: [:admin, :students]

Here it shouldn't be expected I think :/

@seanlinsley
Copy link
Contributor

Oh okay, so I just dug up a conversation I had with @gregbell about this issue. I suggest you read it. For context, that discussion occured on my PR that would have let you pass a hash of options to your parent menu item, but was closed in favor of the syntax that lets you do the same in the initializer. The example @gregbell gave:

# config/initializers/active_admin.rb
# ...
config.namespace :admin do |admin|
  admin.build_menu do |menu|
    menu.add id: "foo", label: proc{ "Bar" }
  end
end
ActiveAdmin.register MyModel do
  menu parent: "foo" # will connect to the `foo` menu item
end

@simonc
Copy link
Author

simonc commented Aug 12, 2013

Ok I see. You create a menu entry, specifying the label so that menu items can connect to it later.
Indeed it seems cleaner and since the id is specified it should create the menu item without any id conversion issue :)

@simonc
Copy link
Author

simonc commented Aug 12, 2013

I just tested it and it seems to work fine. Is it documented any where outside the conversation ? Otherwise I'll add something to the wiki :)

@simonc simonc closed this Aug 12, 2013
@simonc simonc deleted the 2397-allow-proc-for-menu-parent branch August 12, 2013 08:55
@seanlinsley
Copy link
Contributor

Yeah, this file should really mention the :id option and how it's useful for parents with a proc label: https://github.com/gregbell/active_admin/blob/master/docs/2-resource-customization.md

seanlinsley added a commit that referenced this pull request Oct 26, 2013
@seanlinsley
Copy link
Contributor

BTW @simonc, I just came across this again and finally updated the docs: be7ba09

@simonc
Copy link
Author

simonc commented Oct 26, 2013

@seanlinsley awesome :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants