XWiki Platform
  1. XWiki Platform
  2. XWIKI-8875

Add convenience hasSubWikis() method to api.XWiki

    Details

    • Type: Improvement Improvement
    • Status: Closed Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.5.1
    • Fix Version/s: 5.0-milestone-2
    • Component/s: Old Core
    • Labels:
      None
    • Difficulty:
      Unknown
    • Documentation:
      N/A
    • Similar issues:
      XWIKI-2055Move utility APIs from the api.XWiki class to a new api.Util class
      XWIKI-8841Add getWikiNames() method to api.XWiki that exposes the previously private XWiki.getVirtualWikisDatabaseNames()
      XWIKI-4924Add getId method to MacroDescriptor interface
      XWIKI-4939Add getDocumentReference method to WikiMacro interface
      XWIKI-2905XWiki#parseGroovyFromPage(page, jarPage) is not loading jars from jarPage
      XWIKI-6909Add hasWikiAdminRights method to XWikiRightsService
      XWIKI-2428Add renamePage method to XMLRPC API
      XWIKI-2175Add reverseList(List) method to the Util API
      XWIKI-2550Add standard method to load external configuration files
      XWIKI-808Add protected Api.getXWikiContext() method

      Description

      To find out if the XWiki instance contains other (sub)wikis than just the main wiki (assuming XWIKI-8841 is implemented), you would have to test if:

      $xwiki.wikiNames().size() > 1
      

      For convenience, we could just have:

      $xwiki.hasVirtualWikis()
      

        Activity

        Hide
        Eduard Moraru added a comment -

        For the name, I would suggest changing it to hasSubWikis(), since that's basically what it is doing. This way we remove the "virtual" concept.

        Vincent Massol: are you suggesting that we should add a getWikiReferences() in addition to XWIKI-8841?

        Marius Dumitru Florea: You know that I agree with Thomas Mortagne about stopping attempts to "emulate" the single wiki mode. Just going to reiterate that, IMO, it is a bad idea to try to hide the farm actions on the main wiki if there is only one wiki. "Install on farm" does make sense even for a single wiki (since it also applies on future wikis), so it should be displayed.

        Show
        Eduard Moraru added a comment - For the name, I would suggest changing it to hasSubWikis(), since that's basically what it is doing. This way we remove the "virtual" concept. Vincent Massol : are you suggesting that we should add a getWikiReferences() in addition to XWIKI-8841 ? Marius Dumitru Florea : You know that I agree with Thomas Mortagne about stopping attempts to "emulate" the single wiki mode. Just going to reiterate that, IMO, it is a bad idea to try to hide the farm actions on the main wiki if there is only one wiki. "Install on farm" does make sense even for a single wiki (since it also applies on future wikis), so it should be displayed.
        Hide
        Vincent Massol added a comment -

        yes hasSubWikis() is much better, even though its implementation should probably be a one-liner: return getWikiReferences().size() > 1

        <brainstorming mode>
        It's ok, since it's in api.XWiki it's going to disappear in not long I hope. I think this API may need to move in a rewritten xwiki-platform-wiki-manager module that will be a convenience layer above the new model to perform multiwiki operations.

        Actually maybe we won't want to draw this dependency in single wiki mode and have the ability to get this information directly from the Model. Maybe modelContext.getServer().getWikis().size() but since this is an Iterable it would mean sending a query to the DB which isn't that nice. An alternative is to have some other module using the query manager to do some DB queries and cache the results to get the list of wikis. However including multiwikis in the query manager is probably too hard and thus another query module for wikis is probably going to be needed. Something like query-manager-wiki.
        </brainstorming mode>

        Show
        Vincent Massol added a comment - yes hasSubWikis() is much better, even though its implementation should probably be a one-liner: return getWikiReferences().size() > 1 <brainstorming mode> It's ok, since it's in api.XWiki it's going to disappear in not long I hope. I think this API may need to move in a rewritten xwiki-platform-wiki-manager module that will be a convenience layer above the new model to perform multiwiki operations. Actually maybe we won't want to draw this dependency in single wiki mode and have the ability to get this information directly from the Model. Maybe modelContext.getServer().getWikis().size() but since this is an Iterable it would mean sending a query to the DB which isn't that nice. An alternative is to have some other module using the query manager to do some DB queries and cache the results to get the list of wikis. However including multiwikis in the query manager is probably too hard and thus another query module for wikis is probably going to be needed. Something like query-manager-wiki. </brainstorming mode>
        Hide
        Eduard Moraru added a comment -

        <brainstorming mode>
        I`m almost against the wiki-manager module approach because we would be doing the same mistake we are doing now with the current model. The multiwiki model should be part of the model by default and not through some kind of extensions. As we have spaces in wiki, pages in spaces, etc... and AFAIK, we will have spaces in spaces... so we should also have wikis within a wiki. There should be no external API to test for and to use when wanting to create/change/query/etc wikis. It should be a feature of the default model itself.

        Anyway, we could move this discussion on the mailing list.
        </brainstorming mode>

        Show
        Eduard Moraru added a comment - <brainstorming mode> I`m almost against the wiki-manager module approach because we would be doing the same mistake we are doing now with the current model. The multiwiki model should be part of the model by default and not through some kind of extensions. As we have spaces in wiki, pages in spaces, etc... and AFAIK, we will have spaces in spaces... so we should also have wikis within a wiki. There should be no external API to test for and to use when wanting to create/change/query/etc wikis. It should be a feature of the default model itself. Anyway, we could move this discussion on the mailing list. </brainstorming mode>
        Hide
        Thomas Mortagne added a comment -

        Yes big -1 for some new wiki manager module, what is supposed to deprecated the current wiki manager plugin is the new model which is supposed to deal with wikis.

        Show
        Thomas Mortagne added a comment - Yes big -1 for some new wiki manager module, what is supposed to deprecated the current wiki manager plugin is the new model which is supposed to deal with wikis.
        Hide
        Vincent Massol added a comment -

        Guys, you really need to look at the model in the feature-newmodel branch and provide comments ASAP. ATM what you say is definitely not possible.

        Show
        Vincent Massol added a comment - Guys, you really need to look at the model in the feature-newmodel branch and provide comments ASAP. ATM what you say is definitely not possible.

          People

          • Assignee:
            Eduard Moraru
            Reporter:
            Eduard Moraru
          • Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:
              Date of First Response: