25 Jun
2015
25 Jun
'15
8:19 a.m.
On Tue, Jun 23, 2015 at 7:31 PM, Marius Dumitru Florea
<mariusdumitru.florea(a)xwiki.com> wrote:
On Tue, Jun 23, 2015 at 6:43 PM, Ecaterina Moraru
(Valica)
<valicac(a)gmail.com> wrote:
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**
+1
No matter the UI decisions we still need to take, we are implementing
Nested Spaces for 7.2 roadmap. The future is still uncertain regarding
changing the model to accommodate Nested Documents, since we can simulate
ND using NS.
Q1. **NS vs ND in the UI**
Q1.1 The majority agreed that since the final
purpose are ND, we should
display ND in the UI, since it simplifies the mental model of the user.
This implies removing the Space concept from the UI.
+1
Q1.1.1 A consequence is hiding the
'WebHome' name in the UI.
+1
Q1.2 Although the default should be ND, the question is if we want to give
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.)
There are 2 questions actually:
A) Do we want to support creating non-WebHome documents from the UI?
B) Do we display differently the WebHome documents from the
non-WebHome documents in the UI?
No comments on these questions? There are two important use cases:
* a wiki that has custom code (Velocity/Groovy) in (non-WebHome) wiki
pages is upgraded to 7.2+ (with nested documents)
* an admin installs an extension with non-WebHome pages in XWiki 7.2+
(with nested documents)
In both cases we cannot migrate the non-WebHome pages because it will
break the code. So they have to stay. Do we show these pages in the
document index (livetable / tree)? Note that these are not necessarily
technical (hidden) pages. They can be data pages created/managed by an
application/extension (whose code expects non-WebHome documents). Do
we display them differently than the WebHome (nested) documents? The
users will ask why they can't add children to these (non-WebHome)
pages. How do we explain this to non-technical users?
Moreover, since both WebHome and non-WebHome documents must coexist,
what happens when one hides the other. E.g. an old application has
created (through code) some data page AppData.SomePage; an user sees
the "AppData" document (it's not a space anymore, it's actually
AppData.WebHome) and adds a child (nested) document with the same name
SomePage which actually creates AppData.SomePage.WebHome under the
hood. Now what page does the user get when he loads the URL
/bin/view/AppData/SomePage ? The WebHome or the non-WebHome
(application) page? In any case, some users will not get the expected
page. Moreover, which page should be indexed by Solr, the WebHome or
the non-WebHome with the "same" name? If we index both then the users
will complain they get "duplicate" results (with possible different
highlights), and the result links will open the same document (which
one we choose to make accessible, probably the WebHome one).
Q2. **Parent/Child**
Q2.1 Deprecate the notion of Parent/Child.
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].
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 create
hierarchies.
Q2.2 Don't deprecate the notion of Parent/Child.
+1, I agree with Thomas.
> 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.)
>
> Please cast your votes / add comments.
>
> Thank you,
> Caty
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs