8 Jun
2015
8 Jun
'15
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)