From version < 3.7 >
edited by Guillaume Delhumeau
on 2016/02/25
To version < 3.10 >
edited by Guillaume Delhumeau
on 2016/02/25
Change comment: There is no comment for this version



Page properties
... ... @@ -16,6 +16,40 @@
16 16  
17 17  Some applications used this parent/child relationship to organized their data. For them, this relationship is crucial.
18 18  
19 +== The introduction of the Nested Pages concept ==
20 +
21 +In XWiki 7.2, due to frequent users demands, we have introduced the ability to create spaces under some other spaces. It's the **Nested Spaces** concept. We suddenly had the ability to create a hierarchy of spaces to organize our content.
22 +
23 +But we have also found some issues. What if a space hold the same name then a page? Which entry should we render to the user when she reach an URL where 2 entities are matching? Moreover, does it make sense to have a difference between a space and a page? Why the pages cannot have sub-pages inside of them?
24 +
25 +Then we have decided to switch to the **Nested Pages** concept. In theory, a page should now be able to have some sub-pages, because we don't need to have a distinct between a page and a space like we have between a file and a folder.
26 +
27 +But this change was not possible to make on the API side because it would have required too much work that we could not afford at this time. So the decision was made to stick on the **Nested Spaces** implementation on the API (for now), but to propose **Nested Pages** in the UI.
28 +
29 +How does it work?
30 +
31 +Each time a user creates a page from the XWiki UI, she now actually creates a space (without knowing it ;)) with its ##WebHome## page. It means that any user-created page is called ##WebHome##.
32 +
33 +Then, when the user wants to create a sub-page ##FrankCapra## in the page ##Directors.WebHome##, she actually creates a new space inside the space ##Directors## with its ##WebHome## page: ##Directors.FrankCapra.WebHome##. **That's the trick!**
34 +
35 +The notion of space have been removed from the UI. It's not mentioned anywhere, anymore. Everything seems to work as if we were really creating sub-pages, even if we have created sub-spaces behind the scene.
36 +
37 +{{info}}
38 +That tricks should be temporary. When we will able the opportunity to rewrite the core model of XWiki, we will really implement the Nested Pages concept in the API.
39 +{{/info}}
40 +
41 +Note that the user has still the ability to create pages that does not have the ##WebHome## name. As a consequence, such pages (that are not the WebHome of their space) cannot have sub-pages. That is why we call them **Terminal Pages**.
42 +
43 +== Issue with the Parent/Child relationship ==
44 +
45 +Now, it is clear that we had 2 different hierarchies in the wiki. One, made of sub-pages (sub-spaces in the reality), and one made with the old parent/child relationship. Then, clearly, it becomes confusing for the user. Which hierarchy should be displayed in the breadcrumb? What is the parent of page, the "container" page or the parent set in the field?
46 +
47 +The choice have been made to drop the notion of parent/child relationship, since we can now really have children pages, implemented as sub-pages (with inherited rights, preferences, etc...).
48 +
49 +It means that when the user wants to change the parent of a page, she actually needs to **move** this page under the new parent.
50 +
51 +This concept are good in theory. But, how can we handle existing content when an XWiki upgrade is made?
52 +
19 19  = Principle =
20 20  
21 21  After having upgrade the XWiki instance to a recent version (7.4+), you should convert your existing pages to nested ones. This will permit:

Get Connected