Hi, Going on the "node" architecture, where we have only documents and child documents, here's something interesting that pops up as "the way to go" when storing a tree structure in SQL [1]: Closure Table [2]. It seems to cover pretty much all use cases, as solution 1 (Path Enumeration - what we are doing with the "space" document field) is limited [3] when it comes to changes in the tree structure (i.e. renaming/moving a document).
Note: There is also the extension [4] that includes a depth column which would be most useful as well. Basically, getting the list of parents of a document would cost only 1 query, sorting by depth to preserve hierarchy. Of course, all this requires an extra table in the database for storing the hierarchy relationship. WDYT? Thanks, Eduard ---------- [1] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/48 [2] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/68 [3] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/77 [4] http://www.slideshare.net/billkarwin/sql-antipatterns-strike-back/76 On Sat, Jun 6, 2015 at 3:38 PM, [email protected] <[email protected]> wrote: > > > > > > On 6 Jun 2015 at 14:20:46, [email protected] ([email protected](mailto: > [email protected])) wrote: > > > Hi Marius, > > > > On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea ( > [email protected](mailto:[email protected])) > wrote: > > > > > On Wed, Jun 3, 2015 at 5:10 PM, Guillaume "Louis-Marie" Delhumeau > > > wrote: > > > > Hello XWiki committers. > > > > > > > > > > > > Vincent have proposed the development of nested spaces for 7.2 and > some of > > > > us have already agreed. But the concept of nested spaces introduces a > > > > problem that Denis have mentioned during some internal discussions > at XWiki > > > > SAS, and that I am going to report here. > > > > > > > > > > > > From a UI perspective, differentiating pages `A.B.C.WebHome` and > `A.B.C` > > > > could become very difficult. > > > > > > > > > > > > > > > Moreover, we know that a lot of users do not understand the notion of > > > > spaces, and they are lost when you look at them during usability > sessions. > > > > > > I'm not sure about this statement. My feeling is that many users > > > understand spaces as "folders" (they make the analogy with the file > > > system). Moreover, whenever we display a space in the XWiki UI we use > > > the folder icon, so we encourage the users to make this analogy. > > > > I agree with Guillaume here. We’ve seen it on this list but more > importantly Caty has done some recorded usability sessions and if I > remember correctly it was clearly showing the problem. And users don’t > understand that Spaces are like Folders which is why we also had this > discussion on the list at one point about renaming them as Folder. > > > > In any case, removing one concept can only be simpler IMO. I find it > simpler to have 2 concepts (Wiki, Pages: A wiki is a set of pages) instead > of 3 (Wiki, Spaces, Pages: a wiki is a set of spaces, which each one > containing pages). > > > > > > The situation is even worse if you consider the notion of > parent/child > > > > documents, which is completely unrelated to the actual hierarchy. It > > > > creates confusion! > > > > > > > > > > > > > > > To fix these problems, we propose to introduce the notion of "nested > > > > documents", i.e. the ability to create documents inside documents. > > > > > > What's the difference at a *conceptual* level between the notion of > > > parent/child we have right now and the notion of nested documents you > > > propose? I don't see it. > > > > Yes it’s the same thing from a User POV. One difference is that we want > a reference to contain the full path of a doc. Right now you’d need to > transport the (Doc Reference + the full Breadcrumb) to represent the same > thing. > > > > But I agree that it’s the same concept, it’s just a different > implementation. That’s why I’m proposing to drop the parent/child fields as > we have them now since it’s just duplicating the concepts (and it’s > confusing for users), and to reimplement the Breadcrumb UI using Doc > References. > > > > Note that having the full location in the reference also allows to have > URLs containing the full path which is interesting (for knowing where you > are by looking at the URL: http://.../view/Space.Page1, > http://.../view/Space.Page2 > doesn’t indicate anything about the relationship between Page1 and Page2 > when Page1 could the parent of Page2). It’s also interesting for SEO. > > > > > You even use "parent" and "child" words below > > > to explain the "nested" notion. The word "nested" sounds very > > > technical to me. I don't know about French, but in my native language > > > the translation for "nested" is not a commonly used word, unlike > > > parent and child. It seems easier to me to explan to a user that a > > > document can have a parent document and some child documents (the > > > parent / child relationship) then to explain them that a document can > > > be "nested" inside another document and can "nest" other documents > > > too. > > > > I don’t think GL has suggested to use the word Nested anywhere in the > UI… It’s just a word we use internally to describe the feature. I’m fine to > continue using the terminology Parent and Children. > > > > > > Say differently, if a page `A.B.C` exists, nothing should stop the > user to > > > > create the document `A.B.C.D`. > > > > > > You mentioned JCR on the next paragraph. Are JCR nodes identified by > > > the position (path) in the tree? > > > > Yes. They call it Path (we call it a Document Reference). > > > > > I think we should make a distinction > > > between the way we identify a document and the way we access that > > > document. > > > > This means using unique ids for identifying docs (and this is what we > already have in the DB except the Id is based on its path in the DB but > this could be changed and this is our problem). Of course in the UI we > should never display these ids. > > > > > I like the fact that currently when you change the parent of > > > a document the document identifier (reference) stays the same. > > > > It’s not fully true. When we rename a doc the doc id is modified. > > > > What would be interesting would be the ability to have several Document > References for a given doc (with one being the default probably). This is > something I’ve been interested in implementing for a long time but it would > probably require some model changes and it’s not for XWiki 7.x IMO. We > could discuss it when we talk about XWiki 8.x and the new model in general. > See also http://design.xwiki.org/xwiki/bin/view/Design/XWikiModel20 (on > that page I had put: “Ability to have multiple references pointing to the > same entity” and yes this is also supported by the JCR API). > > Also note the idea of "An Entity can be a pointer to another Entity (e.g > of use case: rename, aliases)” from that doc. This should be not to hard to > implement using our current model by adding a Type field in the DB. But > it’s a breaking change that would require 8.x (because current apps doing > queries on the doc table would get the “pointer” Types which should be > excluded, unless we add a filter to search*() APIs + the Query API). > > Thanks > -Vincent > > > > > In JCR[1], there is only one concept: the "node". A node can have a > > > > content, and a list of child nodes. In XWiki, documents could become > a kind > > > > of nodes, and we do not need spaces anymore. > > > > > > > > > > > > If we don't have space anymore, we could ask ourselves: "How the > rights > > > > will be propagated to the children documents? How do we distinguish > rights > > > > applied to the documents and the rights applied to the children?" > > > > > > > > > > > > I think the easiest solution is to inherit the rights from the > parent to > > > > the children, unless an object prevent it. We already have this kind > of > > > > mechanism with XWikiRights and XWikiGlobalRights. XWikiRights would > be > > > > applied for the current document, and XWikiGlobalRights for the > document and > > > > its children. > > > > > > > > > > > > But changing the XWiki model is a lot of work, that we don't have > time to > > > > achieve for 7.2. So we propose to make it step by step. > > > > > > > > > > > > The first step is to change the UI to hide the notion of space to the > > > > users. Concretely, each time a user wants to create a page called > `A`, we > > > > actually create the document `A.WebHome`. So any child of this page > would > > > > be created in the `A` space, like `A.Child`. But this child would be > in a > > > > space too, so it would be `A.Child.WebHome` actually. > > > > > > I find this 'A.WebHome' thing too complex. Look at the document > > > hierarchy tree > http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro#HDocumentHierarchyTree > > > . We can hide the spaces already by relying on the parent / child > > > relationship. > > > > A.WebHome is too complex which is exactly why Guillaume is sending this > proposal about Nested Documents. The idea is that the doc will be seen as > “A" for the user (and implemented technically as A.WebHome till we update > the DB to remove the “space” field, which would make the impl much simpler). > > > > > > Then, when we display the `A.WebHome` page, we remove all mentions > to the > > > > `WebHome` name. In the UI, it will just be presented as the document > `A`. > > > > This is a good point, knowing the fact that the term `WebHome` have > no > > > > sense for the user, neither in English or in other languages. > > > > > > > > > > > > Again, these changes are only for the UI. For the applications, it > is the > > > > developer's job to decide if the app will create documents like > > > > `Document.WebHome` or basic documents just as before. > > > > > > > > > > > > The question of what to do with AWM comes up. When a user creates an > entry, > > > > should it be a new-kind-of-document (`AppSpace.Entry.WebHome`) or an > > > > old-kind-of-document (`AppSpace.Entry`)? The first option is good for > > > > consistency and for the new possibilities it offers, but the second > is > > > > better for retro-compatibility. And the question will be the same > for all > > > > existing applications that create pages. I believe we should answer > these > > > > questions on a case-by-case basis and deserve their own mail threads. > > > > > > > > > > > > This proposal also implies to change some macros, like the {{space}} > one, > > > > and some panels. But I believe there is no blocking-point there. > > > > > > > > > > > > Finally, after these steps are accomplished in 7.2 and polished > until the > > > > end of the 7.x cycle, we will refactor the XWiki model (something we > dream > > > > about for years). > > > > > > > > > > > > To sum up, the idea we propose is: > > > > > > > > > > > > On the short run: > > > > > > > > - Hide the notion of space in the UI. > > > > > > > > - Hide the `WebHome` name in the UI. > > > > > > > > - When a user creates a page from the UI, it actually creates a > space with > > > > a WebHome. > > > > > > > > - Remove the current parent/child mechanism which is outdated (and > > > > confusing) compared to the new hierarchy. > > > > > > > > > > > > On the long run: > > > > > > > > - Remove the notion of space in the model, and replace it by "nested > > > > documents". > > > > > > > > - Tune the rights system to inherit rights from parents to children. > > > > > > > > > > > > Of course, we can discuss the technical details and the > implementation > > > > strategies. But for now, we need to know if you accept the general > idea > > > > (nested documents). > > > > > > > > > > > > > > > So, I hope you will like this proposal, and here is my +1. > > > > > > I'm not convinced. I don't see why we should drop the parent/child > > > relationship in order to introduce something similar but more complex. > > > > I’d say mostly because we need to transport the full location in the Doc > Reference, which allows us to do lots of things: > > - display it in the URL > > - no need to recompute the breadcrumb every time we need to display the > hierarchy (which is the case now and it doesn’t scale) > > - ability in the future to have several references for a single doc > > - consistency: there’s no reason that the space would be in the > reference but not the parent… ATM we have two concurrent concepts which > makes it impossible for users to understand the difference between Spaces > and child/parent relationships. > > > > Thanks > > -Vincent > > > > > Thanks, > > > Marius > > > > > > > > > > > > > > > Thanks, > > > > > > > > Guillaume D. > > > > > > > > > > > > > > > > [1] JCR: > https://en.wikipedia.org/wiki/Content_repository_API_for_Java > > > > > > > > > > > > > > > > > > > > -- > > > > Guillaume Delhumeau ([email protected]) > > > > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
