-
Notifications
You must be signed in to change notification settings - Fork 8
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
Refactor ButtonHelper component of modeladmin to offer drop-down/sub-menu structuring of actions #7
Comments
After having time to think this through, I have a proposal for what I'd like to achieve here: Currently, adding a new button for items in the IndexView (or elsewhere) requires the ButtonHelper class to be sub-classed, and methods adding / overriding in that class. One method needs to define the button (it's text, where it links to etc), and another method does some permission analysis as it bulks buttons together. I would like to make this process easier by...
The appropriate iterable can then be passed to the ButtonHelper's
Which would reproduce the menu shown in Explorer. What I have yet to decide on, is how best to bring permissions into the equation... so that the right buttons only show for the right users. I suppose the simplest solution there would be for each 'button description' method to include a @gasman Interested to hear your thoughts on this :) |
There's another piece of work being discussed in #10 which looks like it will benefit from a few of the features discussed above, but the support for multi-level/dropdown definitions probably isn't as important as the rest of the stuff. For now, I think we just need to focus on the following, and work on bringing in the dropdowns later:
|
I think I've figured out how to implement these changes in a backwards compatible way: We leave the existing ButtonHelper classes largely as they are, but make them raise a deprecation warning on init(). That way, anyone subclassing them will be fine for now. We create a new GenericButtonHelper class that has the new behaviour on it, and update the ModelAdmin class to use that by default. But, anyone using the Then it's just a case of making sure the views support both the old and new style classes when they call on them to do button-related things. |
Quick update: I've made a huge amount of progress with this (including getting the dropdown buttons to render), but it ended up requiring changes in a few more places than I was expecting, and so I'm thinking it'll now be best to split the changes up over a few different PRs to make things easier to review (with unit tests added along the way as required)
In case I die or something, here's where things are at: |
The new more/dropdown UI element used in the Explorer to hide less common actions is really smart, and would certainly be a pattern worth reusing. A logical first step would be look at what's there, and what can be abstracted out for re-use, then to refactor the ButtonHelper component to make use of it.
At the same time, it would probably make sense to refine the way buttons in ButtonHelper are defined (it could be more DRY than it is) and rendered in the various modeladmin templates.
The text was updated successfully, but these errors were encountered: