Rewrite the client-side and server-side implementation of admin UI widgets.

Review Request #10756 — Created Oct. 16, 2019 and submitted

chipx86
Review Board
release-4.0.x
abeb714...
reviewboard

The old design for widgets wasn't very generally useful. The server-side
design of Widget was really only geared toward the use cases we
initially came up with, but wasn't optimal or future-proof. The
client-side was worse -- there was none. Widgets just dumped HTML with
<script> tags into the page, and just tried hard-coding DOM element
IDs as needed, using them to try to look up widgets and populate them.

This change completely redoes the design, while striving to maintain
some backwards-compatibility (until Review Board 5.0).

Server-side, widget support is now provided through a BaseAdminWidget
class, which provides:

  • Basic class attributes for customizing the widget's ID, name, CSS
    classes, and a template name
  • An optional custom template, which would subclass a base
    admin_widget.html (instead of being embedded within the base
    template) and provide content and header/footer actions
  • A method for subclasses to provide context data for the template
  • Methods for specifying attributes and options for the JavaScript model
    class, and options for the view class
  • A method for rendering the template to a string

It doesn't manage caches anymore, as that's not always necessary or even
worth doing. It also doesn't have a concept of primary/secondary
widgets or hard-coded list of action URLs. The legacy Widget class
still provides all this, but is deprecated and will be removed in 5.0.

Widgets are now managed by a registry, rather than being stored in
separate primary/secondary lists of classes.

Client-side, RB.Admin.WidgetView handles all widget rendering and
interactions, with state stored in RB.Admin.Widget. The default
implementations do effectively nothing, but can be subclassed for custom
widget behavior.

Legacy widgets still work, and will continue to in 4.0, but we emit
warnings in Widget.__init__(), AdminWidgetHook, and the legacy
register_admin_widget() and unregister_admin_widget() functions to
encourage anyone actually writing custom widgets to upgrade.

Upcoming changes will port all existing widgets to the new classes.

Tested with a mixture of legacy widgets and some partially-ported
widgets (server-side and client-side). Everything registered and
rendered correctly.

Unit tests pass.

Description From Last Updated

Can you specify array of what?

daviddavid

Can we use {% spaceless %} to wrap this more nicely?

daviddavid
david
  1. 
      
  2. Can you specify array of what?

    1. Sure. It's going to be stupidly vague though: Array of object

  3. Can we use {% spaceless %} to wrap this more nicely?

    1. It doesn't really add any value. I gave it a shot, but each line is still too long, since each tag itself is inherently long. {% spaceless %} only removes spaces between tags, not within tags or within attribute values. I'd rather just opt in this case to leave this line exactly how the old template had it. We're never going to touch this file again, and as soon as we fork for 5.0 it's going to be deleted.

  4. 
      
chipx86
david
  1. Ship It!
  2. 
      
chipx86
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to release-4.0.x (2a81414)
Loading...