• 
      

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

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

    Information

    Review Board
    release-4.0.x
    abeb714...

    Reviewers

    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. Show all issues

      Can you specify array of what?

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

    3. Show all issues

      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:
    Completed
    Change Summary:
    Pushed to release-4.0.x (2a81414)