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

Toolbar Redesign #6554

Closed
martinpovolny opened this issue Feb 8, 2016 · 1 comment
Closed

Toolbar Redesign #6554

martinpovolny opened this issue Feb 8, 2016 · 1 comment

Comments

@martinpovolny
Copy link

martinpovolny commented Feb 8, 2016

So far we have

  • Moved the toolbar selection logic to a separate class ApplicationHelper::ToolbarChooser
  • Moved the toolbar presentation logic to a separate module ToolbarHelper
  • Split toolbar calculation into several methods see ApplicationHelper::ToolbarBuilder
  • Allow creation of button classes: app/helpers/application_helper/button/* (only a couple of buttons are converted, rest are normal hashes) -- ApplicationHelper::Button::Basic and ApplicationHelper::ToolbarButtons
  • Turn toolbar YAML definition into classes (subclasses of ApplicationHelper::Toolbar::Basic).
  • Remove ToolbarButtons case statement by moving button classes to the toolbar definition.
  • Toolbar definitions -- fix gettext invocations
  • Add gettext to simple cases in ApplicationHelper::Toolbar::Basic subclasses. Implement the more complex ones as subclasses of ApplicationHelper::Button::Basic.

Next

  • Finish toolbar i18n.
  • Convert all toolbar logic from toolbar_builder to separate button classes.
  • Deduplicate and unify toolbar definitions extracting common button or button groups to modules.
  • Move relevant parts of ApplicationHelper::ToolbarBuilder to ApplicationHelper::Toolbar::Basic
  • Reimplement History toolbar as a manually created subclass of ApplicationHelper::Toolbar::Basic instead of logic around pre-defined buttons history_1...10 that are being removed when the toolbar is build.
  • Implement ApplicationHelper::Toolbar::Empty or handle the case of empty toolbar in some simpler way.
  • Consider how toolbars need to interact with other stuff especially GTL lists as we move forward with replacing GTL with an Angular component. Think of client-side markup generation.

Once this is done, try to simplify it ;-)

@martinpovolny martinpovolny self-assigned this Feb 8, 2016
@martinpovolny martinpovolny modified the milestone: Sprint 44 Ending Aug 1, 2016 Jul 12, 2016
This was referenced Feb 24, 2017
@miq-bot
Copy link
Member

miq-bot commented Aug 19, 2017

This issue has been automatically marked as stale because it has not been updated for at least 6 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions!

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

No branches or pull requests

2 participants