Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-12197

Refactor and sanitize the action class hierarchy to make it easier to develop web action for Confluence

    • We collect Confluence feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

      This task encompasses all the refactoring work done to the action class hierarchy.

            [CONFSERVER-12197] Refactor and sanitize the action class hierarchy to make it easier to develop web action for Confluence

            Related Doco:
            http://confluence.atlassian.com/display/DOC/XWork-WebWork+Plugins

            WebWork actions must implement com.opensymphony.xwork.Action. However, we recommend you make your action extend ConfluenceActionSupport, which provides a number of helper methods and components that are useful when writing an Action that works within Confluence.

            Other action base-classes can be found within Confluence, but we recommend you don't use them - the hierarchy of action classes in Confluence is over-complicated, and likely to be simplified in the future in a way that will break your plugins.

            Still holds true. Almost all the changes were made in the AbstractPageAction and below and (for now) ConfluenceActionSupport still needs to be used.

            m@ (Inactive) added a comment - Related Doco: http://confluence.atlassian.com/display/DOC/XWork-WebWork+Plugins WebWork actions must implement com.opensymphony.xwork.Action. However, we recommend you make your action extend ConfluenceActionSupport, which provides a number of helper methods and components that are useful when writing an Action that works within Confluence. Other action base-classes can be found within Confluence, but we recommend you don't use them - the hierarchy of action classes in Confluence is over-complicated, and likely to be simplified in the future in a way that will break your plugins. Still holds true. Almost all the changes were made in the AbstractPageAction and below and (for now) ConfluenceActionSupport still needs to be used.

            made title clearer, made issue visible publicly. We still need to move the docs to CAC to resolve this issue.

            Per Fragemann [Atlassian] added a comment - made title clearer, made issue visible publicly. We still need to move the docs to CAC to resolve this issue.

            Can we please update CAC docs about this?

            Per Fragemann [Atlassian] added a comment - Can we please update CAC docs about this?

            We got most of the way to removing the AbstractPageAction. We did this by introducing the replacement AbstractPageAwareAction which is intended to only implement enough to satisfy the PageAware interface. The remaining issues above detail what is left to achieve this.

            The migration policy involved changing any class to extend the AbstractPageAwareAction and fix any missing references. If appropriate, these were extracted into beans, or changed to private methods and moved to a more appropriate class.

            We used our velocity usage audit log periodically to check for usages within our velocity templates.

            We moved enough classes so we could deprecate AbstractPageChangeAction, AbstractFileAttachmentAction, and AbstractEditAttachedFileAction.

            m@ (Inactive) added a comment - We got most of the way to removing the AbstractPageAction . We did this by introducing the replacement AbstractPageAwareAction which is intended to only implement enough to satisfy the PageAware interface. The remaining issues above detail what is left to achieve this. The migration policy involved changing any class to extend the AbstractPageAwareAction and fix any missing references. If appropriate, these were extracted into beans, or changed to private methods and moved to a more appropriate class. We used our velocity usage audit log periodically to check for usages within our velocity templates. We moved enough classes so we could deprecate AbstractPageChangeAction , AbstractFileAttachmentAction , and AbstractEditAttachedFileAction .

            m@ (Inactive) added a comment - Remove Obsolete Actions: http://jira.atlassian.com/browse/CONF-12397 Remove AbstractPageAction: http://jira.atlassian.com/browse/CONF-12396 Fix BootstrapAware interface: http://jira.atlassian.com/browse/CONF-12398

            Could I get you to raise appropriate tasks for these please and resolve this one for 2.9? Also I'd still like a summary of what this task has accomplished for 2.9 in the description.

            Christopher Owen [Atlassian] added a comment - Could I get you to raise appropriate tasks for these please and resolve this one for 2.9? Also I'd still like a summary of what this task has accomplished for 2.9 in the description.

            To finish off the initial goal to remove the AbstractPageAction (replaced with a simpler AbstractPageAwareAction) we need to look at these last classes:

            • ExportWordPageAction (Its suspected that this action isn't being used)
            • RevertPageBackToVersionAction (Uses only a real small amount of code from APA)
            • ViewPageAction (only using dependencies from APA)
            • PageInfoAction (same)

            Other remaining work:

            • Fix up the com.atlassian.confluence.pages.actions.beans.BootstrapAware lifecycle

            After this we have removed one of the bigger areas of the CAS code smell.

            m@ (Inactive) added a comment - To finish off the initial goal to remove the AbstractPageAction (replaced with a simpler AbstractPageAwareAction) we need to look at these last classes: ExportWordPageAction (Its suspected that this action isn't being used) RevertPageBackToVersionAction (Uses only a real small amount of code from APA) ViewPageAction (only using dependencies from APA) PageInfoAction (same) Other remaining work: Fix up the com.atlassian.confluence.pages.actions.beans.BootstrapAware lifecycle After this we have removed one of the bigger areas of the CAS code smell.

            Hi Matt, Could you update the status of this task, maybe with some info on what has been accomplished and raising issues for any remaining worthwhile tasks?

            Christopher Owen [Atlassian] added a comment - Hi Matt, Could you update the status of this task, maybe with some info on what has been accomplished and raising issues for any remaining worthwhile tasks?

            MoveAttachementAction still smells bad

            m@ (Inactive) added a comment - MoveAttachementAction still smells bad

            m@ (Inactive) added a comment - First commit: https://svn.atlassian.com/privateeye/changelog/private/?cs=61442

              mjensen m@ (Inactive)
              mjensen m@ (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: