Hi Marius and all, On 25 Jun 2015 at 08:19:22, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote: [snip]

...

...

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?

Since we can have extensions or scripts/code that create non-WebHome documents, I think it would be interesting to have the ability to do so in the UI but only for advanced users. I think I’d be in favor of doing the following: * When the user is an advanced user, in the Add > Page UI, have a checkbox entitled something like “Create a page without children” and when the user selects it and save, a document with the name entered will be created instead of a space and a WebHome.

...

B) Do we display differently the WebHome documents from the non-WebHome documents in the UI? 

I don’t think we need to display them differently, except maybe to show that one has children while the other doesn’t have children (terminal leaf vs node).

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)? 

Yes

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?

I don’t think we need to display them differently. The only main place where we need to show a difference IMO is in the Add Page UI: when a user wants to create a new page under a non-WebHome document, we simply display a warning saying that this page is a special page that cannot have children. In other words in the documentation we say that there are 2 types of pages in XWiki: * Terminal pages which cannot have children. We can also explain how these came to be historically. * Normal pages that can have children.

The users will ask why they can't add children to these (non-WebHome) pages. How do we explain this to non-technical users? 

Indeed, see above for an idea on how to handle this.

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. 

Good point. We could add a check in the Add > Page UI to prevent this.

Now what page does the user get when he loads the URL /bin/view/AppData/SomePage ? 

It’s up to us to decide but I guess the most logical is to get AppData.SomePage since otherwise there would be no way to access it from the UI.

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). 

I agree that we should add a check to prevent the creation of such pages from the UI. If it’s done by script then I don’t think we should prevent it. WDYT? [snip] Thanks -Vincent

I’ve spoken with Anca and here’s her opinion (barring any misunderstand from my part ;)): * She mentioned we should talk about Terminal Pages (i.e. no children) vs Non Terminal Pages, in term of terminology * Our UI must handle Terminal Pages as well as non Terminal Pages, i.e. we need to generify all our UIs to handle this. This is very important to Anca * The UI to create a new page should have an advanced option to be able to create a Terminal Page. She said she agree to link this feature to the Advanced User profile (for now, maybe it would be interesting to have it as an option like “hidden documents” later on). * She said we should provide a script to let users transform their existing pages from A/B into A/B/WebHome  * She said we probably don’t need to work on a script to convert parent/child relationship into Nested Documents since this change could cause existing apps to not work properly and for her this is an action that has be done manually on a per wiki basis depending on the usage, etc. * She said from her POV the Parent/child relationship is not used much by users on projects she’s been on and she’s seen this used by her or other devs when building apps and that these app will just have to be modified * She said we should be careful to not change the structure of current apps in XE for the moment since that could break some extensions/bookmarks. Personally I believe we shouldn’t relocate pages in the 7.x timeframe and when we do so (in 8.x probably) we should probably think about implementing aliases before to handle the move. * She agrees we should move the breadcrumb/index tree/etc to use Nested Documents and not be based on the parent/child anymore. She agrees having an option to put it back on if needed is good enough. However the field in the DB should stay for now. To sum up: Q0: +1 Q1, Q1.1, Q1.1.1: +1 with the proviso of having a UI that displays as well Terminal pages from non Terminal pages Q1.2: +1 provided we can create terminal pages from the UI Q2.1: +1 (but keep the parent field in the DB) Q2.1.1: -1 Q2.1.2: +1 Q2.2: -0 Q2.2.1: -0 (not really needed in her opinion) @Anca: please correct me if I’ve wrongly expressed what we discussed ;) Thanks -Vincent On 25 Jun 2015 at 15:16:57, Eduard Moraru ([email protected]) wrote: Hi, On Thu, Jun 25, 2015 at 11:59 AM, [email protected] <[email protected]> wrote:

Hi Marius and all,

On 25 Jun 2015 at 08:19:22, Marius Dumitru Florea ( [email protected](mailto:[email protected])) wrote:

[snip]

...

...

...

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?

Since we can have extensions or scripts/code that create non-WebHome documents, I think it would be interesting to have the ability to do so in the UI but only for advanced users.

I think I’d be in favor of doing the following:

* When the user is an advanced user, in the Add > Page UI, have a checkbox entitled something like “Create a page without children” and when the user selects it and save, a document with the name entered will be created instead of a space and a WebHome.

...

...

B) Do we display differently the WebHome documents from the non-WebHome documents in the UI?

I don’t think we need to display them differently, except maybe to show that one has children while the other doesn’t have children (terminal leaf vs node).

...

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)?

Yes

...

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?

I don’t think we need to display them differently. The only main place where we need to show a difference IMO is in the Add Page UI: when a user wants to create a new page under a non-WebHome document, we simply display a warning saying that this page is a special page that cannot have children.

In other words in the documentation we say that there are 2 types of pages in XWiki: * Terminal pages which cannot have children. We can also explain how these came to be historically. * Normal pages that can have children.

...

The users will ask why they can't add children to these (non-WebHome) pages. How do we explain this to non-technical users?

Indeed, see above for an idea on how to handle this.

...

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.

Good point. We could add a check in the Add > Page UI to prevent this.

...

Now what page does the user get when he loads the URL /bin/view/AppData/SomePage ?

It’s up to us to decide but I guess the most logical is to get AppData.SomePage since otherwise there would be no way to access it from the UI.

...

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).

I agree that we should add a check to prevent the creation of such pages from the UI. If it’s done by script then I don’t think we should prevent it.

I`ve asked that same question 1 week ago [1] but put it more in the light of a security issue, since one could perform a denial-of-service-like attack or a phishing-like attack on a ND by "masking" it with a simple document that would high-jack existing URLs. Also, don`t forget that if for a user we can make the difference unnoticeable, for devs it will make life harder, since they need to query for 2 types of documents in their code. DB queries are even more sensitive to this, when, for example, you want to get all the immediate children of a document. They can be simple documents (documents in the space defined by the) or ND (WebHomes of subspaces), not o mention the issues of manipulating the space (path string) in order to get obtain this information. Thanks, Eduard [1] http://xwiki.475771.n2.nabble.com/Proposal-Introduce-the-notion-of-Nested-Do...

WDYT?

[snip]

Thanks -Vincent

  On 26 Jun 2015 at 18:26:11, [email protected] ([email protected](mailto:[email protected])) wrote:

One item we haven’t discussed here again (it was discussed in some other thread) are the Permissions.

When we have ND, we need to decide how to set permissions for a non-terminal page.

Here’s what I propose:

* Remove the current “Edit Rights” menu entry and replace that with an “Administer page” menu entry, see http://design.xwiki.org/xwiki/bin/view/Improvements/PageAdministration . Ask for Admin rights to be able to go to the admin UI. * When on a non-terminal page (i.e. a WebHome page), go to the “Space” Admin UI when clicking “Administer page” * When on a terminal page, go to the Page Admin UI (http://design.xwiki.org/xwiki/bin/view/Improvements/PageAdministration) when clicking “Administer page” * Add a, xobject listener (or some other way) to prevent users without admin rights to be able to add a Rights XObject

Note that one use case that would be nice to support is the following: * You create a page A * Some other persons create pages B, C, having your page A as parent * You change the permissions on page A to allow only yourself to view it (or edit it) * Suddenly people who had the rights to view or edit pages B and C don’t have them anymore.

OTOH with my proposal above you wouldn’t be anymore to have private pages (unless you have Admin permissions). Is this acceptable? If not, do you have a counter proposal? 

A counter proposal would be to introduce a Permissions to control Permissions. This is probably what would be the more flexible and would allow for all use cases. Thanks -Vincent

Thanks -Vincent

On 26 Jun 2015 at 13:44:29, [email protected] ([email protected](mailto:[email protected])) wrote:

...

I’ve spoken with Anca and here’s her opinion (barring any misunderstand from my part ;)):

* She mentioned we should talk about Terminal Pages (i.e. no children) vs Non Terminal Pages, in term of terminology * Our UI must handle Terminal Pages as well as non Terminal Pages, i.e. we need to generify all our UIs to handle this. This is very important to Anca * The UI to create a new page should have an advanced option to be able to create a Terminal Page. She said she agree to link this feature to the Advanced User profile (for now, maybe it would be interesting to have it as an option like “hidden documents” later on). * She said we should provide a script to let users transform their existing pages from A/B into A/B/WebHome * She said we probably don’t need to work on a script to convert parent/child relationship into Nested Documents since this change could cause existing apps to not work properly and for her this is an action that has be done manually on a per wiki basis depending on the usage, etc. * She said from her POV the Parent/child relationship is not used much by users on projects she’s been on and she’s seen this used by her or other devs when building apps and that these app will just have to be modified * She said we should be careful to not change the structure of current apps in XE for the moment since that could break some extensions/bookmarks. Personally I believe we shouldn’t relocate pages in the 7.x timeframe and when we do so (in 8.x probably) we should probably think about implementing aliases before to handle the move. * She agrees we should move the breadcrumb/index tree/etc to use Nested Documents and not be based on the parent/child anymore. She agrees having an option to put it back on if needed is good enough. However the field in the DB should stay for now.

