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

Create a set of useful global macro parameters which macro developers can use without re-inventing

    XMLWordPrintable

Details

    • 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.

    Description

      NOTE: This suggestion is for Confluence Server. Using Confluence Cloud? See the corresponding suggestion.

      Almost all macros would benefit, for example from a parameter called 'context' or 'root' which lets you indicate which page you want the macro to execute from.

      {include:root=pagename}

      (default parameter)

      {toc:root=pagename}

      (not a current parameters, but would be nice)

      {metadata-report:root=pagename}

      (current parameter)

      Currently, all macros would have to re-implement this feature, and many do, and often give a different name. If confluence provided a $rootcontext variable to the macros, which was loaded from a standard 'root' or 'context' parameter, it would enforce standardization.

      Other candidates for standardized 'global' parameters can be found on a page in the confluence extensions section, written by either Guy Fraser or David Peterson, but I couldn't find it right now. I'll list a few here:

      pages - takes a well-written query language that allows macros to simply recieve a list of pages on which to perform their action (such as a $pages collection), but without each macro having to re-invent or re-implement a (different) query language. It could take:

      • list of specific pages, or space:pages, with a standard delimiter ( ; ? )
      • wildcards or regular expressions to indicate a group of pages by name
      • perhaps keywords or symbols like @children, @parent of the current page
      • space key designations
      • as the 'parser' changes or becomes more sophisticated, existing macros woudl all benefit from these changes because they simply use the $pages collection.

      labels - same as above: sets $pages to a set of pages that satify a 'label query', with () for nesting and some operators for and/or/not ( + , ! )

      scope - descendents, ancestors, space, site, children, parent, self - specifies dynamic scope relative to the 'pages' option, or might be incorporated in the pages query language

      query - uses the built in query language, i.e "title:My Page* AND author:james") to retrieve a set of pages for the macro's operation

      style - specify a direct CSS style for this tag. These could then, in theory, be filterd by a per site configuration for all macros
      css - specify a css class. likewise, could then be manipulated / translate site-wide for all macros

      output - wiki / table / html / text (specified how output sould be rendered in page context after macro returns results)
      input - wiki / table / html / text (specified how input should be rendered before passed to $body for macro plugin)

      There are no doubt others that could be used. This request is for Atlassian to put in place the framework to support these 'global macro parameters'.

      Thanks.

      Attachments

        Issue Links

          Activity

            People

              Unassigned Unassigned
              f1dc925b931b JamesM
              Votes:
              6 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved: