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