Model display name fixes #319

Closed
wants to merge 6 commits into
from

Conversation

Projects
None yet
4 participants
@wolframarnold
Contributor

wolframarnold commented Mar 15, 2011

When the model name has been modified with:

RailsAdmin.config do |config|
  config.model Team do
    label_for_navigation "List of teams"
  end
end

that name isn't used when it should be used for the dashboard table, the breadcrumbs, page name, history entries and delete messages.

This fixes issue: https://github.com/sferik/rails_admin/issues/#issue/318

papercheck and others added some commits Mar 10, 2011

Fix for asset loading issue:
When assets have been copied with rake admin:copy_assets, then rails_admin should NOT insert
another ActionDispatch::Static middleware, because it eclipses Rails's native middleware and assets
are loaded from rails_admin's public folder instead of the application's public folder.
Fixed by checking if any of the rails_admin subdirectories exist in any of the static asset classes
(images, javascripts, stylesheets).
Also, if the middleware is inserted, it should be done AFTER, not IN FRONT of Rails's own static asset
middleware, to permit precedence to the application's public folder over the gem's.
Merge in sferik/master which had the same fix for static asset loadin…
…g, but didn't check for the files to be present,

which is cool.
Fix display bug on dashboard page:
Model name in table is now using label override if present.
Fix display bug on list page:
@page_name should use overridden model name.
Same for breadcrumbs.
Spec coverage added.
Fixed several other references to model name for delete and history,
where @model_config.list.label was called, but @model_config.navigation.label should
have been called.
@kaapa

This comment has been minimized.

Show comment
Hide comment
@kaapa

kaapa Mar 15, 2011

Collaborator

Hi Wolfram and thank you for the fix!

Your approach is on the right track, but I think it should be taken bit further. The old code allowed to define label per section (navigation, update, create, list), but that was indeed an overkill and wasn't even implemented in the dashboard. I think simplifying the label definition to a single point of entry is definitely a good idea, but it should not be contained in the navigation section, but on a higher level.

Therefore I'd propose we'd move RailsAdmin::Config::Labelable module's methods to RailsAdmin::Config::Model, remove inclusion of Labelable in RailsAdmin::Config::Sections::* and reflect that in docs & code. That way there'd be less confusion how a model's label is accessed.

In configuration one would use:

RailsAdmin.config do |config|
  config.model Team do
    label "List of teams"
  end
end

And in code:

@model_config.label

Do you find this proposal acceptable and change the pull request accordingly?

PS. I'm also thinking we should do same kind of move with RailsAdmin::Config::Hideable as authorization hooks serve the use cases I had in mind when it was designed, but that's a different topic .

Collaborator

kaapa commented Mar 15, 2011

Hi Wolfram and thank you for the fix!

Your approach is on the right track, but I think it should be taken bit further. The old code allowed to define label per section (navigation, update, create, list), but that was indeed an overkill and wasn't even implemented in the dashboard. I think simplifying the label definition to a single point of entry is definitely a good idea, but it should not be contained in the navigation section, but on a higher level.

Therefore I'd propose we'd move RailsAdmin::Config::Labelable module's methods to RailsAdmin::Config::Model, remove inclusion of Labelable in RailsAdmin::Config::Sections::* and reflect that in docs & code. That way there'd be less confusion how a model's label is accessed.

In configuration one would use:

RailsAdmin.config do |config|
  config.model Team do
    label "List of teams"
  end
end

And in code:

@model_config.label

Do you find this proposal acceptable and change the pull request accordingly?

PS. I'm also thinking we should do same kind of move with RailsAdmin::Config::Hideable as authorization hooks serve the use cases I had in mind when it was designed, but that's a different topic .

@wolframarnold

This comment has been minimized.

Show comment
Hide comment
@wolframarnold

wolframarnold Mar 15, 2011

Contributor

Hi Petteri,

Thanks for your reply. To be honest, I hadn't dove deep enough into the architecture to fully understand the bigger picture. Conceptually what you're proposing makes sense, but I'll have to get my head wrapped around the configuration layer in more detail than I had previously. I'll give it a try.

Best,
Wolf

Contributor

wolframarnold commented Mar 15, 2011

Hi Petteri,

Thanks for your reply. To be honest, I hadn't dove deep enough into the architecture to fully understand the bigger picture. Conceptually what you're proposing makes sense, but I'll have to get my head wrapped around the configuration layer in more detail than I had previously. I'll give it a try.

Best,
Wolf

@sferik

This comment has been minimized.

Show comment
Hide comment
@sferik

sferik Mar 19, 2011

Owner

Can this pull request be close since I've merged #322?

Owner

sferik commented Mar 19, 2011

Can this pull request be close since I've merged #322?

@wolframarnold

This comment has been minimized.

Show comment
Hide comment
@wolframarnold

wolframarnold Mar 19, 2011

Contributor

Yes this can be closed. It was submitted from my co-worker's account at Papercheck. I'll do it. Sorry I forgot. I appreciate your diligence.

Best,
Wolf

Contributor

wolframarnold commented Mar 19, 2011

Yes this can be closed. It was submitted from my co-worker's account at Papercheck. I'll do it. Sorry I forgot. I appreciate your diligence.

Best,
Wolf

jbrown pushed a commit that referenced this pull request Apr 18, 2011

Update the configuration of model label as per discussion here: #319
The model label is now configurable at the model level only, and is no longer configurable
at the section level (list, navigate, update,...), as this was considered overkill.
This refactoring was in part motivated by issue #319 which reported that display of labels was very inconsistent across
various screens, and the label configuration, if given, was not consistently effective.
The Labelable module was removed, and the methods model into config/model.rb
All references to label across the code have been updated to use the model configuration.
Specs updated and passing. Readme also updated accordingly.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment