3 Jun
2015
3 Jun
'15
4:10 p.m.
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.
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.
Say differently, if a page `A.B.C` exists, nothing should stop the user to
create the document `A.B.C.D`.
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.
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.
Thanks,
Guillaume D.
[1] JCR: https://en.wikipedia.org/wiki/Content_repository_API_for_Java
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
3 Jun
3 Jun
4:24 p.m.
There is an important point missing in your proposal: how to you
link/include/target such "pages" that actually ends up as space being
the scene ? Right now with what you propose you will have to write
[[A.Child.WebHome]] or {{include reference="A.Child.WebHome"/}} even
if the UI is teling all the way you that you have a "A.Child" page.
On Wed, Jun 3, 2015 at 4:10 PM, Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> 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.
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.
Say differently, if a page `A.B.C` exists, nothing should stop the user to
create the document `A.B.C.D`.
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.
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.
Thanks,
Guillaume D.
[1] JCR: https://en.wikipedia.org/wiki/Content_repository_API_for_Java
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
4 Jun
4 Jun
10:26 a.m.
Hi Guillaume,
On 3 Jun 2015 at 16:10:36, Guillaume Louis-Marie Delhumeau
(gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
[snip]
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.
Note: I believe this email could have been a VOTE since it’s a very important concept
change and we don’t vote on proposal. Let’s consider it as a brainstorming idea ATM which
could lead to a VOTE later on if need be.
I’m globally +1 to both hiding the concept of Space from the UI and to later on remove it
from the model.
Some comments:
* Regarding the Nested Spaces proposal,
see http://design.xwiki.org/xwiki/bin/view/Proposal/NestedSpaces
* About hiding WebHome from the UI. This is something we should already be doing now even
without the notion of Nested Spaces. Nothing is preventing us from doing it now.
* Regarding permissions, since we want to keep the ability to programatically create pages
named other than WebHome for now (till we modify the model) we’ll need to do the
following: Do not show the page permission menu entry when a user is on a WebHome page
(unless there’s already a Right xobject)
* Regarding the current breadcrumb, in order to ease the migration, I’d propose to make it
configurable in the config: either to use the old style breadcrumb based on parent/child
relationships or the new breadcrumb based on Document References. When the old mode is on,
editing a page should show the parent relationship field as now. We have to remember that
people switching to XWiki 7.2 will not have deep hierarchies set up on their docs (and not
many pages named WebHome).
* I think we’ll need to go even more in the direction defined in the “conclusion” section
of http://design.xwiki.org/xwiki/bin/view/Proposal/ExtendedBreadcrumb, i.e.
** Just a drawer-menu on the right (as proposed for the Macaw skin)
** A breadcrumb based on Document References (+ possibly the ability to execute some
actions at each level)
* We should probably keep the notion of Wiki even though it could be argued that wikis
could be top level documents with some xobject in them.
* Regarding Thomas's comment about creating wiki links, yes we might want to do the
following:
** When rendering [[label>>A.B.C]] we could check if a page named C exists and if so
link to it. If not, check if a page named C.WebHome exists and if so link to it. Otherwise
make it a wanted link (ie display a “?”). This would be a similar logic than for URLs
(supporting A/B/C as well as A/B/C/WebHome or A/B/C/)
Thanks
-Vincent
Thanks,
Guillaume D.
[1] JCR: https://en.wikipedia.org/wiki/Content_repository_API_for_Java
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
6:15 p.m.
On Wed, Jun 3, 2015 at 5:10 PM, Guillaume "Louis-Marie" Delhumeau
<gdelhumeau(a)xwiki.com> wrote:
> 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#HD…
. We can hide the spaces already by relying on the parent / child
relationship.
> 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).
> Thanks,
>
> Guillaume D.
>
> [1] JCR: https://en.wikipedia.org/wiki/Content_repository_API_for_Java
> --
> Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
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.
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. 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.
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? I think we should make a distinction
between the way we identify a document and the way we access that
document. I like the fact that currently when you change the parent of
a document the document identifier (reference) stays the same.
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.
Thanks,
Marius
6 Jun
6 Jun
2:20 p.m.
Hi Marius,
On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea
(mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:
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.
Yes. They call it Path (we call it a Document Reference).
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).
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
On Wed, Jun 3, 2015 at 5:10 PM, Guillaume
"Louis-Marie" Delhumeau
wrote:
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).
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. 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. 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? 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).
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#HD…
. We can hide the spaces already by relying on the parent / child
relationship. 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. Thanks,
Marius
>
>
> Thanks,
>
> Guillaume D.
>
>
>
> [1] JCR: https://en.wikipedia.org/wiki/Content_repository_API_for_Java
>
>
>
>
> --
> Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
2:38 p.m.
On 6 Jun 2015 at 14:20:46, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
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).
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
Hi Marius,
On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea
(mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:
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.
Yes. They call it Path (we call it a Document Reference).
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
On Wed, Jun 3, 2015 at 5:10 PM, Guillaume
"Louis-Marie" Delhumeau
wrote:
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).
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. 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. 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? 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). 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#HD…
. We can hide the spaces already by relying on the parent / child
relationship. 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. Thanks,
Marius
>
>
> Thanks,
>
> Guillaume D.
>
>
>
> [1] JCR: https://en.wikipedia.org/wiki/Content_repository_API_for_Java
>
>
>
>
> --
> Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
8 Jun
8 Jun
10:40 a.m.
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, vincent(a)massol.net <vincent(a)massol.net>
wrote:
On 6 Jun 2015 at 14:20:46, vincent(a)massol.net (vincent(a)massol.net(mailto:
vincent(a)massol.net)) wrote:
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.
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.
UI… It’s
just a word we use internally to describe the feature. I’m fine to
continue using the terminology Parent and Children.
Yes. They call it Path (we call it a Document Reference).
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.
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
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).
I’d say mostly because we need to transport the full location in the Doc
Reference, which allows us to do lots of things:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Hi Marius,
On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea (
mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com))
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
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.
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
> > 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? 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 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 > > 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#HD…
. 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
> > 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. - 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 (gdelhumeau(a)xwiki.com)
10 Jun
10 Jun
5:36 p.m.
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.
Thanks,
Caty
On Mon, Jun 8, 2015 at 11:40 AM, Eduard Moraru <enygma2002(a)gmail.com> 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, vincent(a)massol.net <vincent(a)massol.net>
wrote:
of
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.
instead
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.
as
be
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).
document
threads.
complex.
On 6 Jun 2015 at 14:20:46, vincent(a)massol.net (vincent(a)massol.net
(mailto:
vincent(a)massol.net)) wrote:
introduces
a
Hi Marius,
On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea (
mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com))
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 > >
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 > >
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
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) of 3 (Wiki, Spaces, Pages: a wiki is a set of
spaces, which each one
containing pages).
It
> > The situation is even worse if you consider the notion of
parent/child
> > > documents, which is completely unrelated to the actual hierarchy. > > > 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
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 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.
.../view/Space.Page2
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:// doesn’t indicate anything about the relationship
between Page1 and Page2
when Page1 could the parent of Page2). It’s also interesting for SEO.
UI… It’s
just a word we use internally to describe the feature. I’m fine
to
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 continue using the terminology Parent and
Children.
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.
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
> > 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 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 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
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 of
the
> > 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 > >
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 in a
http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro#HD…
> > space too, so it would be
`A.Child.WebHome` actually.
>
> I find this 'A.WebHome' thing too complex. Look at the document
> hierarchy tree
. 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
> > 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 `A`.
an
> > 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 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 > > >
> > >
> > > This proposal also implies to change some macros, like the
{{space}}
one,
we
> > 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 dream
"nested
> > 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 > > > 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 >
> I’d say mostly because we need to transport the full location in the
Doc
Reference, which allows us to do lots of things:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
- 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 (gdelhumeau(a)xwiki.com)
11 Jun
11 Jun
11:54 a.m.
On Wed, Jun 10, 2015 at 6:36 PM, Ecaterina Moraru (Valica)
<valicac(a)gmail.com> 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 <enygma2002(a)gmail.com> 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, vincent(a)massol.net <vincent(a)massol.net>
wrote:
of
instead
as
be
simpler).
document
threads.
complex.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On 6 Jun 2015 at 14:20:46, vincent(a)massol.net (vincent(a)massol.net
(mailto:
vincent(a)massol.net)) wrote:
introduces
a
Hi Marius,
On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea (
mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com))
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 > >
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 > >
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) of 3 (Wiki, Spaces, Pages: a wiki is a set of
spaces, which each one
containing pages).
It
> > The situation is even worse if you consider the notion of
parent/child
> > > documents, which is completely unrelated to the actual hierarchy. > > > 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 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.
.../view/Space.Page2
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:// doesn’t indicate anything about the relationship
between Page1 and Page2
when Page1 could the parent of Page2). It’s also interesting for SEO.
to
> 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 continue using the terminology Parent and
Children.
would
> > 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 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
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 of
the
> > 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 > >
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 in a
http://extensions.xwiki.org/xwiki/bin/view/Extension/Document+Tree+Macro#HD…
> > space too, so it would be
`A.Child.WebHome` actually.
>
> I find this 'A.WebHome' thing too complex. Look at the document
> hierarchy tree
> . 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
> > 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 `A`.
an
> > 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 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 > > >
> > >
> > > This proposal also implies to change some macros, like the
{{space}}
one,
we
> > 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 dream
"nested
> > 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 > > > 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 >
> I’d say mostly because we need to transport the full location in the
Doc
Reference, which allows us to do lots of things:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
- 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 (gdelhumeau(a)xwiki.com)
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:27 p.m.
+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 <
mariusdumitru.florea(a)xwiki.com> wrote:
On Wed, Jun 10, 2015 at 6:36 PM, Ecaterina Moraru
(Valica)
<valicac(a)gmail.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
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 <enygma2002(a)gmail.com>
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, vincent(a)massol.net <vincent(a)massol.net>
> wrote:
>
> >
> >
> >
> >
> >
> > On 6 Jun 2015 at 14:20:46, vincent(a)massol.net (vincent(a)massol.net
> (mailto:
> > vincent(a)massol.net)) wrote:
> >
> > > Hi Marius,
> > >
> > > On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea (
> > mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com
))
> > 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#HD…
> > > > . 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 (gdelhumeau(a)xwiki.com)
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12 Jun
12 Jun
5:22 p.m.
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
(enygma2002@gmail.com(mailto:enygma2002@gmail.com)) 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 <
mariusdumitru.florea(a)xwiki.com> wrote:
On Wed, Jun 10, 2015 at 6:36 PM, Ecaterina Moraru
(Valica)
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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, vincent(a)massol.net
> wrote:
>
> >
> >
> >
> >
> >
> > On 6 Jun 2015 at 14:20:46, vincent(a)massol.net (vincent(a)massol.net
> (mailto:
> > vincent(a)massol.net)) wrote:
> >
> > > Hi Marius,
> > >
> > > On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea (
> > mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com
))
> > 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#HD…
> > > > . 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 (gdelhumeau(a)xwiki.com)
> >
>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
15 Jun
15 Jun
10:15 a.m.
On Fri, Jun 12, 2015 at 6:22 PM, vincent(a)massol.net <vincent(a)massol.net> 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?
+1, I'm currently working on http://jira.xwiki.org/browse/XWIKI-12173
and I've added a parameter "showSpaceAsDocument" to the document tree.
Thanks,
Marius
>
> Thanks
> -Vincent
>
>
> On 11 Jun 2015 at 17:28:11, Eduard Moraru
(enygma2002@gmail.com(mailto:enygma2002@gmail.com)) 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 <
>> mariusdumitru.florea(a)xwiki.com> 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, vincent(a)massol.net
>> > >> wrote:
>> > >>
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> >
>> > >> > On 6 Jun 2015 at 14:20:46, vincent(a)massol.net
(vincent(a)massol.net
>> > >> (mailto:
>> > >> > vincent(a)massol.net)) wrote:
>> > >> >
>> > >> > > Hi Marius,
>> > >> > >
>> > >> > > On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea (
>> > >> >
mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com
>> > ))
>> > >> > 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#HD…
>> > >> > > > . 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 (gdelhumeau(a)xwiki.com)
>> > >> > >
>> > >> >
>> > >> > _______________________________________________
>> > >> > devs mailing list
>> > >> > devs(a)xwiki.org
>> > >> > http://lists.xwiki.org/mailman/listinfo/devs
>> > >> >
>> > >> _______________________________________________
>> > >> devs mailing list
>> > >> devs(a)xwiki.org
>> > >> http://lists.xwiki.org/mailman/listinfo/devs
>> > >>
>> > > _______________________________________________
>> > > devs mailing list
>> > > devs(a)xwiki.org
>> > > http://lists.xwiki.org/mailman/listinfo/devs
>> > _______________________________________________
>> > devs mailing list
>> > devs(a)xwiki.org
>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
10:59 a.m.
+1
On Fri, Jun 12, 2015 at 5:22 PM, vincent(a)massol.net <vincent(a)massol.net> 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
(enygma2002@gmail.com(mailto:enygma2002@gmail.com)) wrote:
--
Thomas Mortagne
+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 <
mariusdumitru.florea(a)xwiki.com> wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs On Wed, Jun 10, 2015 at 6:36 PM, Ecaterina Moraru
(Valica)
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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, vincent(a)massol.net
> wrote:
>
> >
> >
> >
> >
> >
> > On 6 Jun 2015 at 14:20:46, vincent(a)massol.net (vincent(a)massol.net
> (mailto:
> > vincent(a)massol.net)) wrote:
> >
> > > Hi Marius,
> > >
> > > On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea (
> > mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com
))
> > 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#HD…
> > > > . 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 (gdelhumeau(a)xwiki.com)
> > >
> >
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
17 Jun
17 Jun
5:59 p.m.
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.
- 2 versions of the create page form.
- 2 versions of the create page panel.
- What about the *spaces* macro? 2 different behaviors? If not, should
the space macro be used in the default Dashboard?
Some questions:
- What do we do with the most edited spaces panel?
- What do we do with the space documents panel (display all documents of
the current space)?
2015-06-15 10:59 GMT+02:00 Thomas Mortagne <thomas.mortagne(a)xwiki.com>om>:
+1
On Fri, Jun 12, 2015 at 5:22 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
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 (enygma2002(a)gmail.com(mailto:
enygma2002(a)gmail.com)) 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 <
> mariusdumitru.florea(a)xwiki.com> 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, vincent(a)massol.net
> > >> wrote:
> > >>
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On 6 Jun 2015 at 14:20:46, vincent(a)massol.net (
vincent(a)massol.net
> > >> (mailto:
> > >> > vincent(a)massol.net)) wrote:
> > >> >
> > >> > > Hi Marius,
> > >> > >
> > >> > > On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea (
> > >> > mariusdumitru.florea(a)xwiki.com(mailto:
mariusdumitru.florea(a)xwiki.com
> > ))
> > >> > 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#HD…
> > >> > > > . 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 (gdelhumeau(a)xwiki.com)
>> > >
>> >
>> > _______________________________________________
>> > devs mailing list
>> > devs(a)xwiki.org
>> > http://lists.xwiki.org/mailman/listinfo/devs
>> >
>> _______________________________________________
>> devs mailing list
>> devs(a)xwiki.org
>> http://lists.xwiki.org/mailman/listinfo/devs
>>
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:17 p.m.
On 17 Jun 2015 at 17:59:56, Guillaume Louis-Marie Delhumeau
(gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) 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, vincent(a)massol.net
wrote:
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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 (enygma2002(a)gmail.com(mailto:
enygma2002(a)gmail.com)) 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 <
> mariusdumitru.florea(a)xwiki.com> 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, vincent(a)massol.net
> > >> wrote:
> > >>
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On 6 Jun 2015 at 14:20:46, vincent(a)massol.net (
vincent(a)massol.net
> > >> (mailto:
> > >> > vincent(a)massol.net)) wrote:
> > >> >
> > >> > > Hi Marius,
> > >> > >
> > >> > > On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea (
> > >> > mariusdumitru.florea(a)xwiki.com(mailto:
mariusdumitru.florea(a)xwiki.com
> > ))
> > >> > 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#HD…
> > >> > > > . 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 (gdelhumeau(a)xwiki.com)
> >> > >
> >> >
> >> > _______________________________________________
> >> > devs mailing list
> >> > devs(a)xwiki.org
> >> > http://lists.xwiki.org/mailman/listinfo/devs
> >> >
> >> _______________________________________________
> >> devs mailing list
> >> devs(a)xwiki.org
> >> http://lists.xwiki.org/mailman/listinfo/devs
> >>
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
6:26 p.m.
2015-06-17 18:17 GMT+02:00 vincent(a)massol.net <vincent(a)massol.net>et>:
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
On 17 Jun 2015 at 17:59:56, Guillaume Louis-Marie Delhumeau (
gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
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.
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, vincent(a)massol.net
> 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 (enygma2002(a)gmail.com
(mailto:
> enygma2002(a)gmail.com)) 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 <
> >> mariusdumitru.florea(a)xwiki.com> 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, vincent(a)massol.net
> >> > >> wrote:
> >> > >>
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> > On 6 Jun 2015 at 14:20:46, vincent(a)massol.net (
> vincent(a)massol.net
> >> > >> (mailto:
> >> > >> > vincent(a)massol.net)) wrote:
> >> > >> >
> >> > >> > > Hi Marius,
> >> > >> > >
> >> > >> > > On 4 Jun 2015 at 18:16:03, Marius Dumitru Florea (
> >> > >> > mariusdumitru.florea(a)xwiki.com(mailto:
> mariusdumitru.florea(a)xwiki.com
> >> > ))
> >> > >> > 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#HD…
> >> > >> > > > . 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 (gdelhumeau(a)xwiki.com)
> > >> > >
> > >> >
> > >> > _______________________________________________
> > >> > devs mailing list
> > >> > devs(a)xwiki.org
> > >> > http://lists.xwiki.org/mailman/listinfo/devs
> > >> >
> > >> _______________________________________________
> > >> devs mailing list
> > >> devs(a)xwiki.org
> > >> http://lists.xwiki.org/mailman/listinfo/devs
> > >>
> > > _______________________________________________
> > > devs mailing list
> > > devs(a)xwiki.org
> > > http://lists.xwiki.org/mailman/listinfo/devs
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Thomas Mortagne
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
8:32 p.m.
On 17 Jun 2015 at 18:26:46, Guillaume Louis-Marie Delhumeau
(gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
2015-06-17 18:17 GMT+02:00 vincent(a)massol.net :
Yes me too because:
- it reduces the clutter
- it’s the same for NS and ND (only change is the Add Page screen which can be different
based on some config)
- we keep the breadcrumb (and possibly extend it with actions or easy navigation to
siblings and children - See the other thread where this is discussed)
Thanks
-Vincent
On 17 Jun 2015 at 17:59:56, Guillaume Louis-Marie
Delhumeau (
gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
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. 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, vincent(a)massol.net
> > > 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 (enygma2002(a)gmail.com
> (mailto:
> > > enygma2002(a)gmail.com)) 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 <
> > > >> mariusdumitru.florea(a)xwiki.com> 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, vincent(a)massol.net
> > > >> > >> wrote:
> > > >> > >>
> > > >> > >> >
> > > >> > >> >
> > > >> > >> >
> > > >> > >> >
> > > >> > >> >
> > > >> > >> > On 6 Jun 2015 at 14:20:46, vincent(a)massol.net
(
> > > vincent(a)massol.net
> > > >> > >> (mailto:
> > > >> > >> > vincent(a)massol.net)) wrote:
> > > >> > >> >
> > > >> > >> > > Hi Marius,
> > > >> > >> > >
> > > >> > >> > > On 4 Jun 2015 at 18:16:03, Marius Dumitru
Florea (
> > > >> > >> > mariusdumitru.florea(a)xwiki.com(mailto:
> > > mariusdumitru.florea(a)xwiki.com
> > > >> > ))
> > > >> > >> > 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#HD…
> > > >> > >> > > > . 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
> > > >> > >> > > > >
> > > >> > >> > > > >
18 Jun
18 Jun
12:33 p.m.
So we really need to start deciding what will be the differences from a user POV about the
“Nested Spaces” view and the “Nested Documents” view.
There are 2 possibilities I can think ok.
Assumptions:
- In both cases we assume that by default XE is in “Nested Documents” view when you
install it and that going to the “Nested Spaces” view is an advanced and technical
option.
- In both cases we implement the hiding of WebHome everywhere in the UI by assimilating
WebHome and the Space it’s in.
Option 1
========
Concept: We clearly show the differences between Spaces and Documents in the UI
* Have an checkbox option in the user profile that is named something like “Show the Space
concept”
* Everywhere in the UI where we display spaces (and there are lots of places), we display
them differently than documents. Some examples:
** In the Document Tree the icon used to display spaces is different than the one used to
display documents
** In the Index application we would need to either have 2 tabs: one for Documents and one
for Spaces or a single one but in this case the Livetable column should be named “Document
and Spaces” and both entities should be displayed differently (I’m assuming we want a
single column, see T13
at http://design.xwiki.org/xwiki/bin/view/Proposal/NestedSpaces#HOriginallisto…)
** The Add button would list 2 actions: Add > Page and Add > Space
** In the Main Wiki administration UI we have a “Select Space to Administer” label to
choose the space to administer
** In the Add Page UI we ask the user to select both the document name and the space in
which it’s located
** We can keep the “Space List” on the home page’s dashboard
Option 2
========
Concept: We show Spaces and Documents as similarly as possible in the UI to have the same
UI as much as possible between “Nested Spaces” and “Nested Documents”.
* In the user profile, we would have a checkbox option named something like “Ability to
create several Documents in the same Space”
* Everywhere in the UI we don’t differentiate Spaces and Documents. The same examples as
above would become:
** In the Document Tree we use the same icon (a node icon) to display either spaces or
documents
** In the Index Application, we have a single Document tab and in the Livetable column is
named “Location” (or “Document Names”) and the reference is displayed but without showing
different icons for Spaces or Documents.
** The Add > Space menu entry could be removed and only an Add > Page entry would
stay but when you click on it, you’d still have the ability to create new Spaces.
Basically we ask the user to select both the document name and the space in which it’s
located
** We replace the “Space List” on the home page’s dashboard by a “Document List” widget
(showing both spaces and pages).
In summary, option 2 reduces the difference between Nested Documents and Nested Spaces to
the Add > Page UI.
Pros/Cons
=========
* Option 1:
** Strong difference between Space/Documents in the UI
** Hard to implement: lots of places need to have different behavior depending on whether
the user profile option is turned on or off
** Existing extensions don’t need to be modified to feel natural if you’re in the “Nested
Spaces” mode. However note that since we want to have Nested Documents by default these
extensions must be updated ASAP anyway to reflect that.
* Option 2:
** Smaller difference between Space/Document in the UI
** Easy to implement since the only UI
** Existing extensions may not feel natural (until they’re updated for Nested Documents
but we need to do that anyway)
WDYT? I’m worried that Option 1 is going to be costly to develop and maintain.
Anca, since you were the one who raised this idea of keeping both “Nested Spaces” and
“Nested Documents” in the UI, what’s your POV?
Thanks
-Vincent
On 17 Jun 2015 at 20:32:39, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
On 17 Jun 2015 at 18:26:46, Guillaume Louis-Marie Delhumeau
(gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
2015-06-17 18:17 GMT+02:00 vincent(a)massol.net :
Yes me too because:
- it reduces the clutter
- it’s the same for NS and ND (only change is the Add Page screen which can be different
based on some config)
- we keep the breadcrumb (and possibly extend it with actions or easy navigation to
siblings and children - See the other thread where this is discussed)
Thanks
-Vincent
On 17 Jun 2015 at 17:59:56, Guillaume Louis-Marie
Delhumeau (
gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
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. 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, vincent(a)massol.net
> > > 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 (enygma2002(a)gmail.com
> (mailto:
> > > enygma2002(a)gmail.com)) 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 <
> > > >> mariusdumitru.florea(a)xwiki.com> 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, vincent(a)massol.net
> > > >> > >> wrote:
> > > >> > >>
> > > >> > >> >
> > > >> > >> >
> > > >> > >> >
> > > >> > >> >
> > > >> > >> >
> > > >> > >> > On 6 Jun 2015 at 14:20:46, vincent(a)massol.net
(
> > > vincent(a)massol.net
> > > >> > >> (mailto:
> > > >> > >> > vincent(a)massol.net)) wrote:
> > > >> > >> >
> > > >> > >> > > Hi Marius,
> > > >> > >> > >
> > > >> > >> > > On 4 Jun 2015 at 18:16:03, Marius Dumitru
Florea (
> > > >> > >> > mariusdumitru.florea(a)xwiki.com(mailto:
> > > mariusdumitru.florea(a)xwiki.com
> > > >> > ))
> > > >> > >> > 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#HD…
> > > >> > >> > > > . 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
> > > >> > >> > > > >
> > > >> > >> > > > >
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3431
days inactive
3446
days old
17 comments
6 participants
participants (6)
-
Ecaterina Moraru (Valica) -
Eduard Moraru -
Guillaume "Louis-Marie" Delhumeau -
Marius Dumitru Florea -
Thomas Mortagne -
vincent＠massol.net