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.
> - 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
