24 Jun
2015
24 Jun
'15
4:03 p.m.
On Wed, Jun 24, 2015 at 4:55 PM, Eduard Moraru <enygma2002(a)gmail.com> wrote:
Hi,
On Wed, Jun 24, 2015 at 9:28 AM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
should
give
Parent/Child
would
So this idea solve some of the technical problems: like migrations and
keeps the parent/child data, but I think is too complex from the user point
of view.
It will be super magic ... and no one will know what partial path they need
to fix if there is a problem in the hierarchy. Hierarchies should use just
one type of relation in order to be correctly displayed. There might be
some wikis that have the parent/child data created by accident and without
value to the user and we might display it.
Anyway, our main problem is that we don't have enough parent/child relation
usage.
Thanks,
Caty
On 24 Jun 2015 at 07:45:20, vincent(a)massol.net (vincent(a)massol.net
(mailto:
vincent(a)massol.net)) wrote:
>
>
>
>
>
> On 23 Jun 2015 at 17:44:01, Ecaterina Moraru (Valica) (
valicac(a)gmail.com
(mailto:valicac@gmail.com)) wrote:
regarding
> Hi devs,
>
> So after discussing the topic of Nested in several mails, we need to
reach
> a conclusion in order to start
implementing.
>
> There are several open questions that I will summarize. Please cast
your
> votes in order to advance on some topics and
maybe discover what we
still
> > need to agree on.
> >
> > Q0. **Nested Spaces in model**
> >
> > No matter the UI decisions we still need to take, we are implementing
> > Nested Spaces for 7.2 roadmap. The future is still uncertain >
changing the model to accommodate Nested Documents, since we can
simulate
> > ND using NS.
>
> Already decided, +1
>
> > Q1. **NS vs ND in the UI**
> >
> > Q1.1 The majority agreed that since the final purpose are ND, we > > display ND in the UI, since it
simplifies the mental model of the
user.
This implies removing the Space concept from the UI.
Already decided, +1
Q1.1.1 A consequence is hiding the
'WebHome' name in the UI.
Already decided, +1
> Q1.2 Although the default should be ND, the question is if we want to > the option to display NS in the UI. This
would be implemented as an
> advanced and technical option. The main problem is that we might need
to
> provide UI alternatives for several
components (menus, create step,
etc.)
-0 but would like to have Anca’s opinion on the related thread.
one has to
go away and since we’ve agreed on NS, it has to be Q2. **Parent/Child**
Q2.1 Deprecate the notion of Parent/Child.
+1 because it’s too confusing to have both the NS and Parent/Child so going away.
>
> Note that deprecating doesn’t mean removing it! It just tells users
that
they need to move away from it over time as it’s
no longer the way to do
it.
> Q2.1.1 Provide a migration to transform the relation into NS/ND.
Problem:
> the old URLs[A] (bookmarks) are broken + the
user is stuck with long
> URLs[B] if he wants to keep the hierarchy. Additionally we might need
to
> provide an extension/configuration to
transform into short URLs [B ->
C].
+1, we need to help users migrate from Parent/Child to NS anyway since
we’ve
agreed about NS. However this is not au automated migration; it be some scripts that users can run if they want
to.
create
> Q2.1.2 Don't migrate: the parent/child hierarchy will be lost but the
old
> > URLs[A] (bookmarks) will be kept. The user needs to use NS/ND to > > hierarchies.
> >
> > Q2.2 Don't deprecate the notion of Parent/Child.
>
> -0 as I said it’s too confusing to have both at the same time and we
can
only have 1 breadcrumb at a time!
>
> > Q2.2.1 Provide a configuration in the Administration to switch the
> > breadcrumbs between displaying Parent/Child or NS/ND. We might need
to
> > provide UI alternatives for several
components (tree, breadcrumb
> > navigation, create, etc.)
>
> +1 to let users time to migrate.
>
> I don’t agree with the reasoning of “let’s keep parent/child and have
NS
at the same time”. It’s just too confusing and
we’ll need to fix this
before we can consider the feature finished anyway (like having a
breadcrumb based on NS).
The problem with having the breadcrumb based on parent/child is that when
you create a new document inside a nested space and you save you see an
empty breadcrumb and you have to set the parent explicitly thus
duplicating
the effort.
One idea to help with this could be to use NS in the breadcrumb when the
current doc doesn’t have any parent set. This would let users migrate
more
smoothly, although it could increase confusion.
To help, we could display
two different icons in the breadcrumb to show when it’s based on NS and
when it’s based on Parent/Child.
If I understood your intent correctly, this was one of the first ideas I
discussed with Caty as well. Basically, the highlights were:
1. Do not migrate
** => Preserves URLs
** => Preserves existing internal hierarchy/structure
2. Change the way breadcrumbs work by rebranding the "parent-child"
relationship to "parent override"
** By default, we show the NS path in the breadcrumbs, but still allow
setting a parent (in edit mode) to be able to override the breadcrumbs.
*** This allows existing (not migrated) documents to keep their breadcrumbs
that were created only with parent-child
*** New documents go with the default but, if the user really wants to, he
can short-circuit the displayed breadcrumbs by setting a parent override
*** The downside of this is that the work needed to display the breadcrumbs
will be a bit more costly, since we need to consider path overrides when
walking up the path hierarchy, for each element of the path, while also
avoiding possible cycles.
**** E.g: X > Y > B > C is computed by looking at C's parent. If it is not
set, walk up the path hierarchy to B (C's space in NS or C's parent
document in ND). For B, look at its parent. If it is set to (Y), display
it. Now look at Y's parent, which is not set so walk up Y's path hierarchy
and reach and display X. In this example, C's full path was A.B.C, meaning
that B's parent override (Y) has overridden the breadcrumbs of C from A>B>C
(based only on the path/NS) to X>Y>B>C (computed from path + parent
override).
*** The second downside of this is that, for an app, it becomes more
complicated to get the parent of a document. Which parent does it get, the
path parent or the user-percieved parent (which includes overrides and
which are costly to compute?).
From a user's POV, it`s quite a nice compromise, specially when considering
upgrades/migrations. It might also be interesting from a technical POV, but
I`ll let you be the judges of that.
You can also see this as a breadcrumbs customization tool that has the
added benefit that it solves the migration issues. You can also see it as
an option (parent editing) that is disabled by default, but can be enabled
by admins that are migrating.
Just detailing it to better see the implications of this approach.
Thanks,
Eduard
Thanks
-Vincent
NS
I’m fine to do it later in 7.2 but IMO it has to be done un 7.2 because
we don’t
want *new* users to start using parent/child relationship once is implemented.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
We have to bite the bullet and better sooner than later.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
Please cast your votes / add comments.
Thank you,
Caty
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs