XWiki Platform

Implement a "Update content" mojo

Details

  • Similar issues:
    XWIKI-6528Implement an Object Property Update mojo in the xmldoc-update plugin
    XWIKI-7568Implement mechanism to hide technical content
    XWIKI-8208Add 'attachmentName' configuration parameter to the 'attach' mojo of the xwiki-platform-tool-xmldoc-update-plugin
    XWIKI-5267New Right service implementation
    XWIKI-2800The contentUpdateDate is updated even if there has been nothing changed on the document
    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
    XWIKI-208Implement a new tag that disables syntax processing on its contents
    XWIKI-7589Annotation count is not updated in docextra tab header and shortcuts

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

Ascending order - Click to sort in descending order
Hide
Permalink
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
Permalink
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
Permalink
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
Permalink
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
Vote (0)
Watch (1)

Dates

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