To sum up:

Q0: +1 Q1, Q1.1, Q1.1.1: +1 with the proviso of having a UI that displays as well Terminal pages from non Terminal pages Q1.2: +1 provided we can create terminal pages from the UI Q2.1: +1 (but keep the parent field in the DB) Q2.1.1: -1 Q2.1.2: +1 Q2.2: -0 Q2.2.1: -0 (not really needed in her opinion)

@Anca: please correct me if I’ve wrongly expressed what we discussed ;)

Thanks -Vincent

On 25 Jun 2015 at 15:16:57, Eduard Moraru ([email protected](mailto:[email protected])) wrote:

...

Hi,

On Thu, Jun 25, 2015 at 11:59 AM, [email protected] wrote:

...

Hi Marius and all,

On 25 Jun 2015 at 08:19:22, Marius Dumitru Florea ( [email protected](mailto:[email protected])) wrote:

[snip]

...

...

> 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?

Since we can have extensions or scripts/code that create non-WebHome documents, I think it would be interesting to have the ability to do so in the UI but only for advanced users.

I think I’d be in favor of doing the following:

* When the user is an advanced user, in the Add > Page UI, have a checkbox entitled something like “Create a page without children” and when the user selects it and save, a document with the name entered will be created instead of a space and a WebHome.

...

...

B) Do we display differently the WebHome documents from the non-WebHome documents in the UI?

I don’t think we need to display them differently, except maybe to show that one has children while the other doesn’t have children (terminal leaf vs node).

...

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)?

Yes

...

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?

I don’t think we need to display them differently. The only main place where we need to show a difference IMO is in the Add Page UI: when a user wants to create a new page under a non-WebHome document, we simply display a warning saying that this page is a special page that cannot have children.

In other words in the documentation we say that there are 2 types of pages in XWiki: * Terminal pages which cannot have children. We can also explain how these came to be historically. * Normal pages that can have children.

...

The users will ask why they can't add children to these (non-WebHome) pages. How do we explain this to non-technical users?

Indeed, see above for an idea on how to handle this.

...

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.

Good point. We could add a check in the Add > Page UI to prevent this.

...

Now what page does the user get when he loads the URL /bin/view/AppData/SomePage ?

It’s up to us to decide but I guess the most logical is to get AppData.SomePage since otherwise there would be no way to access it from the UI.

...

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).

I agree that we should add a check to prevent the creation of such pages from the UI. If it’s done by script then I don’t think we should prevent it.

I`ve asked that same question 1 week ago [1] but put it more in the light of a security issue, since one could perform a denial-of-service-like attack or a phishing-like attack on a ND by "masking" it with a simple document that would high-jack existing URLs.

Also, don`t forget that if for a user we can make the difference unnoticeable, for devs it will make life harder, since they need to query for 2 types of documents in their code. DB queries are even more sensitive to this, when, for example, you want to get all the immediate children of a document. They can be simple documents (documents in the space defined by the) or ND (WebHomes of subspaces), not o mention the issues of manipulating the space (path string) in order to get obtain this information.

Thanks, Eduard

[1] http://xwiki.475771.n2.nabble.com/Proposal-Introduce-the-notion-of-Nested-Do...

...

WDYT?

[snip]

Thanks -Vincent

On Sat, Jun 27, 2015 at 10:51 AM, [email protected] <[email protected]> wrote:

On 27 Jun 2015 at 10:29:00, [email protected] ([email protected](mailto: [email protected])) wrote:

...

On 26 Jun 2015 at 18:26:11, [email protected] ([email protected] (mailto:[email protected])) wrote:

...

One item we haven’t discussed here again (it was discussed in some other thread) are the Permissions.

When we have ND, we need to decide how to set permissions for a non-terminal page.

Here’s what I propose:

* Remove the current “Edit Rights” menu entry and replace that with an “Administer page” menu entry, see http://design.xwiki.org/xwiki/bin/view/Improvements/PageAdministration . Ask for Admin rights to be able to go to the admin UI. * When on a non-terminal page (i.e. a WebHome page), go to the “Space” Admin UI when clicking “Administer page” * When on a terminal page, go to the Page Admin UI ( http://design.xwiki.org/xwiki/bin/view/Improvements/PageAdministration) when clicking “Administer page”

Sorry, but either I do not understand or it looks too complicated for end users.

...

...

* Add a, xobject listener (or some other way) to prevent users without admin rights to be able to add a Rights XObject

