Add new dedicated classes for handling action rendering.

 






 

 


  Review Request #14659
  —
  Created Oct. 29, 2025 and updated 

 




















 

  

   Information

  





 
 

  chipx86
 









 
 

  Review Board
 









 
 

  release-7.1.x
 









 
 

  
 









 
 

  
 






 




 

  

   Reviewers

  





 
 

  reviewboard
 









 
 

  
 






 








 





  


 
 

  
When actions were first built, we had a one-to-one mapping of action

class to UI representation. This changed with the introduction of the

Quick Access actions, which required duplicating and specializing

actions.


We only had basic forms of menu and menu item actions at that time, but

as we adopt actions for more parts of the UI (including page navigation

soon) that can show up in multiple places, we've needed a more flexible

approach.


Now, actions provide the metadata and, client-side, activation logic

(implemented in a former change), and rendering is handled by a separate

set of renderer classes. These are responsible for taking a registered

action and turning it into a UI representation server-side. These may be

buttons, menus, menu items, sidebar items, or something specialized for

any part of the UI.


Renderers don't need to be registered anywhere. They can be created and

then set as either the default for an action, or passed explicitly

during action rendering, which will yield new HTML/JavaScript for that

action's view.


Compatibility with existing action-driven rendering is still provided,

but deprecated and will be removed in Review Board 9. As of this change,

such actions are still using the legacy behavior, in part to aid in

testing this compatibility. These will be updated in another change.


This is a precursor to change that will provide defaults for different

areas on a page, which will make it even easier to reuse actions across

a page.

 








  


 
 

  
Unit tests passed.


Tested all actions used in the UI, making sure they rendered and

activated correctly.

 







 









 





  

 


 
 

  



 

  
   


    Summary
    ID

   

  
  

   


    

     

      Add new dedicated classes for handling action rendering.
      
When actions were first built, we had a one-to-one mapping of action
class to UI representation. This changed with the introduction of the
Quick Access actions, which required duplicating and specializing
actions.

We only had basic forms of menu and menu item actions at that time, but
as we adopt actions for more parts of the UI (including page navigation
soon) that can show up in multiple places, we've needed a more flexible
approach.

Now, actions provide the metadata and, client-side, activation logic
(implemented in a former change), and rendering is handled by a separate
set of renderer classes. These are responsible for taking a registered
action and turning it into a UI representation server-side. These may be
buttons, menus, menu items, sidebar items, or something specialized for
any part of the UI.

Renderers don't need to be registered anywhere. They can be created and
then set as either the default for an action, or passed explicitly
during action rendering, which will yield new HTML/JavaScript for that
action's view.

Compatibility with existing action-driven rendering is still provided,
but deprecated and will be removed in Review Board 9. As of this change,
such actions are still using the legacy behavior, in part to aid in
testing this compatibility. These will be updated in another change.

This is a precursor to change that will provide defaults for different
areas on a page, which will make it even easier to reuse actions across
a page.

     


    		
    be7b9ebac56f069961667eaa280152339068b25a

   



  
 




 













 

  
  


   

    

     

     

     

    

   


   

  

 










 






  

 



















 




 




 














 



 

  

   




chipx86




   

   

  

 



 















 



 

  

   




chipx86




   

   

  

 



 

  


   

   

    
 Review request changed

    
   


  

  

  









  

   

    Change Summary:
   

   

    
    

  • Fixed the compatibility shims for old-style actions.
    • 

  • Pre-populated the registry for the action hooks tests so that the temporary renderer warnings won't affect warning assertions.
    • 


   

  








  

   

    Commits:
   

   

    





 

  
   


    

    Summary
    ID

   

  
  

   


    

    

     

      Add new dedicated classes for handling action rendering.
      
When actions were first built, we had a one-to-one mapping of action
class to UI representation. This changed with the introduction of the
Quick Access actions, which required duplicating and specializing
actions.

We only had basic forms of menu and menu item actions at that time, but
as we adopt actions for more parts of the UI (including page navigation
soon) that can show up in multiple places, we've needed a more flexible
approach.

Now, actions provide the metadata and, client-side, activation logic
(implemented in a former change), and rendering is handled by a separate
set of renderer classes. These are responsible for taking a registered
action and turning it into a UI representation server-side. These may be
buttons, menus, menu items, sidebar items, or something specialized for
any part of the UI.

Renderers don't need to be registered anywhere. They can be created and
then set as either the default for an action, or passed explicitly
during action rendering, which will yield new HTML/JavaScript for that
action's view.

Compatibility with existing action-driven rendering is still provided,
but deprecated and will be removed in Review Board 9. As of this change,
such actions are still using the legacy behavior, in part to aid in
testing this compatibility. These will be updated in another change.

This is a precursor to change that will provide defaults for different
areas on a page, which will make it even easier to reuse actions across
a page.

     


    		
    a51d8886715bb04a681c3290fd8387eb3f398dde

   




   


    

    

     

      Add new dedicated classes for handling action rendering.
      
When actions were first built, we had a one-to-one mapping of action
class to UI representation. This changed with the introduction of the
Quick Access actions, which required duplicating and specializing
actions.

We only had basic forms of menu and menu item actions at that time, but
as we adopt actions for more parts of the UI (including page navigation
soon) that can show up in multiple places, we've needed a more flexible
approach.

Now, actions provide the metadata and, client-side, activation logic
(implemented in a former change), and rendering is handled by a separate
set of renderer classes. These are responsible for taking a registered
action and turning it into a UI representation server-side. These may be
buttons, menus, menu items, sidebar items, or something specialized for
any part of the UI.

Renderers don't need to be registered anywhere. They can be created and
then set as either the default for an action, or passed explicitly
during action rendering, which will yield new HTML/JavaScript for that
action's view.

Compatibility with existing action-driven rendering is still provided,
but deprecated and will be removed in Review Board 9. As of this change,
such actions are still using the legacy behavior, in part to aid in
testing this compatibility. These will be updated in another change.

This is a precursor to change that will provide defaults for different
areas on a page, which will make it even easier to reuse actions across
a page.

     


    		
    be7b9ebac56f069961667eaa280152339068b25a

   



  
 







   

  





  

   

    Diff:
   

   

    
 Revision 3 (+4026 -156)
Show changes
 
    docs/manual/extending/coderef/index.rst 
    reviewboard/actions/base.py 
    reviewboard/actions/renderers.py 
    reviewboard/actions/templatetags/actions.py 
    reviewboard/actions/tests/base.py 
    reviewboard/actions/tests/test_base_action.py 
    reviewboard/actions/tests/test_base_action_renderer.py 
    reviewboard/actions/tests/test_button_action_renderer.py 
  12 more
 

   

  











 

  
Checks run (2 succeeded)



  

 flake8
 passed.
 





  

 JSHint
 passed.