On Tue, Jun 23, 2015 at 7:31 PM, Marius Dumitru Florea <[email protected]> wrote: > On Tue, Jun 23, 2015 at 6:43 PM, Ecaterina Moraru (Valica) > <[email protected]> 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 >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