I am convince that we should rely on the current model, and the current abilities of the model to provide a proper security solution. If we start using tricks, it is the open door for security holes.

...

...

Note that one use case that would be nice to support is the following: * You create a page A * Some other persons create pages B, C, having your page A as parent * You change the permissions on page A to allow only yourself to view

it (or edit it)

...

* Suddenly people who had the rights to view or edit pages B and C don’t have them anymore.

Not necessarily true, since we have the CREATOR right, which actually only implies DELETE at document level and undeniable, we may surely extend it to also implies VIEW and EDIT, so it given creator a more consistant right on their own page. Now if that document is non-terminal, the global rights that we set on it will still depends on WebPreferences, and actually those documents are not editable by non-admin users.

...

...

OTOH with my proposal above you wouldn’t be anymore to have private

pages (unless you have Admin permissions). Is this acceptable? If not, do you have a counter proposal?

This already what we have with spaces, user are not able to create private spaces unless these user are admins. This could be seen an unacceptable limitation, but counter proposal need thorough reflexion and I am not sure it is the right time of it at the moment.

...

A counter proposal would be to introduce a Permissions to control

Permissions. This is probably what would be the more flexible and would allow for all use cases.

We would still need to decide if we want to use the page level permission or the space level one when on a non-terminal page. Ideally it should be the space level UI IMO since it has more features (hence my initial proposal above). However, since we may want to retain the ability for a user to edit permissions, we could allow users with the “Permission” permission to go to that Admin page but only be able to modify permissions while requiring Admin permissions to modify the other options of that page.

I really do not like such change. If we would go for it, I would use separate documents to store objects that needs different levels of access. So this could means extracting global rights objects into another document than WebPreferences, and allowing EDIT rights to those that are allowed to edit permissions. Once again, I will be very careful with any proposal that do not exploit the actual model and security module to complete right purposes, since, this has been prove bad in the past.

WDYT?

I am sorry not to have more time at the moment for a complete counter proposal, but I hope the above remarks will be helpful. Thanks, -- Denis Gervalle SOFTEC sa - CEO

On 24 Jun 2015 at 07:45:20, [email protected] ([email protected](mailto:[email protected])) wrote:

On 23 Jun 2015 at 17:44:01, Ecaterina Moraru (Valica) ([email protected](mailto:[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**

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.

Already decided, +1

...

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.

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 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.)

-0 but would like to have Anca’s opinion on the related thread.

...

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 one has to go away and since we’ve agreed on NS, it has to be Parent/Child 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 would be some scripts that users can run if they want to.

...

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.

-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. Thanks -Vincent

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 NS is implemented.

We have to bite the bullet and better sooner than later.

Thanks -Vincent

...

Please cast your votes / add comments.

Thank you, Caty

---

devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Wed, Jun 24, 2015 at 4:55 PM, Eduard Moraru <[email protected]> wrote:

Hi,

On Wed, Jun 24, 2015 at 9:28 AM, [email protected] <[email protected]> wrote:

...

On 24 Jun 2015 at 07:45:20, [email protected] ([email protected]

(mailto:

...

[email protected])) wrote:

...

On 23 Jun 2015 at 17:44:01, Ecaterina Moraru (Valica) (

[email protected] (mailto:[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**

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.

Already decided, +1

...

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.

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 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.)

-0 but would like to have Anca’s opinion on the related thread.

...

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 one has to go away and since we’ve agreed on NS, it has to be Parent/Child 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 would be some scripts that users can run if they want to.

...

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.

-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.

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

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

...

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 NS is implemented.

...

We have to bite the bullet and better sooner than later.

Thanks -Vincent

...

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

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

Hello, Here are my votes: Q0: +1 Q1.1: +1 Q1.1.1: +0 Q1.2: -0 Q2.1: -1 Q2.1.1: -1 Q2.1.2: +0 Q2.2: +1 Q2.2.1: +0 Thanks, Gabriela *Gabriela Smeria* *Web Developer* [email protected] skype: smeria.gabriela On Wed, Jun 24, 2015 at 3:41 PM, Ecaterina Moraru (Valica) < [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**

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.

+1

...

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.)

-0 We would need to create UI alternatives for several components. This means additional work for a feature that will be used by very few people, but we would need to assure the testing of it. I think removing Space as a concept from the UI will simplify the concepts. Extensions can be custom developed and added in e.x.o, but I don't see why we should provide the configuration by default.

...

Q2. **Parent/Child**

So apparently this is the main problem we still need to decide. The issue is that maybe we have different definitions on the word 'deprecate'.

...

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].

-1 I don't agree to make this kind of migration automatically for all users. As Vincent said maybe we could provide some optional script, but not sure about that either.

...

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. 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.)

-0 IMO this is not something that can be done very easy. With the current UI proposal, if we replace the NS/ND hierarchy with the Parent/Child, and without the global menu, the user will not know it's location (except by looking at the URL). How will he navigate to its current wiki or space? Magic like have a fallback on NS if Parent/Child is empty, will confuse the user and won't provide additional insight.

So IMO there are 2 ways to view the Parent/Child deprecation: 1. If we think only about Nested Documents, than the answer is straight forward. Just deprecate the Parent/Child. There is no need to have 2 concepts that do the same thing.

2. If we think about the long URL then the problem is a bit different. If we deprecate the Parent/Child and we will want to switch to an ID implementation and move the hierarchy to another metadata, than the deprecation of Parent/Child field mean a step backwards towards this direction.

What I know about 1) and Parent/Child is that: We shouldn't display both concepts in the UI. This means the breadcrumbs will display the NS/ND, but the Parent/Child data would still be preserved in the database for backwards compatibility reasons. If someone used the Parent/Child concept, he should develop additional extensions to present this information. But at least the Parent/Child field will not be removed / reused / transformed automatically in URLs.

So I guess I'm voting +1 to Q2.2 Don't deprecate the notion of Parent/Child: a.k.a do not consider it totally deprecated, but we should NOT display it in the UI for the NS/ND implementation. Not sure if it makes sense.

Thanks, Caty

...

Please cast your votes / add comments.

Thank you, Caty

_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

On Wed, Jul 1, 2015 at 11:41 AM, Marius Dumitru Florea < [email protected]> wrote:

On Fri, Jun 26, 2015 at 7:48 PM, Ecaterina Moraru (Valica) <[email protected]> wrote:

...

Hi,

Some conclusions with the current votes:

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 regarding changing the model to accommodate Nested Documents, since we can

simulate

...

ND using NS.

7 x (+1) 'Already decided'

...

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.

7 x (+1) 'Already decided'

...

Q1.1.1 A consequence is hiding the 'WebHome' name in the UI.

6 x (+1) , 1 x (+0) 'Already decided'

...

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.)

