Uploaded image for project: 'Release Notes Application'
  1. Release Notes Application
  2. RN-90

The application cannot be copied to another top-level space, although its pages resolve that space at runtime

    XMLWordPrintable

Details

    • Bug
    • Resolution: Fixed
    • Major
    • 2.6
    • 2.0
    • Application
    • None
    • Integration
    • Unknown
    • N/A

    Description

      Problem

      Every page of the application works out at runtime which top-level space it is running in:

      #set ($topSpace = $doc.documentReference.extractFirstReference('SPACE').getName())
      

      and builds its page references, XWQL statements, HTML attributes, Live Data sourceParameters, links and JSX/SSX identifiers out of the answer – 57 places across 18 pages.

      The point of that is to let the application be copied or renamed to another top-level space. It does not achieve it. Three of the things a copy needs are plain xobject values that no interpolation can reach:

      • the XWiki.ClassSheetBinding objects on Code.ContributorsClass and Code.Change.ChangeClass, naming ReleaseNotes.Code.ContributorsSheet and ReleaseNotes.Code.Change.ChangeSheet;
      • Code.ReleaseNotesConfig, whose template and configurationClass name ReleaseNotes.Code.ReleaseNoteTemplate and ReleaseNotes.Code.ReleaseNotesConfigClass;
      • the XWiki.UIExtensionClass object on Code.ApplicationsPanelEntry, whose target is ReleaseNotes.WebHome.

      A copy therefore goes on using the original's sheets, configuration and applications panel entry, and stops working altogether once the original is uninstalled.

      Twelve include targets and seven Live Data suggest URLs additionally write the literal ReleaseNotes. prefix, so they never followed a copy either.

      Consequence

      The application supports exactly one install location, ReleaseNotes, which is where its XAR puts it. What $topSpace actually computes is not that location but the name of whichever page is being rendered – for Code.Change.ChangeSheet any page carrying a ChangeClass xobject, for the releasenotechanges and releasenotecontributors macros any page that calls them. Those coincide in a normal installation and diverge otherwise, so the variable adds a way for the rendered output to vary that nothing needs.

      Proposal

      Name ReleaseNotes in the references and drop $topSpace altogether. Supporting a second install location would first need the three xobject values above to become relative; until that is possible the mechanism is better absent than half-present.

      Attachments

        Activity

          People

            vmassol Vincent Massol
            vmassol Vincent Massol
            Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: