2015-06-17 18:17 GMT+02:00 [email protected] <[email protected]>: > > > > > > On 17 Jun 2015 at 17:59:56, Guillaume Louis-Marie Delhumeau ( > [email protected](mailto:[email protected])) wrote: > > > I've created a design page: > > http://design.xwiki.org/xwiki/bin/view/Proposal/NestedDocuments > > > > For the cost of having Nested Documents as an option in the UI, I see the > > following points: > > > > - 2 versions of the top level menu. > > Why 2 versions? I see only one. >
Because the actions for spaces are not the same than the actions for pages. If the concept of spaces is removed (ND enabled), then we must re-organize these actions. Unless we implement the menu designed by Caty: http://design.xwiki.org/xwiki/bin/view/Proposal/MacawSkin I love this idea. > > > - 2 versions of the create page form. > > - 2 versions of the create page panel. > > I agree. We could think about dropping that Create Page Panel BTW. We kept > it for backward compat reasons with older skins which didn’t have the Add > menu but now that we’ve had skins that added this button for several cycles > we could maybe make that panel optional as an extension on e.x.o. > > > - What about the *spaces* macro? 2 different behaviors? If not, should > > the space macro be used in the default Dashboard? > > I think we could have a Document Tree instead of the Spaces list by > default, possibly with the ability to do some actions on spaces (like space > index as it’s done for the current spaces macro). WDYT? > > > Some questions: > > > > - What do we do with the most edited spaces panel? > > I think that any panel that manages spaces but not used by default could > stay as they are (provided we hide the WebHome). They don’t have to be used > and someone configuring his wiki to not show spaces would just not use it. > > > - What do we do with the space documents panel (display all documents of > > the current space)? > > Same answer as above. > > WDYT? > > Thanks > -Vincent > > > 2015-06-15 10:59 GMT+02:00 Thomas Mortagne : > > > > > +1 > > > > > > On Fri, Jun 12, 2015 at 5:22 PM, [email protected] > > > wrote: > > > > Hi Devs, > > > > > > > > After discussing with Anca about this she raised an idea which I find > > > interesting and that I’d like to discuss. > > > > > > > > * We all agree about Nested Spaces so that’s a given. > > > > * Now for Nested Document it’s less obvious. Some of us (most) > believe > > > that the way forward is to drop the concept of Spaces not only in the > UI > > > but also in the DB. However some others (Denis for example) believe > that we > > > shouldn’t change the model because it’ll be reused for implementing > other > > > features in the future (translations, permissions on xobjects, etc). > Some > > > (me included) are expressing doubts that we’ll be able to move to > Nested > > > Docs in the model any time soon. > > > > * Anca pointed out that Nested Documents in the UI is just a special > > > view of Nested Spaces. A bit similar to the Simple/Advanced user > feature or > > > the Show Hidden Documents one. She argues that the concept of spaces, > if it > > > exists in the model (which is the case ATM), will surface to the users > when > > > they start writing scripts for example. > > > > * Said differently she believes that the UI should be in accordance > with > > > the model and that it’s a bit utopian to think that users will never > see > > > it. But she also acknowledges that it could be interesting for some > users > > > or xwiki instances to have a simplified view. > > > > * Thus Anca is asking us to think about the possibility to view > Nested > > > Documents as an **option** that can be turned on/off (could be > implemented > > > as a different skin or possibly better as options of the current skin). > > > > * Breadcrumb and menu modifications would still be done since they’re > > > related to Nested Spaces and not Nested Documents, etc. Only the > features > > > purely related to Nested Documents would need to be able to be turned > > > on/off (there are also plenty of places where we can find a common UI > for > > > both NS and ND). > > > > > > > > To be honest, I’m not 100% sure how ND would be received by users and > > > it’s possible that it won’t be the best choice in the end and that we > wish > > > to change it in the future. I would find it interesting to be able to > > > implement the UI for NS and be able to turn on ND if need be (or the > other > > > way around). > > > > > > > > I’m thus proposing to evaluate how complex it would be to display > both a > > > NS UI and a ND UI, based on some config options. > > > > > > > > Note that it’s possible that by trying to list all places that would > be > > > different, in the end, we could come up with very little places and > thus > > > there would be only a small/reasonable overhead of keeping the 2 > options. > > > > > > > > I can think of Add > Page (note that Add > Space could be removed IMO > > > and let the user be able to create a Space when adding a page only, > which > > > would remove one difference). > > > > > > > > WDYT? > > > > > > > > Thanks > > > > -Vincent > > > > > > > > > > > > On 11 Jun 2015 at 17:28:11, Eduard Moraru ([email protected] > (mailto: > > > [email protected])) wrote: > > > > > > > >> +1, with the same opinion on long URLs. > > > >> > > > >> So we need a way to have a document hierarchy without impacting the > URL > > > >> scheme, unless the admins of the wiki explicitly want to configure > it > > > that > > > >> way. This means, as Caty suggested in an offline discussion, not > doing > > > the > > > >> proposed item: > > > >> "- Remove the current parent/child mechanism which is outdated (and > > > >> confusing) compared to the new hierarchy." > > > >> > > > >> We still need the parent/child mechanism, but we could disable it by > > > >> default and allow admins that create a new wiki or that migrate > from a > > > >> previous XWiki version that does not have ND to preserve their > hierarchy > > > >> and not change their URLs. The direction would obviously be to > encourage > > > >> the creation of Nested Documents, while still keeping the option of > > > having > > > >> shorter URLs (using parent-child). > > > >> > > > >> Note: If we keep both relationships (space-page and parent-child) > the > > > >> create/move/etc UIs will need to check if the parent-child > relationship > > > is > > > >> enabled and provide a field to set/alter that too. > > > >> > > > >> Thanks, > > > >> Eduard > > > >> > > > >> On Thu, Jun 11, 2015 at 12:54 PM, Marius Dumitru Florea < > > > >> [email protected]> wrote: > > > >> > > > >> > On Wed, Jun 10, 2015 at 6:36 PM, Ecaterina Moraru (Valica) > > > >> > wrote: > > > >> > > Hi, > > > >> > > > > > >> > > Since we discussed so many things lately and there are many > > > technical > > > >> > > constrain that we are facing, I'm going to try to get some > > > conclusions > > > >> > from > > > >> > > the UI perspective: > > > >> > > > > > >> > > First of all there was the discussion about the usability tests. > > > It's > > > >> > true > > > >> > > that users are confused that we provide 2 levels of hierarchy > > > >> > > (wiki/space/page and parent/child). If we can switch to just > one it > > > would > > > >> > > be great since it will simplify the user's mental model. Another > > > problem > > > >> > > they had was with the naming, since wiki/space/page does not > ring > > > any > > > >> > > folder/page bell, even with the icon usage. That's why I like > the > > > concept > > > >> > > of nodes and only one type of entities that can have children. > > > Since we > > > >> > are > > > >> > > on the Web, I think the most likely entity name we could use is > > > 'page', > > > >> > > similar to content-page, web-page, wiki-page (even if > technically > > > is a > > > >> > > space or a document). > > > >> > > > > > >> > > Having only one type of entity, I agree to the fact that we > should > > > remove > > > >> > > the space notion. We still have complexity, since we will have > > > main-wiki, > > > >> > > wikis*, pages* (child-pages). > > > >> > > > > > >> > > I also agree to remove the notion of 'WebHome' from UI. We can > > > still use > > > >> > it > > > >> > > technically to differentiate old spaces from pages, but for the > user > > > >> > > doesn't mean anything, except looking technical. > > > >> > > > > > >> > > Regarding the global-menu, we need to remove the > > > wiki>space>page+actions > > > >> > > display since it is not scalable. This means that the current > > > breadcrumb > > > >> > > zone will display the hierarchy. This is perfectly normal with > the > > > >> > current > > > >> > > navigation patterns used all over the Web. Note that classical > > > breadcrumb > > > >> > > do not display entity-type or actions. We shouldn't either. This > > > means > > > >> > (as > > > >> > > stated on > > > >> > > http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb) > > > >> > > that we need to provide a Drawer + Move actions inside the > > > content-menu. > > > >> > > > > > >> > > Regarding actions, since we will have just one entity-type (not > > > sure what > > > >> > > we do with the wikis) we will need to standardize the entity > > > actions. > > > >> > > Currently we provide just 'Delete' for spaces, but if we don't > > > display > > > >> > > Spaces differently and they are just nodes, this means that we > will > > > need > > > >> > to > > > >> > > implement or normalize the available actions. No matter what > type > > > it is > > > >> > > technically, the user should be able to: Add (child), Edit, > Delete, > > > View, > > > >> > > Administer, Copy, Rename, Move, Export, Watch, View History, > View > > > >> > > Informations, View Attachments, View Comments, View Rights, View > > > Objects, > > > >> > > etc. > > > >> > > > > > >> > > > > >> > > Now, what I really don't like are the long URL. For me this is > the > > > most > > > >> > bad > > > >> > > decision we can make. Nobody uses long URL on the web. I really > > > like the > > > >> > > way our current parent/child works, it provides the hierarchy in > > > the UI, > > > >> > > invisible in the URL (keeping it relevant to the current page). > > > Hierarchy > > > >> > > anyway should we displayed in Trees, not linear in URLs, since > it's > > > hard > > > >> > to > > > >> > > read. People like short URL. They are easier to share, easier to > > > scan, > > > >> > > easier to understand what the content is about. We have the > > > breadcrumbs > > > >> > for > > > >> > > navigation, the URL is for identification. > > > >> > > > > >> > +1, I don't like long URLs either. > > > >> > > > > >> > Thanks, > > > >> > Marius > > > >> > > > > >> > > > > > >> > > Thanks, > > > >> > > Caty > > > >> > > > > > >> > > > > > >> > > > > > >> > > On Mon, Jun 8, 2015 at 11:40 AM, Eduard Moraru > > > >> > wrote: > > > >> > > > > > >> > >> 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] > > > >> > >> 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 > > > >> > >> > > > >> > > _______________________________________________ > > > >> > > devs mailing list > > > >> > > [email protected] > > > >> > > http://lists.xwiki.org/mailman/listinfo/devs > > > >> > _______________________________________________ > > > >> > devs mailing list > > > >> > [email protected] > > > >> > http://lists.xwiki.org/mailman/listinfo/devs > > > >> > > > > >> _______________________________________________ > > > >> devs mailing list > > > >> [email protected] > > > >> http://lists.xwiki.org/mailman/listinfo/devs > > > > _______________________________________________ > > > > devs mailing list > > > > [email protected] > > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > > -- > > > Thomas Mortagne > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > > > > > > -- > > Guillaume Delhumeau ([email protected]) > > Research & Development Engineer at XWiki SAS > > Committer on the XWiki.org project > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > -- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