6 x (-0) -> so we will not give an additional option to display NS in the UI (see Terminal Pages)

...

Q2. **Parent/Child**

Parent/Child deprecation is a bit more difficult to calculate, since the votes are mixed depending on the definition of 'deprecation', not clearly stated the vote or given partially votes.

The conclusion is that in order not to confuse the user, we should deprecate the P/C concept. It will not be dropped from the DB (and will be available if someone wants to create additional extensions to display it), but it will not be displayed by default in the UI, since breadcrumbs/trees will display the ND.

...

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.

The 'migration' got: 3 x (-1) 1 x (-0) 1 x (+1)

Don't 'migrate' got: 2 x (+1) 2 x (+0)

The general feeling is that we don't need to provide such a migration automatically. Script could be put into place (to transform P/C into ND), but this should be applied on a case by case scenario.

Other needed script is in order to transform the existing pages from A/B into A/B/WebHome.

...

Q2.2 Don't deprecate the notion of Parent/Child. 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.)

Configuration between P/C and NS/ND: 4 x (-0) 1 x (+0) 1 x (+1)

The general feeling is that this is not needed. There could be an option from UI/config to turn the P/C relation on, but it would be off by default.

Q3. **Terminal Pages**

Since we will have 'Terminal Pages' and 'Non Terminal Pages', it was proposed to have an option in the Profile or associate this behavior with the Advanced user role, in order to display a checkbox ('Create a page without children') in the 'Create Page' step.

Additional, for the users that have this checkbox selected, if they land on a non existing page, instead of being transferred directly into Edit mode, when they click 'You can edit this page to create it', they will be directed to the 'Create Page' step, in order to be able to select the 'Create a page without children' checkbox. (Use case mentioned by Vincent).

...

Terminal and Non Terminal pages will be displayed in the Tree, by having associated an expand icon or not.

This is not enough / right. There's a difference between pages that don't have child documents (currently) and pages that can't have child documents (because they don't support it).

Currently I see 2 solutions: - Instead of '+' symbol we could have like a new icon, a terminal icon, something like 'ꜜ' in order to differentiate between the 2 types; - Or for non-terminal pages, we can display the '+' icon and when expanding have an 'Add child' link;

...

Maybe there are other ideas regarding 'Terminal Pages'?

Please let me know if I summarized correctly and if others want to cast additional votes.

Thanks, 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