Details

    • Similar issues:
      XWIKI-6528Implement an Object Property Update mojo in the xmldoc-update plugin
      XWIKI-7568Implement mechanism to hide technical content
      XWIKI-5267New Right service implementation
      XWIKI-8208Add 'attachmentName' configuration parameter to the 'attach' mojo of the xwiki-platform-tool-xmldoc-update-plugin
      XWIKI-2800The contentUpdateDate is updated even if there has been nothing changed on the document
      XWIKI-9253BaseProperty#setOwnerDocument sets the content as dirty when updating a property
      XWIKI-10829Executing the import mojo after the package mojo in the same reactor causes the build to fail
      XWIKI-6350Implement Trackback
      XWIKI-5632False annotation update events are being launched every time the content of the page is being changed
      XWIKI-1473Implement a mailing plugin

      Description

      The use case is the following : when building a wiki that depends on another wiki, being able to affect the content of wikis page from the depending wiki.
      For example, appending an include at the end of the content of a wiki page, to enrich this page, and still be able to benefit from its evolutions (which would not be the case just overriding the wiki document).

      Proposed properties :

      • content (text)
      • append (boolean, if true, append the content to the existing content, if false, overrides the whole content)

        Activity

        Hide
        Vincent Massol added a comment -

        hmmm this sounds a bit too complex to me... (unless there's real need)

        AFAIK the use case is for the home page only, right?
        I think each product should have its own home page.

        Do you have a specific use case? If this is for Watch I think it should have its own home page.
        Another possibility is to modify the XE home and move the "common" part in another page included from the home.

        Show
        Vincent Massol added a comment - hmmm this sounds a bit too complex to me... (unless there's real need) AFAIK the use case is for the home page only, right? I think each product should have its own home page. Do you have a specific use case? If this is for Watch I think it should have its own home page. Another possibility is to modify the XE home and move the "common" part in another page included from the home.
        Hide
        Jerome Velociter added a comment -

        No, the use case here is not for the Main.WebHome, but rather for XWiki Workspaces user profiles. I want to append a XWS-specific part to those profiles, without rewriting the whole sheet.
        I believe we could need this for other purposes, too (I have in mind the upcoming Admin section, for example).

        I said "update content" in the mojo, because it's more generic, but my real need is to append an include.

        Show
        Jerome Velociter added a comment - No, the use case here is not for the Main.WebHome, but rather for XWiki Workspaces user profiles. I want to append a XWS-specific part to those profiles, without rewriting the whole sheet. I believe we could need this for other purposes, too (I have in mind the upcoming Admin section, for example). I said "update content" in the mojo, because it's more generic, but my real need is to append an include.
        Hide
        Vincent Massol added a comment -

        Re the new admin part it's going to be done differently (a generic admin page that can be contributed to by apps).

        I guess the same should be done for the profiles eventually with Interface Extensions (IX).

        Right now we have 2 options:
        1) do as you suggest
        2) modify XE to move to another page the common code and include it

        Show
        Vincent Massol added a comment - Re the new admin part it's going to be done differently (a generic admin page that can be contributed to by apps). I guess the same should be done for the profiles eventually with Interface Extensions (IX). Right now we have 2 options: 1) do as you suggest 2) modify XE to move to another page the common code and include it
        Hide
        Jerome Velociter added a comment -

        Closing as won't fix since we've never needed this. We usually perform this kind of build operation with a XSLT transformation.

        Show
        Jerome Velociter added a comment - Closing as won't fix since we've never needed this. We usually perform this kind of build operation with a XSLT transformation.

          People

          • Assignee:
            Jerome Velociter
            Reporter:
            Jerome Velociter
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

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