Description

• Objective
• Principle
• Use cases
• Implementation and problems
  • UC1: Move children pages under the parent page
  • UC10: Transform terminal pages to nested pages
  • UC4, UC5, UC6: Implement the migration as a job (probably in Java)
  • UC3: Checkboxes
  • UC7: A redirect object should be saved in the old location of the document.
  • UC8: Add a way to simply change the "hierarchy mode" per wiki
  • UC2: Copy all inherited preferences to the Target.WebPreferences pages
  • UC11: Don't apply transformations on technical pages.
• Mock ups
• Proposition B

Objective

Upgrade an existing wiki, older than 7.2, to a version handling Nested Pages, and try to get the best of it.

Principle

The idea is to move some pages under some others to benefits from the Nested Pages ability. That's pretty much all we can.

Use cases

• UC1: Current Parent/Child relationship should be preserved and presented in some way.
• UC2: Preferences applied to a page should not be changed by the migration.
• UC3: The user should be able to select which pages are going to be moved, and which not.
• UC4: Scalability: the migration should work on wiki containing a huge amount of pages.
• UC5: Transparency: some informations about the migration being executed should be displayed to the user (logs).
• UC6: The migration should be stoppable.
• UC7: Bookmarks should not be broken after the migration.
• UC8: The migration should be optional and the breadcrumb should handle it
• UC10: Add the ability to add children to existing pages.
• UC11: Don't break extensions

Implementation and problems

UC1: Move children pages under the parent page

Problems:

• You have SciFi.List and Dramas.List, both children of Movies.WebHome. If they are moved under Movies, the target will be Movies.List for both. Maybe it should be
  Movies.SciFi.List and Movies.Dramas.List but it is hard to anticipate what the user want.
  • Maybe this situation is not so frequent, because SciFi.List is more probably a child of SciFi.WebHome, which is a child of Movies.WebHome
  • But at least, we should propose a way to avoid this situation.

• If we have Persons.Angelina with Persons.Kevin as child and Persons.Ben a child of Persons.Kevin:

1. First, Persons.Angelina should be renamed Persons.Angelina.WebHome.
2. Then Persons.Kevin should be renamed Persons.Angelina.Kevin.WebHome and the parent field should be set to Persons.Angelina.WebHome.
3. Finally Persons.Ben should be renamed Persons.Angelina.Kevin.Ben.WebHome and the parent field should be set to Persons.Angelina.Kevin.WebHome.

• 
  
  • You get only 3 actions.
  • But if you start by renaming Persons.Ben to Persons.Kevin.Ben before moving Persons.Kevin with all its children, you will have more saving operations. We should avoid that by first renaming top level pages.
  • So we need to compute all changes before applying them.

• Should we propose a list of strategies to apply in a case by case basis?
• Note: some internal links (e.g. an xobject having a reference to a page) will be broken

UC10: Transform terminal pages to nested pages

Problems:

• it could be done for user created-pages, but it should not affect technical pages. Most of them are terminal right now, even in XWiki 7.4. (see UC11)
• same problem: data page created by applications (like AWM) are not supposed to be nested. How to detect them? Looking if some object is attached to them? Or let the user decide per space?

• Some pages have to be in a black list: pages containing an User object, pages containing a Skin object, pages containing a class etc...

UC4, UC5, UC6: Implement the migration as a job (probably in Java)

• Add a progress bar in the UI and display the logs via JavaScript.

I don't see any problem except that it takes time to implement.

UC3: Checkboxes

Like the "install plan" computed before an extension is installed, we should list the proposed actions to be made. Then the user could select (with a checkbox) which actions should be done (all enabled by default).

Problems:

• it must be scalable.
  • Should we paginate this form?

UC7: A redirect object should be saved in the old location of the document.

Seems easy to do, except if the old location is now used by a moved page.

UC8: Add a way to simply change the "hierarchy mode" per wiki

Optional: add an helper to configure hierarchyMode.
See if it is doable per wiki.

UC2: Copy all inherited preferences to the Target.WebPreferences pages

Better: copy only the ones that are distinct from the inherited in the new location

• Hard to do!

In some cases, the preferences could be saved in ParentPage.WebPreferences

• Should we propose which strategy to apply in a case by case basis?

UC11: Don't apply transformations on technical pages.

Problems:

• how to know if a page is technical or not?
  • maybe using the hidden property.

Mock ups

With preferences:

Proposition B

• Do not handle UC1 and let the user put the children pages under the parent page manually if she wants to.
• Only transform the terminal pages to Nested Pages so the user can create children to existing documents, but nothing from preferences to URL, will be broken.

Ideally, the tool should propose both options.