On 28 Sep 2015 at 09:25:51, Thomas Mortagne ([email protected](mailto:[email protected])) wrote:

Be careful with theses rules since they are not only for xwiki-platform but also for contrib application and it should be made clear that this is only for an application that require 7.2 or more which is really not a good idea for a new contrib extension.

Yes, good point, we should mention that this applies only when you depend on XWiki 7.2+. Note that this is already covered by this rule: "In your POM always try to depend on the oldest version of commons/rendering/platform dependencies for which your code works. At least ensure that your Applications works on the latest LTS version of XWiki. This will allow the largest number of users to use your application.” Thanks -Vincent

On Sun, Sep 27, 2015 at 9:19 PM, [email protected] wrote:

...

Hi devs,

Following our implementation of NS/NP in 7.2 I’d like to propose 2 new best practices for app dev that we would list at http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...

1) New rule 1: “Code” subspace

Current text: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations.

New version: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations. * Technical pages should be put in a subspace named “Code”

Note: this rule can only be applied for new applications for now since the EM doesn’t know how to follow renames currently so for example if I move pages from the FAQCode space to the FAQ.Code space, when EM upgrades the app, it’ll display all pages in FAQCode as deleted (basically it considers all pages in FAQ.Code as new pages and pages in FAQCode as deleted pages). Note: I’ve created http://jira.xwiki.org/browse/XWIKI-12622 for this.

2) New rule 2:

* Technical pages without children must be terminal pages.

WDYT?

Thanks -Vincent

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

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

On 28 Sep 2015 at 10:06:52, Thomas Mortagne ([email protected](mailto:[email protected])) wrote:

Also before making this a rule we should probably refactor AWM first since it's more and more the base for many new applications.

Yes. I don’t think we need to wait to agree on what we want to have. The wait is only needed to decide when to apply the rule but we could decide the rule before applying it. Regarding AWM it’s planned for 7.3 (I talked about it with Marius a few days ago). I don’t know if we have a jira issue already but we should create one. Thanks -Vincent Ps: You haven’t said whether you agree with these rules (independently of when we would apply them) :)  

On Mon, Sep 28, 2015 at 9:55 AM, [email protected] wrote:

...

On 28 Sep 2015 at 09:25:51, Thomas Mortagne ([email protected](mailto:[email protected])) wrote:

...

Be careful with theses rules since they are not only for xwiki-platform but also for contrib application and it should be made clear that this is only for an application that require 7.2 or more which is really not a good idea for a new contrib extension.

Yes, good point, we should mention that this applies only when you depend on XWiki 7.2+.

Note that this is already covered by this rule:

"In your POM always try to depend on the oldest version of commons/rendering/platform dependencies for which your code works. At least ensure that your Applications works on the latest LTS version of XWiki. This will allow the largest number of users to use your application.”

Thanks -Vincent

...

On Sun, Sep 27, 2015 at 9:19 PM, [email protected] wrote:

...

Hi devs,

Following our implementation of NS/NP in 7.2 I’d like to propose 2 new best practices for app dev that we would list at http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...

1) New rule 1: “Code” subspace

Current text: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations.

New version: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations. * Technical pages should be put in a subspace named “Code”

Note: this rule can only be applied for new applications for now since the EM doesn’t know how to follow renames currently so for example if I move pages from the FAQCode space to the FAQ.Code space, when EM upgrades the app, it’ll display all pages in FAQCode as deleted (basically it considers all pages in FAQ.Code as new pages and pages in FAQCode as deleted pages). Note: I’ve created http://jira.xwiki.org/browse/XWIKI-12622 for this.

2) New rule 2:

* Technical pages without children must be terminal pages.

WDYT?

Thanks -Vincent

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

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

---

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

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

On 28 Sep 2015 at 10:28:45, Thomas Mortagne ([email protected](mailto:[email protected])) wrote:

I agree with this best practice at some point yes.

We need to agree on these 2 practices before we can implement it in AWM anyway :) Thanks -Vincent

On Mon, Sep 28, 2015 at 10:21 AM, [email protected] wrote:

...

On 28 Sep 2015 at 10:06:52, Thomas Mortagne ([email protected](mailto:[email protected])) wrote:

...

Also before making this a rule we should probably refactor AWM first since it's more and more the base for many new applications.

Yes.

I don’t think we need to wait to agree on what we want to have. The wait is only needed to decide when to apply the rule but we could decide the rule before applying it.

Regarding AWM it’s planned for 7.3 (I talked about it with Marius a few days ago). I don’t know if we have a jira issue already but we should create one.

Thanks -Vincent

Ps: You haven’t said whether you agree with these rules (independently of when we would apply them) :)

...

On Mon, Sep 28, 2015 at 9:55 AM, [email protected] wrote:

...

On 28 Sep 2015 at 09:25:51, Thomas Mortagne ([email protected](mailto:[email protected])) wrote:

...

Be careful with theses rules since they are not only for xwiki-platform but also for contrib application and it should be made clear that this is only for an application that require 7.2 or more which is really not a good idea for a new contrib extension.

Yes, good point, we should mention that this applies only when you depend on XWiki 7.2+.

Note that this is already covered by this rule:

"In your POM always try to depend on the oldest version of commons/rendering/platform dependencies for which your code works. At least ensure that your Applications works on the latest LTS version of XWiki. This will allow the largest number of users to use your application.”

Thanks -Vincent

...

On Sun, Sep 27, 2015 at 9:19 PM, [email protected] wrote:

...

Hi devs,

Following our implementation of NS/NP in 7.2 I’d like to propose 2 new best practices for app dev that we would list at http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...

1) New rule 1: “Code” subspace

Current text: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations.

New version: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations. * Technical pages should be put in a subspace named “Code”

Note: this rule can only be applied for new applications for now since the EM doesn’t know how to follow renames currently so for example if I move pages from the FAQCode space to the FAQ.Code space, when EM upgrades the app, it’ll display all pages in FAQCode as deleted (basically it considers all pages in FAQ.Code as new pages and pages in FAQCode as deleted pages). Note: I’ve created http://jira.xwiki.org/browse/XWIKI-12622 for this.

2) New rule 2:

* Technical pages without children must be terminal pages.

WDYT?

Thanks -Vincent

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

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

---

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

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

---

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

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

Well, I have not yet look in details the new features for page manipulation, but I was wondering if there will be a simple way to delete application data without deleting the application itself with the model you propose ? I know there is already issue with that about the WebHome which is usually an entry point to the application, but deleting a space was possible. If the code is nested under the data, isn't it an issue. It looks like the opposite of the general way (not xwiki way, but in application in general), where the code abstract more or less the location of the data and is the "main" part. So, I am not sure actually, that this is the best way. Maybe code and data should be side by side under a entry point documents ? On Wed, Sep 30, 2015 at 8:22 AM, [email protected] <[email protected]> wrote:

Ping! There’s only Thomas and Gaby who answered so far :)

Thanks -Vincent

On 27 Sep 2015 at 21:19:43, [email protected] ([email protected]) wrote:

Hi devs,

Following our implementation of NS/NP in 7.2 I’d like to propose 2 new best practices for app dev that we would list at http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...

1) New rule 1: “Code” subspace

Current text: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations.

New version: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations. * Technical pages should be put in a subspace named “Code”

Note: this rule can only be applied for new applications for now since the EM doesn’t know how to follow renames currently so for example if I move pages from the FAQCode space to the FAQ.Code space, when EM upgrades the app, it’ll display all pages in FAQCode as deleted (basically it considers all pages in FAQ.Code as new pages and pages in FAQCode as deleted pages). Note: I’ve created http://jira.xwiki.org/browse/XWIKI-12622 for this.

2) New rule 2:

* Technical pages without children must be terminal pages.

WDYT?

Thanks -Vincent

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

-- Denis Gervalle SOFTEC sa - CEO

Hi 2015-09-30 10:22 GMT+02:00 [email protected] <[email protected]>:

Hi Denis,

On 30 Sep 2015 at 09:49:28, Denis Gervalle ([email protected](mailto: [email protected])) wrote:

...

Well, I have not yet look in details the new features for page manipulation, but I was wondering if there will be a simple way to delete application data without deleting the application itself with the model you propose ? I know there is already issue with that about the WebHome which is usually an entry point to the application, but deleting a space was possible. If the code is nested under the data, isn't it an issue. It looks like the opposite of the general way (not xwiki way, but in application in general), where the code abstract more or less the location of the data and is the "main" part.

So, I am not sure actually, that this is the best way. Maybe code and data should be side by side under a entry point documents ?

You mean something like:

MyApp |_ Data/ |_ Code/ |_ WebHome

(Instead of leaving it free for apps to decide where to put the data they generate)

We could indeed standardize on the location of where an app puts the data it generates in a “Data" space.

Even without this, to remove an app you’d simply remove the Code/ space (+ the WebHome).

The problem is not about removing the app, but removing the data without removing the app.

So your proposal of a standardized Data directory doesn’t contradict my proposal, it’s actually an additional proposal, so I guess you agree about the 2 rules? (you didn’t mention anything about rule 2).

Thanks! -Vincent

...

On Wed, Sep 30, 2015 at 8:22 AM, [email protected] wrote:

...

Ping! There’s only Thomas and Gaby who answered so far :)

Thanks -Vincent

On 27 Sep 2015 at 21:19:43, [email protected] ([email protected]) wrote:

Hi devs,

Following our implementation of NS/NP in 7.2 I’d like to propose 2 new best practices for app dev that we would list at

http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...

...

1) New rule 1: “Code” subspace

Current text: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC,

AppWithinMinutes,

...

etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations.

New version: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations. * Technical pages should be put in a subspace named “Code”

Note: this rule can only be applied for new applications for now since the EM doesn’t know how to follow renames currently so for example if I move pages from the FAQCode space to the FAQ.Code space, when EM upgrades the app, it’ll display all pages in FAQCode as deleted (basically it considers all pages in FAQ.Code as new pages and pages in FAQCode as deleted pages). Note: I’ve created http://jira.xwiki.org/browse/XWIKI-12622 for this.

2) New rule 2:

* Technical pages without children must be terminal pages.

WDYT?

Thanks -Vincent

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

-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

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

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

On Wed, Sep 30, 2015 at 10:22 AM, [email protected] <[email protected]> wrote:

Hi Denis,

On 30 Sep 2015 at 09:49:28, Denis Gervalle ([email protected](mailto:[email protected])) wrote:

...

Well, I have not yet look in details the new features for page manipulation, but I was wondering if there will be a simple way to delete application data without deleting the application itself with the model you propose ? I know there is already issue with that about the WebHome which is usually an entry point to the application, but deleting a space was possible. If the code is nested under the data, isn't it an issue. It looks like the opposite of the general way (not xwiki way, but in application in general), where the code abstract more or less the location of the data and is the "main" part.

So, I am not sure actually, that this is the best way. Maybe code and data should be side by side under a entry point documents ?

You mean something like:

MyApp |_ Data/ |_ Code/ |_ WebHome

(Instead of leaving it free for apps to decide where to put the data they generate)

We could indeed standardize on the location of where an app puts the data it generates in a “Data" space.

The problem with that is the forced /Data/ part of the URL which is really not nice.

Even without this, to remove an app you’d simply remove the Code/ space (+ the WebHome).

So your proposal of a standardized Data directory doesn’t contradict my proposal, it’s actually an additional proposal, so I guess you agree about the 2 rules? (you didn’t mention anything about rule 2).

Thanks! -Vincent

...

On Wed, Sep 30, 2015 at 8:22 AM, [email protected] wrote:

...

Ping! There’s only Thomas and Gaby who answered so far :)

Thanks -Vincent

On 27 Sep 2015 at 21:19:43, [email protected] ([email protected]) wrote:

Hi devs,

Following our implementation of NS/NP in 7.2 I’d like to propose 2 new best practices for app dev that we would list at http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...

1) New rule 1: “Code” subspace

Current text: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations.

New version: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations. * Technical pages should be put in a subspace named “Code”

Note: this rule can only be applied for new applications for now since the EM doesn’t know how to follow renames currently so for example if I move pages from the FAQCode space to the FAQ.Code space, when EM upgrades the app, it’ll display all pages in FAQCode as deleted (basically it considers all pages in FAQ.Code as new pages and pages in FAQCode as deleted pages). Note: I’ve created http://jira.xwiki.org/browse/XWIKI-12622 for this.

2) New rule 2:

* Technical pages without children must be terminal pages.

WDYT?

Thanks -Vincent

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

-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

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

-- Thomas Mortagne

I think what I like best is some option in the refactoring API to indicate that you want to delete only final documents in the space (so skipping space home page and spaces). On Wed, Sep 30, 2015 at 10:29 AM, [email protected] <[email protected]> wrote:

On 30 Sep 2015 at 10:28:54, Thomas Mortagne ([email protected](mailto:[email protected])) wrote:

...

On Wed, Sep 30, 2015 at 10:22 AM, [email protected] wrote:

...

Hi Denis,

On 30 Sep 2015 at 09:49:28, Denis Gervalle ([email protected](mailto:[email protected])) wrote:

...

Well, I have not yet look in details the new features for page manipulation, but I was wondering if there will be a simple way to delete application data without deleting the application itself with the model you propose ? I know there is already issue with that about the WebHome which is usually an entry point to the application, but deleting a space was possible. If the code is nested under the data, isn't it an issue. It looks like the opposite of the general way (not xwiki way, but in application in general), where the code abstract more or less the location of the data and is the "main" part.

So, I am not sure actually, that this is the best way. Maybe code and data should be side by side under a entry point documents ?

You mean something like:

MyApp |_ Data/ |_ Code/ |_ WebHome

(Instead of leaving it free for apps to decide where to put the data they generate)

We could indeed standardize on the location of where an app puts the data it generates in a “Data" space.

The problem with that is the forced /Data/ part of the URL which is really not nice.

Good point, that’s a no go IMO.

Thanks -Vincent

...

...

Even without this, to remove an app you’d simply remove the Code/ space (+ the WebHome).

So your proposal of a standardized Data directory doesn’t contradict my proposal, it’s actually an additional proposal, so I guess you agree about the 2 rules? (you didn’t mention anything about rule 2).

Thanks! -Vincent

...

On Wed, Sep 30, 2015 at 8:22 AM, [email protected] wrote:

...

Ping! There’s only Thomas and Gaby who answered so far :)

Thanks -Vincent

On 27 Sep 2015 at 21:19:43, [email protected] ([email protected]) wrote:

Hi devs,

Following our implementation of NS/NP in 7.2 I’d like to propose 2 new best practices for app dev that we would list at http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...

1) New rule 1: “Code” subspace

Current text: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations.

New version: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations. * Technical pages should be put in a subspace named “Code”

Note: this rule can only be applied for new applications for now since the EM doesn’t know how to follow renames currently so for example if I move pages from the FAQCode space to the FAQ.Code space, when EM upgrades the app, it’ll display all pages in FAQCode as deleted (basically it considers all pages in FAQ.Code as new pages and pages in FAQCode as deleted pages). Note: I’ve created http://jira.xwiki.org/browse/XWIKI-12622 for this.

2) New rule 2:

* Technical pages without children must be terminal pages.

WDYT?

Thanks -Vincent

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

-- Thomas Mortagne

On Wed, Sep 30, 2015 at 10:58 AM, [email protected] <[email protected]> wrote:

On 30 Sep 2015 at 10:53:48, Thomas Mortagne ([email protected](mailto:[email protected])) wrote:

...

I think what I like best is some option in the refactoring API to indicate that you want to delete only final documents in the space (so skipping space home page and spaces).

That could be interesting for some use cases but it’s risky for this one. Several apps may generate terminal pages and users could create terminal pages in app spaces too. So that would not just remove the app technical pages, it could remove more.

I don't understand what you mean. The whole point is to remove only data, the technical pages would be in Code subspace.

Thanks -Vincent

...

On Wed, Sep 30, 2015 at 10:29 AM, [email protected] wrote:

...

On 30 Sep 2015 at 10:28:54, Thomas Mortagne ([email protected](mailto:[email protected])) wrote:

...

On Wed, Sep 30, 2015 at 10:22 AM, [email protected] wrote:

...

Hi Denis,

On 30 Sep 2015 at 09:49:28, Denis Gervalle ([email protected](mailto:[email protected])) wrote:

...

Well, I have not yet look in details the new features for page manipulation, but I was wondering if there will be a simple way to delete application data without deleting the application itself with the model you propose ? I know there is already issue with that about the WebHome which is usually an entry point to the application, but deleting a space was possible. If the code is nested under the data, isn't it an issue. It looks like the opposite of the general way (not xwiki way, but in application in general), where the code abstract more or less the location of the data and is the "main" part.

So, I am not sure actually, that this is the best way. Maybe code and data should be side by side under a entry point documents ?

You mean something like:

MyApp |_ Data/ |_ Code/ |_ WebHome

(Instead of leaving it free for apps to decide where to put the data they generate)

We could indeed standardize on the location of where an app puts the data it generates in a “Data" space.

The problem with that is the forced /Data/ part of the URL which is really not nice.

Good point, that’s a no go IMO.

Thanks -Vincent

...

...

Even without this, to remove an app you’d simply remove the Code/ space (+ the WebHome).

So your proposal of a standardized Data directory doesn’t contradict my proposal, it’s actually an additional proposal, so I guess you agree about the 2 rules? (you didn’t mention anything about rule 2).

Thanks! -Vincent

...

On Wed, Sep 30, 2015 at 8:22 AM, [email protected] wrote:

> Ping! There’s only Thomas and Gaby who answered so far :) > > > Thanks > -Vincent > > > On 27 Sep 2015 at 21:19:43, [email protected] ([email protected]) wrote: > > Hi devs, > > Following our implementation of NS/NP in 7.2 I’d like to propose 2 new > best practices for app dev that we would list at > http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac... > > 1) New rule 1: “Code” subspace > > Current text: > * Generally, put all your pages in a single space dedicated for the > application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, > etc). The name must be as short as possible while still being > understandable of course and without overusing abbreviations. > > New version: > * Generally, put all your pages in a single space dedicated for the > application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, > etc). The name must be as short as possible while still being > understandable of course and without overusing abbreviations. > * Technical pages should be put in a subspace named “Code” > > Note: this rule can only be applied for new applications for now since the > EM doesn’t know how to follow renames currently so for example if I move > pages from the FAQCode space to the FAQ.Code space, when EM upgrades the > app, it’ll display all pages in FAQCode as deleted (basically it considers > all pages in FAQ.Code as new pages and pages in FAQCode as deleted pages). > Note: I’ve created http://jira.xwiki.org/browse/XWIKI-12622 for this. > > 2) New rule 2: > > * Technical pages without children must be terminal pages. > > WDYT? > > Thanks > -Vincent

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

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

---

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

-- Thomas Mortagne

Hi, On Wed, Sep 30, 2015 at 11:16 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

2015-09-30 10:58 GMT+02:00 [email protected] <[email protected]>:

...

On 30 Sep 2015 at 10:53:48, Thomas Mortagne ([email protected] (mailto:[email protected])) wrote:

...

I think what I like best is some option in the refactoring API to indicate that you want to delete only final documents in the space (so skipping space home page and spaces).

That could be interesting for some use cases but it’s risky for this one. Several apps may generate terminal pages and users could create terminal pages in app spaces too. So that would not just remove the app technical pages, it could remove more.

The idea of Thomas is an option to only delete *terminal* pages located in the space with a depth of 1. Said differently, the direct and terminal children of the page.

This way, you can delete all data located in the space without removing the code (because the code would be located in a deeper depth), but it works only if the app generates data as terminal pages. It is the case right now, but new apps should work differently and create their data as regular Nested Pages.

That is why I don't think it's the correct way to go.

We need this option: delete this page and its children *except* the "Code" page and its children. This option could be proposed by the app itself, as a "clean data" functionality.

From an interface point of view, this could be solved with a treeview when clicking on delete.

"This action will delete the page and all of its children, as displayed below. Please uncheck pages you don't want to see deleted." Thanks, Guillaume

The other solution is to not change the current best practices and let the code in an other space.

...

Thanks -Vincent

...

On Wed, Sep 30, 2015 at 10:29 AM, [email protected] wrote:

...

On 30 Sep 2015 at 10:28:54, Thomas Mortagne (

[email protected]

...

(mailto:[email protected])) wrote:

...

...

...

On Wed, Sep 30, 2015 at 10:22 AM, [email protected] wrote:

...

Hi Denis,

On 30 Sep 2015 at 09:49:28, Denis Gervalle ([email protected](mailto:

[email protected])) wrote:

...

...

...

> Well, I have not yet look in details the new features for page > manipulation, but I was wondering if there will be a simple way

to delete

...

> application data without deleting the application itself with the model you > propose ? > I know there is already issue with that about the WebHome which > is usually an entry point to the application, but deleting a space was > possible. If the code is nested under the data, isn't it an issue. It looks > like the opposite of the general way (not xwiki way, but in application in > general), where the code abstract more or less the location of the data and > is the "main" part. > > So, I am not sure actually, that this is the best way. Maybe code and data > should be side by side under a entry point documents ?

You mean something like:

MyApp |_ Data/ |_ Code/ |_ WebHome

(Instead of leaving it free for apps to decide where to put the data they generate)

We could indeed standardize on the location of where an app puts the data it generates in a “Data" space.

The problem with that is the forced /Data/ part of the URL which is really not nice.

Good point, that’s a no go IMO.

Thanks -Vincent

...

...

Even without this, to remove an app you’d simply remove the Code/ space (+ the WebHome).

So your proposal of a standardized Data directory doesn’t contradict my proposal, it’s actually an additional proposal, so I guess you agree about the 2 rules? (you didn’t mention anything about rule 2).

Thanks! -Vincent

> On Wed, Sep 30, 2015 at 8:22 AM, [email protected] > wrote: > > > Ping! There’s only Thomas and Gaby who answered so far :) > > > > > > Thanks > > -Vincent > > > > > > On 27 Sep 2015 at 21:19:43, [email protected] ( [email protected]) wrote: > > > > Hi devs, > > > > Following our implementation of NS/NP in 7.2 I’d like to propose 2 new > > best practices for app dev that we would list at > >

http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...

...

...

...

...

...

> > > > 1) New rule 1: “Code” subspace > > > > Current text: > > * Generally, put all your pages in a single space dedicated for the > > application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, > > etc). The name must be as short as possible while still being > > understandable of course and without overusing abbreviations. > > > > New version: > > * Generally, put all your pages in a single space dedicated for the > > application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, > > etc). The name must be as short as possible while still being > > understandable of course and without overusing abbreviations. > > * Technical pages should be put in a subspace named “Code” > > > > Note: this rule can only be applied for new applications for now since the > > EM doesn’t know how to follow renames currently so for example if I move > > pages from the FAQCode space to the FAQ.Code space, when EM upgrades the > > app, it’ll display all pages in FAQCode as deleted (basically it considers > > all pages in FAQ.Code as new pages and pages in FAQCode as deleted pages). > > Note: I’ve created http://jira.xwiki.org/browse/XWIKI-12622 for this. > > > > 2) New rule 2: > > > > * Technical pages without children must be terminal pages. > > > > WDYT? > > > > Thanks > > -Vincent

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

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

---

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

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

Actually maybe a simpler thing would be an option (or combination of options) to delete all the not hidden pages inside a space (except the home page) since that's pretty much what is the difference between (properly written) technical page and data usually. Even if you provide a tree you still need some proposal or thing selected by default. On Wed, Sep 30, 2015 at 11:55 AM, [email protected] <[email protected]> wrote:

On 30 Sep 2015 at 11:30:16, Guillaume Lerouge ([email protected](mailto:[email protected])) wrote:

...

Hi,

On Wed, Sep 30, 2015 at 11:16 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

2015-09-30 10:58 GMT+02:00 [email protected] :

...

On 30 Sep 2015 at 10:53:48, Thomas Mortagne ([email protected] (mailto:[email protected])) wrote:

...

I think what I like best is some option in the refactoring API to indicate that you want to delete only final documents in the space (so skipping space home page and spaces).

That could be interesting for some use cases but it’s risky for this one. Several apps may generate terminal pages and users could create terminal pages in app spaces too. So that would not just remove the app technical pages, it could remove more.

The idea of Thomas is an option to only delete *terminal* pages located in the space with a depth of 1. Said differently, the direct and terminal children of the page.

This way, you can delete all data located in the space without removing the code (because the code would be located in a deeper depth), but it works only if the app generates data as terminal pages. It is the case right now, but new apps should work differently and create their data as regular Nested Pages.

That is why I don't think it's the correct way to go.

We need this option: delete this page and its children *except* the "Code" page and its children. This option could be proposed by the app itself, as a "clean data" functionality.

From an interface point of view, this could be solved with a treeview when clicking on delete.

"This action will delete the page and all of its children, as displayed below. Please uncheck pages you don't want to see deleted.”

Yes, I like this, a LT might be better for filtering things though.

Thanks -Vincent

...

Thanks,

Guillaume

...

The other solution is to not change the current best practices and let the code in an other space.

...

Thanks -Vincent

...

On Wed, Sep 30, 2015 at 10:29 AM, [email protected] wrote:

...

On 30 Sep 2015 at 10:28:54, Thomas Mortagne (

[email protected]

...

(mailto:[email protected])) wrote:

...

...

> On Wed, Sep 30, 2015 at 10:22 AM, [email protected] wrote: > > Hi Denis, > > > > On 30 Sep 2015 at 09:49:28, Denis Gervalle ([email protected](mailto:

[email protected])) wrote:

...

> > > >> Well, I have not yet look in details the new features for page > >> manipulation, but I was wondering if there will be a simple way to delete > >> application data without deleting the application itself with the model you > >> propose ? > >> I know there is already issue with that about the WebHome which > >> is usually an entry point to the application, but deleting a space was > >> possible. If the code is nested under the data, isn't it an issue. It looks > >> like the opposite of the general way (not xwiki way, but in application in > >> general), where the code abstract more or less the location of the data and > >> is the "main" part. > >> > >> So, I am not sure actually, that this is the best way. Maybe code and data > >> should be side by side under a entry point documents ? > > > > You mean something like: > > > > MyApp > > |_ Data/ > > |_ Code/ > > |_ WebHome > > > > (Instead of leaving it free for apps to decide where to put the data they generate) > > > > We could indeed standardize on the location of where an app puts the data it generates in a “Data" space. > > The problem with that is the forced /Data/ part of the URL which is > really not nice.

Good point, that’s a no go IMO.

Thanks -Vincent

> > Even without this, to remove an app you’d simply remove the Code/ space (+ the WebHome). > > > > So your proposal of a standardized Data directory doesn’t contradict my proposal, it’s actually an additional proposal, so I guess you agree about the 2 rules? (you didn’t mention anything about rule 2). > > > > Thanks! > > -Vincent > > > >> On Wed, Sep 30, 2015 at 8:22 AM, [email protected] > >> wrote: > >> > >> > Ping! There’s only Thomas and Gaby who answered so far :) > >> > > >> > > >> > Thanks > >> > -Vincent > >> > > >> > > >> > On 27 Sep 2015 at 21:19:43, [email protected] ( [email protected]) wrote: > >> > > >> > Hi devs, > >> > > >> > Following our implementation of NS/NP in 7.2 I’d like to propose 2 new > >> > best practices for app dev that we would list at > >> >

http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...

...

...

...

> >> > > >> > 1) New rule 1: “Code” subspace > >> > > >> > Current text: > >> > * Generally, put all your pages in a single space dedicated for the > >> > application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, > >> > etc). The name must be as short as possible while still being > >> > understandable of course and without overusing abbreviations. > >> > > >> > New version: > >> > * Generally, put all your pages in a single space dedicated for the > >> > application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, > >> > etc). The name must be as short as possible while still being > >> > understandable of course and without overusing abbreviations. > >> > * Technical pages should be put in a subspace named “Code” > >> > > >> > Note: this rule can only be applied for new applications for now since the > >> > EM doesn’t know how to follow renames currently so for example if I move > >> > pages from the FAQCode space to the FAQ.Code space, when EM upgrades the > >> > app, it’ll display all pages in FAQCode as deleted (basically it considers > >> > all pages in FAQ.Code as new pages and pages in FAQCode as deleted pages). > >> > Note: I’ve created http://jira.xwiki.org/browse/XWIKI-12622 for this. > >> > > >> > 2) New rule 2: > >> > > >> > * Technical pages without children must be terminal pages. > >> > > >> > WDYT? > >> > > >> > Thanks > >> > -Vincent

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

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

---

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

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

---

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

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

-- Thomas Mortagne

Hi, IMO, this starts getting overly complicated (when we start making assumptions). We don`t really need/want to let (or strive to help) the end user/admin have to decide what he *has* to delete. We need to simplify his main objectives: 1) delete the data (keep the app) 2) delete the app and data (i.e. whipe everything) 3) delete the app (but preserve data). I like the proposal Denis made, since it`s simplifies things greatly, specially point 1), but also makes apps easier to understand and manage with XWiki's default UI (administration/rights, CRUP operations, etc.) IMO, the "/Data/" URL fragment is not a no-go and, if it becomes vital for a deployment to have it removed, then I guess an URL rewrite would easily fix this by pointing to documents inside the "Data" space by default, while still allowing "/Code/..." explicit access. We would probably also need to adapt AWM to this new layout for the new apps. Thanks, Eduard On Wed, Sep 30, 2015 at 12:55 PM, [email protected] <[email protected]> wrote:

On 30 Sep 2015 at 11:30:16, Guillaume Lerouge ([email protected](mailto: [email protected])) wrote:

...

Hi,

On Wed, Sep 30, 2015 at 11:16 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

2015-09-30 10:58 GMT+02:00 [email protected] :

...

On 30 Sep 2015 at 10:53:48, Thomas Mortagne (

[email protected]

...

(mailto:[email protected])) wrote:

...

I think what I like best is some option in the refactoring API to indicate that you want to delete only final documents in the space (so skipping space home page and spaces).

That could be interesting for some use cases but it’s risky for this one. Several apps may generate terminal pages and users could create terminal pages in app spaces too. So that would not just remove the app technical pages, it could remove more.

The idea of Thomas is an option to only delete *terminal* pages located in the space with a depth of 1. Said differently, the direct and terminal children of the page.

This way, you can delete all data located in the space without removing the code (because the code would be located in a deeper depth), but it works only if the app generates data as terminal pages. It is the case right now, but new apps should work differently and create their data as regular Nested Pages.

That is why I don't think it's the correct way to go.

We need this option: delete this page and its children *except* the "Code" page and its children. This option could be proposed by the app itself, as a "clean data" functionality.

From an interface point of view, this could be solved with a treeview when clicking on delete.

"This action will delete the page and all of its children, as displayed below. Please uncheck pages you don't want to see deleted.”

Yes, I like this, a LT might be better for filtering things though.

Thanks -Vincent

...

Thanks,

Guillaume

...

The other solution is to not change the current best practices and let

the

...

...

code in an other space.

...

Thanks -Vincent

...

On Wed, Sep 30, 2015 at 10:29 AM, [email protected] wrote:

...

On 30 Sep 2015 at 10:28:54, Thomas Mortagne (

[email protected]

...

(mailto:[email protected])) wrote:

...

...

> On Wed, Sep 30, 2015 at 10:22 AM, [email protected] wrote: > > Hi Denis, > > > > On 30 Sep 2015 at 09:49:28, Denis Gervalle ([email protected]

(mailto: [email protected])) wrote:

...

> > > >> Well, I have not yet look in details the new features for page > >> manipulation, but I was wondering if there will be a simple way to delete > >> application data without deleting the application itself with the model you > >> propose ? > >> I know there is already issue with that about the WebHome which > >> is usually an entry point to the application, but deleting a space was > >> possible. If the code is nested under the data, isn't it an issue. It looks > >> like the opposite of the general way (not xwiki way, but in application in > >> general), where the code abstract more or less the location of the data and > >> is the "main" part. > >> > >> So, I am not sure actually, that this is the best way. Maybe code and data > >> should be side by side under a entry point documents ? > > > > You mean something like: > > > > MyApp > > |_ Data/ > > |_ Code/ > > |_ WebHome > > > > (Instead of leaving it free for apps to decide where to put the data they generate) > > > > We could indeed standardize on the location of where an app puts the data it generates in a “Data" space. > > The problem with that is the forced /Data/ part of the URL which is > really not nice.

Good point, that’s a no go IMO.

Thanks -Vincent

> > Even without this, to remove an app you’d simply remove the Code/ space (+ the WebHome). > > > > So your proposal of a standardized Data directory doesn’t contradict my proposal, it’s actually an additional proposal, so I guess you agree about the 2 rules? (you didn’t mention anything about rule 2). > > > > Thanks! > > -Vincent > > > >> On Wed, Sep 30, 2015 at 8:22 AM, [email protected] > >> wrote: > >> > >> > Ping! There’s only Thomas and Gaby who answered so far :) > >> > > >> > > >> > Thanks > >> > -Vincent > >> > > >> > > >> > On 27 Sep 2015 at 21:19:43, [email protected] ( [email protected]) wrote: > >> > > >> > Hi devs, > >> > > >> > Following our implementation of NS/NP in 7.2 I’d like to propose 2 new > >> > best practices for app dev that we would list at > >> >

http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...

...

...

...

...

> >> > > >> > 1) New rule 1: “Code” subspace > >> > > >> > Current text: > >> > * Generally, put all your pages in a single space dedicated for the > >> > application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, > >> > etc). The name must be as short as possible while still being > >> > understandable of course and without overusing abbreviations. > >> > > >> > New version: > >> > * Generally, put all your pages in a single space dedicated for the > >> > application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, > >> > etc). The name must be as short as possible while still being > >> > understandable of course and without overusing abbreviations. > >> > * Technical pages should be put in a subspace named “Code” > >> > > >> > Note: this rule can only be applied for new applications for now since the > >> > EM doesn’t know how to follow renames currently so for example if I move > >> > pages from the FAQCode space to the FAQ.Code space, when EM upgrades the > >> > app, it’ll display all pages in FAQCode as deleted (basically it considers > >> > all pages in FAQ.Code as new pages and pages in FAQCode as deleted pages). > >> > Note: I’ve created http://jira.xwiki.org/browse/XWIKI-12622 for this. > >> > > >> > 2) New rule 2: > >> > > >> > * Technical pages without children must be terminal pages. > >> > > >> > WDYT? > >> > > >> > Thanks > >> > -Vincent

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

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

---

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

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

---

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

---

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

On Wed, Sep 30, 2015 at 11:16 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

2015-09-30 10:58 GMT+02:00 [email protected] <[email protected]>:

...

On 30 Sep 2015 at 10:53:48, Thomas Mortagne ([email protected] (mailto:[email protected])) wrote:

...

I think what I like best is some option in the refactoring API to indicate that you want to delete only final documents in the space (so skipping space home page and spaces).

That could be interesting for some use cases but it’s risky for this one. Several apps may generate terminal pages and users could create terminal pages in app spaces too. So that would not just remove the app technical pages, it could remove more.

The idea of Thomas is an option to only delete *terminal* pages located in the space with a depth of 1. Said differently, the direct and terminal children of the page.

This way, you can delete all data located in the space without removing the code (because the code would be located in a deeper depth), but it works only if the app generates data as terminal pages. It is the case right now, but new apps should work differently and create their data as regular Nested Pages.

I don't agree at all on this later statement. New apps _may_ work differently and create nested pages, but it _should_ not. Anyway, this is why I am wondering about properly separating WebHome, Code and Data. I do not think we need stable names, but the structure matter. If Data does not look nice, you may leave apps decide for themselves, the rules being put your data in subspaces, and code in the Code subspace, or something like that. Please note that using "space" in the previous rules looks bad to me, since we do not have space anymore ;)

[...] Just another random thought: some applications might really want to have two "data" spaces; for example currently in the blog you cannot have a category and a blog post with the same name. If both end up in their respective "subfolders" "Blog.Posts" and "Blog.Categories", the problem goes away. On the other hand if the application pages end up directly inside the main page, then e.g. you cannot have a category "Code" in the Blog. (You cannot have a blog post with it either, but that might be a smaller nuisance)

Hello. Why not using "Entries" instead of "Data" for the name? It will be shown both in the URL and in the breadcrumb, and fit with most of the use-cases. Users can still change the title of the "Entries" space to have a more specific name such as "Ideas", "Meetings", etc... Just my 2 cents. 2015-10-26 10:45 GMT+01:00 Marius Dumitru Florea < [email protected]>:

On Fri, Oct 23, 2015 at 5:06 PM, Clemens Klein-Robbenhaar < [email protected]> wrote:

...

...

On Wed, Sep 30, 2015 at 11:16 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

2015-09-30 10:58 GMT+02:00 [email protected] <[email protected]>:

...

On 30 Sep 2015 at 10:53:48, Thomas Mortagne (

[email protected]

...

...

...

...

(mailto:[email protected])) wrote:

...

I think what I like best is some option in the refactoring API to indicate that you want to delete only final documents in the space (so skipping space home page and spaces).

That could be interesting for some use cases but it’s risky for this one. Several apps may generate terminal pages and users could create terminal pages in app spaces too. So that would not just remove the app technical pages, it could remove more.

The idea of Thomas is an option to only delete *terminal* pages located in the space with a depth of 1. Said differently, the direct and terminal children of the page.

This way, you can delete all data located in the space without removing the code (because the code would be located in a deeper depth), but it works only if the app generates data as terminal pages. It is the case right now, but new apps should work differently and create their data as regular Nested Pages.

I don't agree at all on this later statement. New apps _may_ work differently and create nested pages, but it _should_ not. Anyway, this is why I am wondering about properly separating WebHome, Code and Data. I do not think we need stable names, but the structure matter. If Data does not look nice, you may leave apps decide for themselves, the rules being put your data in subspaces, and code in the Code subspace, or something like that. Please note that using "space" in the previous rules looks bad to me, since we do not have space anymore ;)

[...]

...

Just another random thought: some applications might really want to have two "data" spaces; for example currently in the blog you cannot have a category and a blog post with the same name. If both end up in their respective "subfolders" "Blog.Posts" and "Blog.Categories", the problem goes away.

Indeed, but I don't think it contradicts the rule. IMO the best practice should be to group the application data in one or more subspaces under the application space. If the application generates only one type of data (e.g. Events) then it makes sense to have only one Data subspace. If the application generates two or more types of data (Categories and Posts) then it may need more subspaces. The only question is whether we should group these subspaces under a Data subspace, e.g.

App / Data / Categories

or leave them directly under the application space:

App / Categories

I prefer the second option.

Another thing to decide is whether the Data space should be named "Data" or some domain-specific name. Considering that we can set the title of the home page to anything we want, I prefer to use "Data" as name, so that the code deals with a generic "Data" space, even though the user sees "Events" in the breadcrumbs.

...

On the other hand if the application pages end up directly inside the main page, then e.g. you cannot have a category "Code" in the Blog. (You cannot have a blog post with it either, but that might be a smaller nuisance)

Good point, and another reason to group the application data in nested spaces under the application space.

Thanks, Marius

...

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

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

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project

On Tue, Oct 27, 2015 at 11:37 AM, [email protected] <[email protected]> wrote:

On 27 Oct 2015 at 11:35:13, Guillaume Louis-Marie Delhumeau ( [email protected](mailto:[email protected])) wrote:

...

Hello.

Why not using "Entries" instead of "Data" for the name? It will be shown both in the URL and in the breadcrumb, and fit with most of the use-cases.

Users can still change the title of the "Entries" space to have a more specific name such as "Ideas", "Meetings", etc…

It’s true that Entries is less technical than Data so I would also prefer it. However can we foresee some generated data that won’t be Entries?

First that come to mind, is configuration. You may as well need to store temporary data, cached data, etc… I am not sure all apps should be considered close to AWM.

Thanks -Vincent

...

Just my 2 cents.

2015-10-26 10:45 GMT+01:00 Marius Dumitru Florea < [email protected]>:

...

On Fri, Oct 23, 2015 at 5:06 PM, Clemens Klein-Robbenhaar < [email protected]> wrote:

...

...

On Wed, Sep 30, 2015 at 11:16 AM, Guillaume "Louis-Marie"

Delhumeau <

...

...

[email protected]> wrote:

...

2015-09-30 10:58 GMT+02:00 [email protected] :

> > On 30 Sep 2015 at 10:53:48, Thomas Mortagne ( [email protected] > (mailto:[email protected])) wrote: > >> I think what I like best is some option in the refactoring API to >> indicate that you want to delete only final documents in the space (so >> skipping space home page and spaces). > > That could be interesting for some use cases but it’s risky for this one. > Several apps may generate terminal pages and users could create terminal > pages in app spaces too. So that would not just remove the app technical > pages, it could remove more. >

The idea of Thomas is an option to only delete *terminal* pages located in the space with a depth of 1. Said differently, the direct and terminal children of the page.

This way, you can delete all data located in the space without removing the code (because the code would be located in a deeper depth), but it works only if the app generates data as terminal pages. It is the case right now, but new apps should work differently and create their data as regular Nested Pages.

I don't agree at all on this later statement. New apps _may_ work differently and create nested pages, but it _should_ not. Anyway, this is why I am wondering about properly separating WebHome, Code and Data. I do not think we need stable names, but the structure matter. If Data does not look nice, you may leave apps decide for themselves, the rules being put your data in subspaces, and code in the Code subspace, or something like that. Please note that using "space" in the previous rules looks bad to me, since we do not have space anymore ;)

[...]

...

Just another random thought: some applications might really want to have two "data" spaces; for example currently in the blog you cannot have a category and a blog post with the same name. If both end up in their respective "subfolders" "Blog.Posts" and "Blog.Categories", the problem goes away.

Indeed, but I don't think it contradicts the rule. IMO the best practice should be to group the application data in one or more subspaces under the application space. If the application generates only one type of data (e.g. Events) then it makes sense to have only one Data subspace. If the application generates two or more types of data (Categories and Posts) then it may need more subspaces. The only question is whether we should group these subspaces under a Data subspace, e.g.

App / Data / Categories

or leave them directly under the application space:

App / Categories

I prefer the second option.

Another thing to decide is whether the Data space should be named "Data" or some domain-specific name. Considering that we can set the title of the home page to anything we want, I prefer to use "Data" as name, so that the code deals with a generic "Data" space, even though the user sees "Events" in the breadcrumbs.

...

On the other hand if the application pages end up directly inside the main page, then e.g. you cannot have a category "Code" in the Blog. (You cannot have a blog post with it either, but that might be a smaller nuisance)

Good point, and another reason to group the application data in nested spaces under the application space.

Thanks, Marius

...

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

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

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

---

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

-- Denis Gervalle SOFTEC sa - CEO

Hi Anca, On Fri, Nov 13, 2015 at 8:51 PM, Anca Luca <[email protected]> wrote:

Hello all,

my 2 cents on the "Data" or "Entries" subspace. ( But too late, since I see the issue was already closed :( )

I'm afraid that, even if technically it seems like a nice idea, it's not that nice for a "regular non-developer user" which perceive an application as only having data.

They don't need to and won't know that the code of that application is also stored on the wiki, in another subspace that is called "Code".

The Code space is still hidden so a regular user doesn't see it. There's no change in this regard.

There is complaint about the size and the amount of bloat in the XWiki URLS (the /xwiki/bin/view/ part) and this would be an extra one, for the case of applications. I don't think url rewrite should be considered so easily as an option because it's technically not so easy to achieve and I think that there can be an issue with colision (e.g. between MyApp/WebPreferences and MyApp/Data/WebPreferences).

So you think having MyApp and MyAppCode is better?

But I guess this is really too late now...

The location where the application stores its data is configurable. Thanks, Marius

Thanks, Anca

On Tue, Oct 27, 2015 at 11:34 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

Hello.

Why not using "Entries" instead of "Data" for the name? It will be shown both in the URL and in the breadcrumb, and fit with most of the use-cases.

Users can still change the title of the "Entries" space to have a more specific name such as "Ideas", "Meetings", etc...

Just my 2 cents.

2015-10-26 10:45 GMT+01:00 Marius Dumitru Florea < [email protected]>:

...

On Fri, Oct 23, 2015 at 5:06 PM, Clemens Klein-Robbenhaar < [email protected]> wrote:

...

...

On Wed, Sep 30, 2015 at 11:16 AM, Guillaume "Louis-Marie"

Delhumeau <

...

...

[email protected]> wrote:

...

2015-09-30 10:58 GMT+02:00 [email protected] <[email protected] :

> > On 30 Sep 2015 at 10:53:48, Thomas Mortagne ( [email protected] > (mailto:[email protected])) wrote: > >> I think what I like best is some option in the refactoring API to >> indicate that you want to delete only final documents in the space (so >> skipping space home page and spaces). > > That could be interesting for some use cases but it’s risky for this one. > Several apps may generate terminal pages and users could create terminal > pages in app spaces too. So that would not just remove the app technical > pages, it could remove more. >

The idea of Thomas is an option to only delete *terminal* pages located in the space with a depth of 1. Said differently, the direct and terminal children of the page.

This way, you can delete all data located in the space without removing the code (because the code would be located in a deeper depth), but it works only if the app generates data as terminal pages. It is the case right now, but new apps should work differently and create their data as regular Nested Pages.

I don't agree at all on this later statement. New apps _may_ work differently and create nested pages, but it _should_ not. Anyway, this is why I am wondering about properly separating WebHome, Code and Data. I do not think we need stable names, but the structure matter. If Data does not look nice, you may leave apps decide for themselves, the rules being put your data in subspaces, and code in the Code subspace, or something like that. Please note that using "space" in the previous rules looks bad to me, since we do not have space anymore ;)

[...]

...

Just another random thought: some applications might really want to have two "data" spaces; for example currently in the blog you cannot have a category and a blog post with the same name. If both end up in their respective "subfolders" "Blog.Posts" and "Blog.Categories", the problem goes away.

Indeed, but I don't think it contradicts the rule. IMO the best practice should be to group the application data in one or more subspaces under the application space. If the application generates only one type of data (e.g. Events) then it makes sense to have only one Data subspace. If the application generates two or more types of data (Categories and Posts) then it may need more subspaces. The only question is whether we should group these subspaces under a Data subspace, e.g.

App / Data / Categories

or leave them directly under the application space:

App / Categories

I prefer the second option.

Another thing to decide is whether the Data space should be named "Data" or some domain-specific name. Considering that we can set the title of the home page to anything we want, I prefer to use "Data" as name, so that the code deals with a generic "Data" space, even though the user sees "Events" in the breadcrumbs.

...

On the other hand if the application pages end up directly inside the main page, then e.g. you cannot have a category "Code" in the Blog. (You cannot have a blog post with it either, but that might be a smaller nuisance)

Good point, and another reason to group the application data in nested spaces under the application space.

Thanks, Marius

...

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

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

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

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

On Sat, Nov 14, 2015 at 3:17 PM, [email protected] <[email protected]> wrote:

Hi Anca, On 14 Nov 2015 at 10:57:24, Marius Dumitru Florea ( [email protected]) wrote:

Hi Anca,

On Fri, Nov 13, 2015 at 8:51 PM, Anca Luca <[email protected]> wrote:

...

Hello all,

my 2 cents on the "Data" or "Entries" subspace. ( But too late, since I see the issue was already closed :( ) Thanks for taking the time to participate.

...

I'm afraid that, even if technically it seems like a nice idea, it's not that nice for a "regular non-developer user" which perceive an application as only having data.

...

They don't need to and won't know that the code of that application is also stored on the wiki, in another subspace that is called "Code".

The Code space is still hidden so a regular user doesn't see it. There's no change in this regard.

...

There is complaint about the size and the amount of bloat in the XWiki URLS (the /xwiki/bin/view/ part) and this would be an extra one, for the case of applications. I don't think url rewrite should be considered so easily as an option because it's technically not so easy to achieve and I think that there can be an issue with colision (e.g. between MyApp/WebPreferences and MyApp/Data/WebPreferences).

So you think having MyApp and MyAppCode is better? You need to read the whole discussion thread and see that we’ve discussed about what you said already and we’ve weighted pros and cons to decide in the end that all things considered the Code and Data subspaces were probably the best solution.

If you think they are not, please make a proposal that you think would be better (ideally taking into account the arguments that we’ve already discussed) and we can discuss updating what’s been already done.

Actually, I read the discussion and I re-read it now. And, depending on how the "delete application data" is implemented (IIRC In the UI now) we could more go for detailed delete options (by default and in the app withim minutes itself). All the arguments that were brought in the discussion are correct, I just think that in some of them the 80-20 rule was wrongly estimated: * deleting a whole application data is frequent, but not _that_ frequent (20%). * it was said that a url rewrite should be doable (people really bothered by the Data particle should be able to do it). No, it's not that easy (less than 20% of the people bothered by the Data particle can do it). * less than 20% of usecases have an application within minutes that has two data spaces. Actually, I am wondering how is that an app within minutes still, because out of my knowledge this is not a known feature of app within minutes, and it means that some customization has been done to that application. For me, if an application was customized, it's still an application but not "within minutes" anymore. * if we're talking about applications in general, I think just as frequent is the case when the same application has multiple data spaces (e.g. having multiple blogs, each in a different space, in a different point in the hierarchy). Having multiple subspaces in the application space would not help much in this case. * for the rights issue, in 80% of the cases the code authors are data authors as well, there are just additional rights on the code (sub) space, so it's normal that code space inherits from app space. * deleting a space without some of its subspaces is a larger problem than app within minutes, so a more generic solution for that could be interesting. Also, I think it would be a frequent problem (80%), so having a flexible solution for it can be interesting. Actually, the only thing on which I have a doubt that it would affect 80% of the usecases is the Data particle itself in the url :) (maybe more like 50-50 :D) . However, from the discussions in the thread I kind of had the feeling that it being annoying is considered to fall in the 20% bucket, compared to the other arguments which would be 80. I have the opposite feeling, as I explained above in the bullet list. It's a good thing that it's configurable, though. In what concerns the more generic topic of best practices: In the cases of larger customizations that I met so far (on non-nested spaces, though), the isolation was much more important: all the code for all the applications and all the customizations is in one space, in order to be able to manage it together as a group (rights, UI settings, deployment, search, etc), while the data was spread around in spaces that are dedicated exclusively to data, potentially more data spaces for all the different areas of applications coded by that code. Note that this would not fit in the case of a standard app within minutes anyway. I haven't thought yet about how this strategy would adapt for nested spaces, if each code space should be nested under its application space or still keep it all isolated... Thanks, Anca

...

But I guess this is really too late now... It’ s not too late. This was done recently and we can still tune things if there’s a better proposal.

The location where the application stores its data is configurable. What we need (and the topic of this thread) is a best practice, ie. what’s used by default. We want apps by default to use these best practices, even if they’re configurable (that should be the exception). So it would be nice to have Anca and all the devs on this list to agree to use the best practices :)

Thanks

-Vincent

Thanks, Marius

...

Thanks, Anca

On Tue, Oct 27, 2015 at 11:34 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

Hello.

Why not using "Entries" instead of "Data" for the name? It will be

shown

...

...

both in the URL and in the breadcrumb, and fit with most of the use-cases.

Users can still change the title of the "Entries" space to have a more specific name such as "Ideas", "Meetings", etc...

Just my 2 cents.

2015-10-26 10:45 GMT+01:00 Marius Dumitru Florea < [email protected]>:

...

On Fri, Oct 23, 2015 at 5:06 PM, Clemens Klein-Robbenhaar < [email protected]> wrote:

...

...

On Wed, Sep 30, 2015 at 11:16 AM, Guillaume "Louis-Marie"

Delhumeau <

...

...

[email protected]> wrote:

> 2015-09-30 10:58 GMT+02:00 [email protected] < [email protected] : > >> >> On 30 Sep 2015 at 10:53:48, Thomas Mortagne ( [email protected] >> (mailto:[email protected])) wrote: >> >>> I think what I like best is some option in the refactoring API to >>> indicate that you want to delete only final documents in the space (so >>> skipping space home page and spaces). >> >> That could be interesting for some use cases but it’s risky for this one. >> Several apps may generate terminal pages and users could create terminal >> pages in app spaces too. So that would not just remove the app technical >> pages, it could remove more. >> > > The idea of Thomas is an option to only delete *terminal* pages located in > the space with a depth of 1. Said differently, the direct and terminal > children of the page. > > This way, you can delete all data located in the space without removing the > code (because the code would be located in a deeper depth), but it works > only if the app generates data as terminal pages. It is the case right now, > but new apps should work differently and create their data as regular > Nested Pages. >

I don't agree at all on this later statement. New apps _may_ work differently and create nested pages, but it _should_ not. Anyway, this is why I am wondering about properly separating WebHome, Code and Data. I do not think we need stable names, but the structure matter. If Data does not look nice, you may leave apps decide for themselves, the rules being put your data in subspaces, and code in the Code subspace, or something like that. Please note that using "space" in the previous rules looks bad to me, since we do not have space anymore ;)

[...]

...

Just another random thought: some applications might really want to have two "data" spaces; for example currently in the blog you cannot have a category and a blog post with the same name. If both end up in their respective "subfolders" "Blog.Posts" and "Blog.Categories", the problem goes away.

Indeed, but I don't think it contradicts the rule. IMO the best practice should be to group the application data in one or more subspaces under the application space. If the application generates only one type of data (e.g. Events) then it makes sense to have only one Data subspace. If the application generates two or more types of data (Categories and Posts) then it may need more subspaces. The only question is whether we should group these subspaces under a Data subspace, e.g.

App / Data / Categories

or leave them directly under the application space:

App / Categories

I prefer the second option.

Another thing to decide is whether the Data space should be named "Data" or some domain-specific name. Considering that we can set the title of the home page to anything we want, I prefer to use "Data" as name, so that the code deals with a generic "Data" space, even though the user sees "Events" in the breadcrumbs.

...

On the other hand if the application pages end up directly inside the main page, then e.g. you cannot have a category "Code" in the Blog. (You cannot have a blog post with it either, but that might be a smaller nuisance)

Good point, and another reason to group the application data in nested spaces under the application space.

Thanks, Marius

---

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

Hi Ludovic, On 20 Nov 2015 at 19:30:26, Ludovic Dubost ([email protected](mailto:[email protected])) wrote:

On this subject, while showing 7.3 in an internal meeting, we saw that the Data page/space is the parent of all content pages in an AWM, but does not actually exist, so in the breadcrumb if you click on "Data" you get an error.

Thanks for reporting, see http://jira.xwiki.org/browse/XWIKI-12836# -Vincent

Ludovic

--*Ludovic Dubost* *Founder and CEO* [email protected] skype: ldubost Blog: http://blog.ludovic.org

On Fri, Nov 20, 2015 at 5:10 PM, Anca Luca wrote:

...

On Sat, Nov 14, 2015 at 3:17 PM, [email protected] wrote:

...

Hi Anca, On 14 Nov 2015 at 10:57:24, Marius Dumitru Florea ( [email protected]) wrote:

Hi Anca,

On Fri, Nov 13, 2015 at 8:51 PM, Anca Luca wrote:

...

Hello all,

my 2 cents on the "Data" or "Entries" subspace. ( But too late, since I see the issue was already closed :( ) Thanks for taking the time to participate.

...

I'm afraid that, even if technically it seems like a nice idea, it's not that nice for a "regular non-developer user" which perceive an application as only having data.

...

They don't need to and won't know that the code of that application is also stored on the wiki, in another subspace that is called "Code".

The Code space is still hidden so a regular user doesn't see it. There's no change in this regard.

...

There is complaint about the size and the amount of bloat in the XWiki URLS (the /xwiki/bin/view/ part) and this would be an extra one, for the case of applications. I don't think url rewrite should be considered so easily as an option because it's technically not so easy to achieve and I think that there can be an issue with colision (e.g. between MyApp/WebPreferences and MyApp/Data/WebPreferences).

So you think having MyApp and MyAppCode is better? You need to read the whole discussion thread and see that we’ve discussed about what you said already and we’ve weighted pros and cons to decide in the end that all things considered the Code and Data subspaces were probably the best solution.

...

If you think they are not, please make a proposal that you think would be better (ideally taking into account the arguments that we’ve already discussed) and we can discuss updating what’s been already done.

Actually, I read the discussion and I re-read it now. And, depending on how the "delete application data" is implemented (IIRC In the UI now) we could more go for detailed delete options (by default and in the app withim minutes itself). All the arguments that were brought in the discussion are correct, I just think that in some of them the 80-20 rule was wrongly estimated: * deleting a whole application data is frequent, but not _that_ frequent (20%). * it was said that a url rewrite should be doable (people really bothered by the Data particle should be able to do it). No, it's not that easy (less than 20% of the people bothered by the Data particle can do it). * less than 20% of usecases have an application within minutes that has two data spaces. Actually, I am wondering how is that an app within minutes still, because out of my knowledge this is not a known feature of app within minutes, and it means that some customization has been done to that application. For me, if an application was customized, it's still an application but not "within minutes" anymore. * if we're talking about applications in general, I think just as frequent is the case when the same application has multiple data spaces (e.g. having multiple blogs, each in a different space, in a different point in the hierarchy). Having multiple subspaces in the application space would not help much in this case. * for the rights issue, in 80% of the cases the code authors are data authors as well, there are just additional rights on the code (sub) space, so it's normal that code space inherits from app space. * deleting a space without some of its subspaces is a larger problem than app within minutes, so a more generic solution for that could be interesting. Also, I think it would be a frequent problem (80%), so having a flexible solution for it can be interesting.

Actually, the only thing on which I have a doubt that it would affect 80% of the usecases is the Data particle itself in the url :) (maybe more like 50-50 :D) . However, from the discussions in the thread I kind of had the feeling that it being annoying is considered to fall in the 20% bucket, compared to the other arguments which would be 80. I have the opposite feeling, as I explained above in the bullet list.

It's a good thing that it's configurable, though.

In what concerns the more generic topic of best practices: In the cases of larger customizations that I met so far (on non-nested spaces, though), the isolation was much more important: all the code for all the applications and all the customizations is in one space, in order to be able to manage it together as a group (rights, UI settings, deployment, search, etc), while the data was spread around in spaces that are dedicated exclusively to data, potentially more data spaces for all the different areas of applications coded by that code. Note that this would not fit in the case of a standard app within minutes anyway. I haven't thought yet about how this strategy would adapt for nested spaces, if each code space should be nested under its application space or still keep it all isolated...

Thanks, Anca

...

...

But I guess this is really too late now... It’ s not too late. This was done recently and we can still tune things

if

...

there’s a better proposal.

The location where the application stores its data is configurable. What we need (and the topic of this thread) is a best practice, ie. what’s used by default. We want apps by default to use these best practices, even if they’re configurable (that should be the exception). So it would be nice to have Anca and all the devs on this list to agree to use the best practices :)

Thanks

-Vincent

Thanks, Marius

...

Thanks, Anca

On Tue, Oct 27, 2015 at 11:34 AM, Guillaume "Louis-Marie" Delhumeau < [email protected]> wrote:

...

Hello.

Why not using "Entries" instead of "Data" for the name? It will be

shown

...

...

both in the URL and in the breadcrumb, and fit with most of the use-cases.

Users can still change the title of the "Entries" space to have a more specific name such as "Ideas", "Meetings", etc...

Just my 2 cents.

2015-10-26 10:45 GMT+01:00 Marius Dumitru Florea < [email protected]>:

...

On Fri, Oct 23, 2015 at 5:06 PM, Clemens Klein-Robbenhaar < [email protected]> wrote:

> > > On Wed, Sep 30, 2015 at 11:16 AM, Guillaume "Louis-Marie" Delhumeau < > > [email protected]> wrote: > > > >> 2015-09-30 10:58 GMT+02:00 [email protected] < [email protected] : > >> > >>> > >>> On 30 Sep 2015 at 10:53:48, Thomas Mortagne ( [email protected] > >>> (mailto:[email protected])) wrote: > >>> > >>>> I think what I like best is some option in the refactoring API to > >>>> indicate that you want to delete only final documents in the space (so > >>>> skipping space home page and spaces). > >>> > >>> That could be interesting for some use cases but it’s risky for this > one. > >>> Several apps may generate terminal pages and users could create > terminal > >>> pages in app spaces too. So that would not just remove the app > technical > >>> pages, it could remove more. > >>> > >> > >> The idea of Thomas is an option to only delete *terminal* pages located > in > >> the space with a depth of 1. Said differently, the direct and terminal > >> children of the page. > >> > >> This way, you can delete all data located in the space without removing > the > >> code (because the code would be located in a deeper depth), but it works > >> only if the app generates data as terminal pages. It is the case right > now, > >> but new apps should work differently and create their data as regular > >> Nested Pages. > >> > > > > I don't agree at all on this later statement. New apps _may_ work > > differently and create nested pages, but it _should_ not. > > Anyway, this is why I am wondering about properly separating WebHome, > Code > > and Data. > > I do not think we need stable names, but the structure matter. If Data > does > > not look nice, you may leave apps decide for themselves, the rules being > > put your data in subspaces, and code in the Code subspace, or something > > like that. Please note that using "space" in the previous rules looks bad > > to me, since we do not have space anymore ;) > > > [...] > >

> Just another random thought: some applications might really want to have > two "data" spaces; > for example currently in the blog you cannot have a category and a blog > post with the same name. > If both end up in their respective "subfolders" "Blog.Posts" and > "Blog.Categories", the problem goes away. >

Indeed, but I don't think it contradicts the rule. IMO the best practice should be to group the application data in one or more subspaces under the application space. If the application generates only one type of data (e.g. Events) then it makes sense to have only one Data subspace. If the application generates two or more types of data (Categories and Posts) then it may need more subspaces. The only question is whether we should group these subspaces under a Data subspace, e.g.

App / Data / Categories

or leave them directly under the application space:

App / Categories

I prefer the second option.

Another thing to decide is whether the Data space should be named "Data" or some domain-specific name. Considering that we can set the title of the home page to anything we want, I prefer to use "Data" as name, so that the code deals with a generic "Data" space, even though the user sees "Events" in the breadcrumbs.

> On the other hand if the application pages end up directly inside the main > page, then e.g. you cannot have a category "Code" in the Blog. > (You cannot have a blog post with it either, but that might be a smaller > nuisance) >

Good point, and another reason to group the application data in nested spaces under the application space.

Thanks, Marius

---

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

So basically you want to introduce the "Program Files" of XWiki ? +1 for A other important pros IMO: already protected against edition by anyone else than admin, allow extension to do have to deal with that with some hypothetical "XWikiAdminGroup" group that may or may not exist On Fri, Apr 29, 2016 at 3:31 PM, Denis Gervalle <[email protected]> wrote:

Hi Devs,

Appart from the “conventional” application that manage their own data subset, there is more general application, that are either providing wiki-wide feature without data, or that are managing data in the whole wiki, providing additional features. For example, the Administration application, the CKEditor, … and other application actually mixed in the XWiki space.

For those applications, the code/data space separation has no real meaning, but I think it would also be nice to have the code of those applications under a common root, in place of having all of them creating a space at the root of the wiki. For example, currently the UI of the CKEditor is in a CKEditor space at the root, and I have no easy way to distinguish it from a normal space (except that it is invisible), and it is also holding a space name. I agree, there is little chance that a user wants to create an editorial space by the name, but it could happen, and depends on the application space name, there could be more common cases.

My proposal is to put such application inside a common space. There is several options for the name of that space:

A) Reuse the existing “XWiki” space Pros: - not holding a new name at root - always available - nice place to move application already mixup in that space to their own space Cons: - it is currently a mess - it holds users (but shouldn’t we move them to Users space ? I know it is not easy)

B) Create a new space for this purpose B1) XWikiApplications B2) XWikiExtensions B3) WikiApplications B4) WikiExtensions B5) Wiki B6) … ?

wdyt ?

On Fri, Nov 20, 2015 at 9:53 PM, [email protected] <[email protected]> wrote:

...

Hi Ludovic,

On 20 Nov 2015 at 19:30:26, Ludovic Dubost ([email protected](mailto: [email protected])) wrote:

...

On this subject, while showing 7.3 in an internal meeting, we saw that the Data page/space is the parent of all content pages in an AWM, but does not actually exist, so in the breadcrumb if you click on "Data" you get an error.

Thanks for reporting, see http://jira.xwiki.org/browse/XWIKI-12836#

-Vincent

...

Ludovic

--*Ludovic Dubost* *Founder and CEO* [email protected] skype: ldubost Blog: http://blog.ludovic.org

On Fri, Nov 20, 2015 at 5:10 PM, Anca Luca wrote:

...

On Sat, Nov 14, 2015 at 3:17 PM, [email protected] wrote:

...

Hi Anca, On 14 Nov 2015 at 10:57:24, Marius Dumitru Florea ( [email protected]) wrote:

Hi Anca,

On Fri, Nov 13, 2015 at 8:51 PM, Anca Luca wrote:

...

Hello all,

my 2 cents on the "Data" or "Entries" subspace. ( But too late, since I see the issue was already closed :( ) Thanks for taking the time to participate.

...

I'm afraid that, even if technically it seems like a nice idea, it's not that nice for a "regular non-developer user" which perceive an application as only having data.

...

They don't need to and won't know that the code of that application is also stored on the wiki, in another subspace that is called "Code".

The Code space is still hidden so a regular user doesn't see it. There's no change in this regard.

...

There is complaint about the size and the amount of bloat in the XWiki URLS (the /xwiki/bin/view/ part) and this would be an extra one, for the case of applications. I don't think url rewrite should be considered so easily as an option because it's technically not so easy to achieve and I think that there can be an issue with colision (e.g. between MyApp/WebPreferences and MyApp/Data/WebPreferences).

So you think having MyApp and MyAppCode is better? You need to read the whole discussion thread and see that we’ve discussed about what you said already and we’ve weighted pros and cons to decide in the end that all things considered the Code and Data subspaces were probably the best solution.

...

If you think they are not, please make a proposal that you think would be better (ideally taking into account the arguments that we’ve already discussed) and we can discuss updating what’s been already done.

Actually, I read the discussion and I re-read it now. And, depending on how the "delete application data" is implemented (IIRC In the UI now) we could more go for detailed delete options (by default and in the app withim minutes itself). All the arguments that were brought in the discussion are correct, I just think that in some of them the 80-20 rule was wrongly estimated: * deleting a whole application data is frequent, but not _that_ frequent (20%). * it was said that a url rewrite should be doable (people really bothered by the Data particle should be able to do it). No, it's not that easy (less than 20% of the people bothered by the Data particle can do it). * less than 20% of usecases have an application within minutes that has two data spaces. Actually, I am wondering how is that an app within minutes still, because out of my knowledge this is not a known feature of app within minutes, and it means that some customization has been done to that application. For me, if an application was customized, it's still an application but not "within minutes" anymore. * if we're talking about applications in general, I think just as frequent is the case when the same application has multiple data spaces (e.g. having multiple blogs, each in a different space, in a different point in the hierarchy). Having multiple subspaces in the application space would not help much in this case. * for the rights issue, in 80% of the cases the code authors are data authors as well, there are just additional rights on the code (sub) space, so it's normal that code space inherits from app space. * deleting a space without some of its subspaces is a larger problem than app within minutes, so a more generic solution for that could be interesting. Also, I think it would be a frequent problem (80%), so having a flexible solution for it can be interesting.

Actually, the only thing on which I have a doubt that it would affect 80% of the usecases is the Data particle itself in the url :) (maybe more like 50-50 :D) . However, from the discussions in the thread I kind of had the feeling that it being annoying is considered to fall in the 20% bucket, compared to the other arguments which would be 80. I have the opposite feeling, as I explained above in the bullet list.

It's a good thing that it's configurable, though.

In what concerns the more generic topic of best practices: In the cases of larger customizations that I met so far (on non-nested spaces, though), the isolation was much more important: all the code for all the applications and all the customizations is in one space, in order to be able to manage it together as a group (rights, UI settings, deployment, search, etc), while the data was spread around in spaces that are dedicated exclusively to data, potentially more data spaces for all the different areas of applications coded by that code. Note that this would not fit in the case of a standard app within minutes anyway. I haven't thought yet about how this strategy would adapt for nested spaces, if each code space should be nested under its application space or still keep it all isolated...

Thanks, Anca

...

...

But I guess this is really too late now... It’ s not too late. This was done recently and we can still tune

things if

...

there’s a better proposal.

The location where the application stores its data is configurable. What we need (and the topic of this thread) is a best practice, ie. what’s used by default. We want apps by default to use these best practices, even if they’re configurable (that should be the exception). So it would be nice to have Anca and all the devs on this list to agree to use the best practices :)

Thanks

-Vincent

Thanks, Marius

...

Thanks, Anca

On Tue, Oct 27, 2015 at 11:34 AM, Guillaume "Louis-Marie"

Delhumeau <

...

[email protected]> wrote:

> Hello. > > Why not using "Entries" instead of "Data" for the name? It will be shown > both in the URL and in the breadcrumb, and fit with most of the use-cases. > > Users can still change the title of the "Entries" space to have a more > specific name such as "Ideas", "Meetings", etc... > > Just my 2 cents. > > 2015-10-26 10:45 GMT+01:00 Marius Dumitru Florea < > [email protected]>: > > > On Fri, Oct 23, 2015 at 5:06 PM, Clemens Klein-Robbenhaar < > > [email protected]> wrote: > > > > > > > > > On Wed, Sep 30, 2015 at 11:16 AM, Guillaume "Louis-Marie" Delhumeau < > > > > [email protected]> wrote: > > > > > > > >> 2015-09-30 10:58 GMT+02:00 [email protected] < [email protected] >: > > > >> > > > >>> > > > >>> On 30 Sep 2015 at 10:53:48, Thomas Mortagne ( > > [email protected] > > > >>> (mailto:[email protected])) wrote: > > > >>> > > > >>>> I think what I like best is some option in the refactoring API to > > > >>>> indicate that you want to delete only final documents in the space > > (so > > > >>>> skipping space home page and spaces). > > > >>> > > > >>> That could be interesting for some use cases but it’s risky for > this > > > one. > > > >>> Several apps may generate terminal pages and users could create > > > terminal > > > >>> pages in app spaces too. So that would not just remove the app > > > technical > > > >>> pages, it could remove more. > > > >>> > > > >> > > > >> The idea of Thomas is an option to only delete *terminal* pages > > located > > > in > > > >> the space with a depth of 1. Said differently, the direct and > terminal > > > >> children of the page. > > > >> > > > >> This way, you can delete all data located in the space without > > removing > > > the > > > >> code (because the code would be located in a deeper depth), but it > > works > > > >> only if the app generates data as terminal pages. It is the case > right > > > now, > > > >> but new apps should work differently and create their data as > regular > > > >> Nested Pages. > > > >> > > > > > > > > I don't agree at all on this later statement. New apps _may_ work > > > > differently and create nested pages, but it _should_ not. > > > > Anyway, this is why I am wondering about properly separating WebHome, > > > Code > > > > and Data. > > > > I do not think we need stable names, but the structure matter. If > Data > > > does > > > > not look nice, you may leave apps decide for themselves, the rules > > being > > > > put your data in subspaces, and code in the Code subspace, or > something > > > > like that. Please note that using "space" in the previous rules looks > > bad > > > > to me, since we do not have space anymore ;) > > > > > > > [...] > > > > > > > > > > > Just another random thought: some applications might really want to > have > > > two "data" spaces; > > > for example currently in the blog you cannot have a category and a blog > > > post with the same name. > > > If both end up in their respective "subfolders" "Blog.Posts" and > > > "Blog.Categories", the problem goes away. > > > > > > > Indeed, but I don't think it contradicts the rule. IMO the best practice > > should be to group the application data in one or more subspaces under > the > > application space. If the application generates only one type of data > (e.g. > > Events) then it makes sense to have only one Data subspace. If the > > application generates two or more types of data (Categories and Posts) > then > > it may need more subspaces. The only question is whether we should group > > these subspaces under a Data subspace, e.g. > > > > App / Data / Categories > > > > or leave them directly under the application space: > > > > App / Categories > > > > I prefer the second option. > > > > Another thing to decide is whether the Data space should be named "Data" > or > > some domain-specific name. Considering that we can set the title of the > > home page to anything we want, I prefer to use "Data" as name, so that > the > > code deals with a generic "Data" space, even though the user sees > "Events" > > in the breadcrumbs. > > > > > > > On the other hand if the application pages end up directly inside the > > main > > > page, then e.g. you cannot have a category "Code" in the Blog. > > > (You cannot have a blog post with it either, but that might be a > smaller > > > nuisance) > > > > > > > Good point, and another reason to group the application data in nested > > spaces under the application space. > > > > Thanks, > > Marius

---

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

---

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

-- Denis Gervalle SOFTEC sa - CEO _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Thomas Mortagne

On 02 May 2016, at 09:56, Vincent Massol <[email protected]> wrote:

...

On 02 May 2016, at 09:32, Thomas Mortagne <[email protected]> wrote:

So basically you want to introduce the "Program Files" of XWiki ?

Not quite. Program Files is for all apps (see below for a real “program files” proposal).

From Denis’ proposal I also prefer option A.

Denis Proposal A ==============

Right now I think the proposal is twofold: * Apps with Data continue to create a top level Space containing both Code and Data (i.e. apps that generate user-related data) * Apps without Data under the XWiki space (option A)

Example:

[ROOT] |_ XWiki |_ Applications |_ CKEditor |_ <app pages, i.e. technical pages, no data for the user, can contain config data> |_ Blog |_ Code |_ <app pages, i.e. technical pages, no data for the user, can contain config data> |_ Data |_ <blog-generated user data, i.e. blog posts>

"Program Files” Proposal ====================

* Have all apps under the XWiki space (ie the “Program Files” of Windows for XWiki) * Have user-related data in a nested space under the User profile’s page (would need to be converted to a space first) * Have data generated for users (wiki wide) in some other location. Right now that would be a top level space named after the app.

So in this proposal we would have for example:

[ROOT] |_ XWiki |_ Applications |_ CKEditor |_ <app pages, i.e. technical pages, no data for the user, can contain config data> |_ Blog |_ <app pages, i.e. technical pages, no data for the user, can contain config data> |_ Blog |_ <blog-generated user data, i.e. blog posts>

Pros: - All apps located in the same place - App Code protected by default (but can be overridden if need be) - Nicer for users since that would solve the “Data”-space-in-the-breadcrumb issue (i.e. they wouldn’t see /Data/ in the breadcrumb when on app-generated pages)

Little note for WebHomes of apps: * Apps that have UI (WebHome for example) should provide a WebHome for users (i.e. in Blog.WebHome in the example above). That WebHome can do an include of generic content from XWiki.Applications.Blog.* pages. FTR this is what the FAQ apps already does so that the user doesn’t himself on a page with FAQCode in the breadcrumb. Thanks -Vincent

WDYT?

Thanks -Vincent

...

+1 for A

other important pros IMO: already protected against edition by anyone else than admin, allow extension to do have to deal with that with some hypothetical "XWikiAdminGroup" group that may or may not exist

On Fri, Apr 29, 2016 at 3:31 PM, Denis Gervalle <[email protected]> wrote:

...

Hi Devs,

Appart from the “conventional” application that manage their own data subset, there is more general application, that are either providing wiki-wide feature without data, or that are managing data in the whole wiki, providing additional features. For example, the Administration application, the CKEditor, … and other application actually mixed in the XWiki space.

For those applications, the code/data space separation has no real meaning, but I think it would also be nice to have the code of those applications under a common root, in place of having all of them creating a space at the root of the wiki. For example, currently the UI of the CKEditor is in a CKEditor space at the root, and I have no easy way to distinguish it from a normal space (except that it is invisible), and it is also holding a space name. I agree, there is little chance that a user wants to create an editorial space by the name, but it could happen, and depends on the application space name, there could be more common cases.

My proposal is to put such application inside a common space. There is several options for the name of that space:

A) Reuse the existing “XWiki” space Pros: - not holding a new name at root - always available - nice place to move application already mixup in that space to their own space Cons: - it is currently a mess - it holds users (but shouldn’t we move them to Users space ? I know it is not easy)

B) Create a new space for this purpose B1) XWikiApplications B2) XWikiExtensions B3) WikiApplications B4) WikiExtensions B5) Wiki B6) … ?

wdyt ?

On Fri, Nov 20, 2015 at 9:53 PM, [email protected] <[email protected]> wrote:

...

Hi Ludovic,

On 20 Nov 2015 at 19:30:26, Ludovic Dubost ([email protected](mailto: [email protected])) wrote:

...

On this subject, while showing 7.3 in an internal meeting, we saw that the Data page/space is the parent of all content pages in an AWM, but does not actually exist, so in the breadcrumb if you click on "Data" you get an error.

Thanks for reporting, see http://jira.xwiki.org/browse/XWIKI-12836#

-Vincent

...

Ludovic

--*Ludovic Dubost* *Founder and CEO* [email protected] skype: ldubost Blog: http://blog.ludovic.org

On Fri, Nov 20, 2015 at 5:10 PM, Anca Luca wrote:

...

On Sat, Nov 14, 2015 at 3:17 PM, [email protected] wrote:

> Hi Anca, > On 14 Nov 2015 at 10:57:24, Marius Dumitru Florea ( > [email protected]) wrote: > > Hi Anca, > > On Fri, Nov 13, 2015 at 8:51 PM, Anca Luca wrote: > >> Hello all, >> >> my 2 cents on the "Data" or "Entries" subspace. >> ( But too late, since I see the issue was already closed :( ) > Thanks for taking the time to participate. > >> I'm afraid that, even if technically it seems like a nice idea, it's not >> that nice for a "regular non-developer user" which perceive an > application >> as only having data. > > > >> They don't need to and won't know that the code of >> that application is also stored on the wiki, in another subspace that is >> called "Code". > > > The Code space is still hidden so a regular user doesn't see it. There's no > change in this regard. > > >> There is complaint about the size and the amount of bloat in >> the XWiki URLS (the /xwiki/bin/view/ part) and this would be an extra > one, >> for the case of applications. I don't think url rewrite should be >> considered so easily as an option because it's technically not so easy to >> achieve and I think that there can be an issue with colision (e.g. > between >> MyApp/WebPreferences and MyApp/Data/WebPreferences). >> > > So you think having MyApp and MyAppCode is better? > You need to read the whole discussion thread and see that we’ve discussed > about what you said already and we’ve weighted pros and cons to decide in > the end that all things considered the Code and Data subspaces were > probably the best solution.

> If you think they are not, please make a proposal that you think would be > better (ideally taking into account the arguments that we’ve already > discussed) and we can discuss updating what’s been already done. >

Actually, I read the discussion and I re-read it now. And, depending on how the "delete application data" is implemented (IIRC In the UI now) we could more go for detailed delete options (by default and in the app withim minutes itself). All the arguments that were brought in the discussion are correct, I just think that in some of them the 80-20 rule was wrongly estimated: * deleting a whole application data is frequent, but not _that_ frequent (20%). * it was said that a url rewrite should be doable (people really bothered by the Data particle should be able to do it). No, it's not that easy (less than 20% of the people bothered by the Data particle can do it). * less than 20% of usecases have an application within minutes that has two data spaces. Actually, I am wondering how is that an app within minutes still, because out of my knowledge this is not a known feature of app within minutes, and it means that some customization has been done to that application. For me, if an application was customized, it's still an application but not "within minutes" anymore. * if we're talking about applications in general, I think just as frequent is the case when the same application has multiple data spaces (e.g. having multiple blogs, each in a different space, in a different point in the hierarchy). Having multiple subspaces in the application space would not help much in this case. * for the rights issue, in 80% of the cases the code authors are data authors as well, there are just additional rights on the code (sub) space, so it's normal that code space inherits from app space. * deleting a space without some of its subspaces is a larger problem than app within minutes, so a more generic solution for that could be interesting. Also, I think it would be a frequent problem (80%), so having a flexible solution for it can be interesting.

Actually, the only thing on which I have a doubt that it would affect 80% of the usecases is the Data particle itself in the url :) (maybe more like 50-50 :D) . However, from the discussions in the thread I kind of had the feeling that it being annoying is considered to fall in the 20% bucket, compared to the other arguments which would be 80. I have the opposite feeling, as I explained above in the bullet list.

It's a good thing that it's configurable, though.

In what concerns the more generic topic of best practices: In the cases of larger customizations that I met so far (on non-nested spaces, though), the isolation was much more important: all the code for all the applications and all the customizations is in one space, in order to be able to manage it together as a group (rights, UI settings, deployment, search, etc), while the data was spread around in spaces that are dedicated exclusively to data, potentially more data spaces for all the different areas of applications coded by that code. Note that this would not fit in the case of a standard app within minutes anyway. I haven't thought yet about how this strategy would adapt for nested spaces, if each code space should be nested under its application space or still keep it all isolated...

Thanks, Anca

> >> But I guess this is really too late now... > It’ s not too late. This was done recently and we can still tune things if > there’s a better proposal. > > The location where the application stores its data is configurable. > What we need (and the topic of this thread) is a best practice, ie. what’s > used by default. We want apps by default to use these best practices, even > if they’re configurable (that should be the exception). So it would be nice > to have Anca and all the devs on this list to agree to use the best > practices :) > > Thanks > > -Vincent > > Thanks, > Marius > > >> >> Thanks, >> Anca >> >> On Tue, Oct 27, 2015 at 11:34 AM, Guillaume "Louis-Marie" Delhumeau < >> [email protected]> wrote: >> >>> Hello. >>> >>> Why not using "Entries" instead of "Data" for the name? It will be > shown >>> both in the URL and in the breadcrumb, and fit with most of the >> use-cases. >>> >>> Users can still change the title of the "Entries" space to have a more >>> specific name such as "Ideas", "Meetings", etc... >>> >>> Just my 2 cents. >>> >>> 2015-10-26 10:45 GMT+01:00 Marius Dumitru Florea < >>> [email protected]>: >>> >>>> On Fri, Oct 23, 2015 at 5:06 PM, Clemens Klein-Robbenhaar < >>>> [email protected]> wrote: >>>> >>>>> >>>>>> On Wed, Sep 30, 2015 at 11:16 AM, Guillaume "Louis-Marie" >> Delhumeau < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> 2015-09-30 10:58 GMT+02:00 [email protected] < > [email protected] >>> : >>>>>>> >>>>>>>> >>>>>>>> On 30 Sep 2015 at 10:53:48, Thomas Mortagne ( >>>> [email protected] >>>>>>>> (mailto:[email protected])) wrote: >>>>>>>> >>>>>>>>> I think what I like best is some option in the refactoring API >> to >>>>>>>>> indicate that you want to delete only final documents in the >> space >>>> (so >>>>>>>>> skipping space home page and spaces). >>>>>>>> >>>>>>>> That could be interesting for some use cases but it’s risky for >>> this >>>>> one. >>>>>>>> Several apps may generate terminal pages and users could create >>>>> terminal >>>>>>>> pages in app spaces too. So that would not just remove the app >>>>> technical >>>>>>>> pages, it could remove more. >>>>>>>> >>>>>>> >>>>>>> The idea of Thomas is an option to only delete *terminal* pages >>>> located >>>>> in >>>>>>> the space with a depth of 1. Said differently, the direct and >>> terminal >>>>>>> children of the page. >>>>>>> >>>>>>> This way, you can delete all data located in the space without >>>> removing >>>>> the >>>>>>> code (because the code would be located in a deeper depth), but > it >>>> works >>>>>>> only if the app generates data as terminal pages. It is the case >>> right >>>>> now, >>>>>>> but new apps should work differently and create their data as >>> regular >>>>>>> Nested Pages. >>>>>>> >>>>>> >>>>>> I don't agree at all on this later statement. New apps _may_ work >>>>>> differently and create nested pages, but it _should_ not. >>>>>> Anyway, this is why I am wondering about properly separating >> WebHome, >>>>> Code >>>>>> and Data. >>>>>> I do not think we need stable names, but the structure matter. If >>> Data >>>>> does >>>>>> not look nice, you may leave apps decide for themselves, the > rules >>>> being >>>>>> put your data in subspaces, and code in the Code subspace, or >>> something >>>>>> like that. Please note that using "space" in the previous rules >> looks >>>> bad >>>>>> to me, since we do not have space anymore ;) >>>>>> >>>>> [...] >>>>> >>>>> >>>> >>>>> Just another random thought: some applications might really want to >>> have >>>>> two "data" spaces; >>>>> for example currently in the blog you cannot have a category and a >> blog >>>>> post with the same name. >>>>> If both end up in their respective "subfolders" "Blog.Posts" and >>>>> "Blog.Categories", the problem goes away. >>>>> >>>> >>>> Indeed, but I don't think it contradicts the rule. IMO the best >> practice >>>> should be to group the application data in one or more subspaces > under >>> the >>>> application space. If the application generates only one type of data >>> (e.g. >>>> Events) then it makes sense to have only one Data subspace. If the >>>> application generates two or more types of data (Categories and > Posts) >>> then >>>> it may need more subspaces. The only question is whether we should >> group >>>> these subspaces under a Data subspace, e.g. >>>> >>>> App / Data / Categories >>>> >>>> or leave them directly under the application space: >>>> >>>> App / Categories >>>> >>>> I prefer the second option. >>>> >>>> Another thing to decide is whether the Data space should be named >> "Data" >>> or >>>> some domain-specific name. Considering that we can set the title of > the >>>> home page to anything we want, I prefer to use "Data" as name, so > that >>> the >>>> code deals with a generic "Data" space, even though the user sees >>> "Events" >>>> in the breadcrumbs. >>>> >>>> >>>>> On the other hand if the application pages end up directly inside > the >>>> main >>>>> page, then e.g. you cannot have a category "Code" in the Blog. >>>>> (You cannot have a blog post with it either, but that might be a >>> smaller >>>>> nuisance) >>>>> >>>> >>>> Good point, and another reason to group the application data in > nested >>>> spaces under the application space. >>>> >>>> Thanks, >>>> Marius >

On 02 May 2016, at 09:56, Vincent Massol <[email protected]> wrote:

...

On 02 May 2016, at 09:32, Thomas Mortagne <[email protected]> wrote:

So basically you want to introduce the "Program Files" of XWiki ?

Not quite. Program Files is for all apps (see below for a real “program files” proposal).

From Denis’ proposal I also prefer option A.

Denis Proposal A ==============

Right now I think the proposal is twofold: * Apps with Data continue to create a top level Space containing both Code and Data (i.e. apps that generate user-related data) * Apps without Data under the XWiki space (option A)

Example:

[ROOT] |_ XWiki |_ Applications |_ CKEditor |_ <app pages, i.e. technical pages, no data for the user, can contain config data> |_ Blog |_ Code |_ <app pages, i.e. technical pages, no data for the user, can contain config data> |_ Data |_ <blog-generated user data, i.e. blog posts>

"Program Files” Proposal ====================

* Have all apps under the XWiki space (ie the “Program Files” of Windows for XWiki) * Have user-related data in a nested space under the User profile’s page (would need to be converted to a space first) * Have data generated for users (wiki wide) in some other location. Right now that would be a top level space named after the app.

So in this proposal we would have for example:

[ROOT] |_ XWiki |_ Applications |_ CKEditor |_ <app pages, i.e. technical pages, no data for the user, can contain config data> |_ Blog |_ <app pages, i.e. technical pages, no data for the user, can contain config data> |_ Blog |_ <blog-generated user data, i.e. blog posts>

There’s also an alternative if we wish to cleanly separate app-generated data from content spaces, which is to put all app-generated data under a different root. For example: [ROOT] |_ XWiki |_ Applications |_ CKEditor |_ <app pages, i.e. technical pages, no data for the user, can contain config data> |_ Blog |_ <app pages, i.e. technical pages, no data for the user, can contain config data> |_ Applications (or another name - FTR Windows uses AppData but it’s hidden) |_ Blog |_ <blog-generated user data, i.e. blog posts> |_ <content spaces under root> Thanks -Vincent

Pros: - All apps located in the same place - App Code protected by default (but can be overridden if need be) - Nicer for users since that would solve the “Data”-space-in-the-breadcrumb issue (i.e. they wouldn’t see /Data/ in the breadcrumb when on app-generated pages)

WDYT?

Thanks -Vincent

...

+1 for A

other important pros IMO: already protected against edition by anyone else than admin, allow extension to do have to deal with that with some hypothetical "XWikiAdminGroup" group that may or may not exist

On Fri, Apr 29, 2016 at 3:31 PM, Denis Gervalle <[email protected]> wrote:

...

Hi Devs,

Appart from the “conventional” application that manage their own data subset, there is more general application, that are either providing wiki-wide feature without data, or that are managing data in the whole wiki, providing additional features. For example, the Administration application, the CKEditor, … and other application actually mixed in the XWiki space.

For those applications, the code/data space separation has no real meaning, but I think it would also be nice to have the code of those applications under a common root, in place of having all of them creating a space at the root of the wiki. For example, currently the UI of the CKEditor is in a CKEditor space at the root, and I have no easy way to distinguish it from a normal space (except that it is invisible), and it is also holding a space name. I agree, there is little chance that a user wants to create an editorial space by the name, but it could happen, and depends on the application space name, there could be more common cases.

My proposal is to put such application inside a common space. There is several options for the name of that space:

A) Reuse the existing “XWiki” space Pros: - not holding a new name at root - always available - nice place to move application already mixup in that space to their own space Cons: - it is currently a mess - it holds users (but shouldn’t we move them to Users space ? I know it is not easy)

B) Create a new space for this purpose B1) XWikiApplications B2) XWikiExtensions B3) WikiApplications B4) WikiExtensions B5) Wiki B6) … ?

wdyt ?

On Fri, Nov 20, 2015 at 9:53 PM, [email protected] <[email protected]> wrote:

...

Hi Ludovic,

On 20 Nov 2015 at 19:30:26, Ludovic Dubost ([email protected](mailto: [email protected])) wrote:

...

On this subject, while showing 7.3 in an internal meeting, we saw that the Data page/space is the parent of all content pages in an AWM, but does not actually exist, so in the breadcrumb if you click on "Data" you get an error.

Thanks for reporting, see http://jira.xwiki.org/browse/XWIKI-12836#

-Vincent

...

Ludovic

--*Ludovic Dubost* *Founder and CEO* [email protected] skype: ldubost Blog: http://blog.ludovic.org

On Fri, Nov 20, 2015 at 5:10 PM, Anca Luca wrote:

...

On Sat, Nov 14, 2015 at 3:17 PM, [email protected] wrote:

> Hi Anca, > On 14 Nov 2015 at 10:57:24, Marius Dumitru Florea ( > [email protected]) wrote: > > Hi Anca, > > On Fri, Nov 13, 2015 at 8:51 PM, Anca Luca wrote: > >> Hello all, >> >> my 2 cents on the "Data" or "Entries" subspace. >> ( But too late, since I see the issue was already closed :( ) > Thanks for taking the time to participate. > >> I'm afraid that, even if technically it seems like a nice idea, it's not >> that nice for a "regular non-developer user" which perceive an > application >> as only having data. > > > >> They don't need to and won't know that the code of >> that application is also stored on the wiki, in another subspace that is >> called "Code". > > > The Code space is still hidden so a regular user doesn't see it. There's no > change in this regard. > > >> There is complaint about the size and the amount of bloat in >> the XWiki URLS (the /xwiki/bin/view/ part) and this would be an extra > one, >> for the case of applications. I don't think url rewrite should be >> considered so easily as an option because it's technically not so easy to >> achieve and I think that there can be an issue with colision (e.g. > between >> MyApp/WebPreferences and MyApp/Data/WebPreferences). >> > > So you think having MyApp and MyAppCode is better? > You need to read the whole discussion thread and see that we’ve discussed > about what you said already and we’ve weighted pros and cons to decide in > the end that all things considered the Code and Data subspaces were > probably the best solution.

> If you think they are not, please make a proposal that you think would be > better (ideally taking into account the arguments that we’ve already > discussed) and we can discuss updating what’s been already done. >

Actually, I read the discussion and I re-read it now. And, depending on how the "delete application data" is implemented (IIRC In the UI now) we could more go for detailed delete options (by default and in the app withim minutes itself). All the arguments that were brought in the discussion are correct, I just think that in some of them the 80-20 rule was wrongly estimated: * deleting a whole application data is frequent, but not _that_ frequent (20%). * it was said that a url rewrite should be doable (people really bothered by the Data particle should be able to do it). No, it's not that easy (less than 20% of the people bothered by the Data particle can do it). * less than 20% of usecases have an application within minutes that has two data spaces. Actually, I am wondering how is that an app within minutes still, because out of my knowledge this is not a known feature of app within minutes, and it means that some customization has been done to that application. For me, if an application was customized, it's still an application but not "within minutes" anymore. * if we're talking about applications in general, I think just as frequent is the case when the same application has multiple data spaces (e.g. having multiple blogs, each in a different space, in a different point in the hierarchy). Having multiple subspaces in the application space would not help much in this case. * for the rights issue, in 80% of the cases the code authors are data authors as well, there are just additional rights on the code (sub) space, so it's normal that code space inherits from app space. * deleting a space without some of its subspaces is a larger problem than app within minutes, so a more generic solution for that could be interesting. Also, I think it would be a frequent problem (80%), so having a flexible solution for it can be interesting.

Actually, the only thing on which I have a doubt that it would affect 80% of the usecases is the Data particle itself in the url :) (maybe more like 50-50 :D) . However, from the discussions in the thread I kind of had the feeling that it being annoying is considered to fall in the 20% bucket, compared to the other arguments which would be 80. I have the opposite feeling, as I explained above in the bullet list.

It's a good thing that it's configurable, though.

In what concerns the more generic topic of best practices: In the cases of larger customizations that I met so far (on non-nested spaces, though), the isolation was much more important: all the code for all the applications and all the customizations is in one space, in order to be able to manage it together as a group (rights, UI settings, deployment, search, etc), while the data was spread around in spaces that are dedicated exclusively to data, potentially more data spaces for all the different areas of applications coded by that code. Note that this would not fit in the case of a standard app within minutes anyway. I haven't thought yet about how this strategy would adapt for nested spaces, if each code space should be nested under its application space or still keep it all isolated...

Thanks, Anca

> >> But I guess this is really too late now... > It’ s not too late. This was done recently and we can still tune things if > there’s a better proposal. > > The location where the application stores its data is configurable. > What we need (and the topic of this thread) is a best practice, ie. what’s > used by default. We want apps by default to use these best practices, even > if they’re configurable (that should be the exception). So it would be nice > to have Anca and all the devs on this list to agree to use the best > practices :) > > Thanks > > -Vincent > > Thanks, > Marius > > >> >> Thanks, >> Anca >> >> On Tue, Oct 27, 2015 at 11:34 AM, Guillaume "Louis-Marie" Delhumeau < >> [email protected]> wrote: >> >>> Hello. >>> >>> Why not using "Entries" instead of "Data" for the name? It will be > shown >>> both in the URL and in the breadcrumb, and fit with most of the >> use-cases. >>> >>> Users can still change the title of the "Entries" space to have a more >>> specific name such as "Ideas", "Meetings", etc... >>> >>> Just my 2 cents. >>> >>> 2015-10-26 10:45 GMT+01:00 Marius Dumitru Florea < >>> [email protected]>: >>> >>>> On Fri, Oct 23, 2015 at 5:06 PM, Clemens Klein-Robbenhaar < >>>> [email protected]> wrote: >>>> >>>>> >>>>>> On Wed, Sep 30, 2015 at 11:16 AM, Guillaume "Louis-Marie" >> Delhumeau < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> 2015-09-30 10:58 GMT+02:00 [email protected] < > [email protected] >>> : >>>>>>> >>>>>>>> >>>>>>>> On 30 Sep 2015 at 10:53:48, Thomas Mortagne ( >>>> [email protected] >>>>>>>> (mailto:[email protected])) wrote: >>>>>>>> >>>>>>>>> I think what I like best is some option in the refactoring API >> to >>>>>>>>> indicate that you want to delete only final documents in the >> space >>>> (so >>>>>>>>> skipping space home page and spaces). >>>>>>>> >>>>>>>> That could be interesting for some use cases but it’s risky for >>> this >>>>> one. >>>>>>>> Several apps may generate terminal pages and users could create >>>>> terminal >>>>>>>> pages in app spaces too. So that would not just remove the app >>>>> technical >>>>>>>> pages, it could remove more. >>>>>>>> >>>>>>> >>>>>>> The idea of Thomas is an option to only delete *terminal* pages >>>> located >>>>> in >>>>>>> the space with a depth of 1. Said differently, the direct and >>> terminal >>>>>>> children of the page. >>>>>>> >>>>>>> This way, you can delete all data located in the space without >>>> removing >>>>> the >>>>>>> code (because the code would be located in a deeper depth), but > it >>>> works >>>>>>> only if the app generates data as terminal pages. It is the case >>> right >>>>> now, >>>>>>> but new apps should work differently and create their data as >>> regular >>>>>>> Nested Pages. >>>>>>> >>>>>> >>>>>> I don't agree at all on this later statement. New apps _may_ work >>>>>> differently and create nested pages, but it _should_ not. >>>>>> Anyway, this is why I am wondering about properly separating >> WebHome, >>>>> Code >>>>>> and Data. >>>>>> I do not think we need stable names, but the structure matter. If >>> Data >>>>> does >>>>>> not look nice, you may leave apps decide for themselves, the > rules >>>> being >>>>>> put your data in subspaces, and code in the Code subspace, or >>> something >>>>>> like that. Please note that using "space" in the previous rules >> looks >>>> bad >>>>>> to me, since we do not have space anymore ;) >>>>>> >>>>> [...] >>>>> >>>>> >>>> >>>>> Just another random thought: some applications might really want to >>> have >>>>> two "data" spaces; >>>>> for example currently in the blog you cannot have a category and a >> blog >>>>> post with the same name. >>>>> If both end up in their respective "subfolders" "Blog.Posts" and >>>>> "Blog.Categories", the problem goes away. >>>>> >>>> >>>> Indeed, but I don't think it contradicts the rule. IMO the best >> practice >>>> should be to group the application data in one or more subspaces > under >>> the >>>> application space. If the application generates only one type of data >>> (e.g. >>>> Events) then it makes sense to have only one Data subspace. If the >>>> application generates two or more types of data (Categories and > Posts) >>> then >>>> it may need more subspaces. The only question is whether we should >> group >>>> these subspaces under a Data subspace, e.g. >>>> >>>> App / Data / Categories >>>> >>>> or leave them directly under the application space: >>>> >>>> App / Categories >>>> >>>> I prefer the second option. >>>> >>>> Another thing to decide is whether the Data space should be named >> "Data" >>> or >>>> some domain-specific name. Considering that we can set the title of > the >>>> home page to anything we want, I prefer to use "Data" as name, so > that >>> the >>>> code deals with a generic "Data" space, even though the user sees >>> "Events" >>>> in the breadcrumbs. >>>> >>>> >>>>> On the other hand if the application pages end up directly inside > the >>>> main >>>>> page, then e.g. you cannot have a category "Code" in the Blog. >>>>> (You cannot have a blog post with it either, but that might be a >>> smaller >>>>> nuisance) >>>>> >>>> >>>> Good point, and another reason to group the application data in > nested >>>> spaces under the application space. >>>> >>>> Thanks, >>>> Marius >

Hi Guillaume,

On 02 May 2016, at 10:57, Guillaume Delhumeau <[email protected]> wrote:

Hello.

Thanks for raising this topic Denis. I think we need to take a decision on this.

Vincent: I like your proposal, except that we need to manage rights with caution. Right now, the "XWiki" space is protected and regular users cannot write content in it (except on their profile page). But regular users have the rights to use AWM, and with your proposal, the code generated by AWM will be in the XWiki space that the user cannot edit. Same for any application that he would like to write without being administrator of the wiki.

Yes that’s what I meant by "App Code protected by default (but can be overridden if need be)” in my first reply. I think it’s good that it’s protected by default but for special cases like AWM, the proper rights can be set at the space level. I don’t think this is an issue at all, quite the opposite, I see it as an advantage. Thanks -Vincent

Thanks

2016-05-02 10:12 GMT+02:00 Vincent Massol <[email protected]>:

...

...

On 02 May 2016, at 09:56, Vincent Massol <[email protected]> wrote:

...

On 02 May 2016, at 09:32, Thomas Mortagne <[email protected]> wrote:

So basically you want to introduce the "Program Files" of XWiki ?

Not quite. Program Files is for all apps (see below for a real “program files” proposal).

From Denis’ proposal I also prefer option A.

Denis Proposal A ==============

Right now I think the proposal is twofold: * Apps with Data continue to create a top level Space containing both Code and Data (i.e. apps that generate user-related data) * Apps without Data under the XWiki space (option A)

Example:

[ROOT] |_ XWiki |_ Applications |_ CKEditor |_ <app pages, i.e. technical pages, no data for the user, can contain config data> |_ Blog |_ Code |_ <app pages, i.e. technical pages, no data for the user, can contain config data> |_ Data |_ <blog-generated user data, i.e. blog posts>

"Program Files” Proposal ====================

* Have all apps under the XWiki space (ie the “Program Files” of Windows for XWiki) * Have user-related data in a nested space under the User profile’s page (would need to be converted to a space first) * Have data generated for users (wiki wide) in some other location. Right now that would be a top level space named after the app.

So in this proposal we would have for example:

[ROOT] |_ XWiki |_ Applications |_ CKEditor |_ <app pages, i.e. technical pages, no data for the user, can contain config data> |_ Blog |_ <app pages, i.e. technical pages, no data for the user, can contain config data> |_ Blog |_ <blog-generated user data, i.e. blog posts>

There’s also an alternative if we wish to cleanly separate app-generated data from content spaces, which is to put all app-generated data under a different root. For example:

[ROOT] |_ XWiki |_ Applications |_ CKEditor |_ <app pages, i.e. technical pages, no data for the user, can contain config data> |_ Blog |_ <app pages, i.e. technical pages, no data for the user, can contain config data> |_ Applications (or another name - FTR Windows uses AppData but it’s hidden) |_ Blog |_ <blog-generated user data, i.e. blog posts> |_ <content spaces under root>

Thanks -Vincent

...

Pros: - All apps located in the same place - App Code protected by default (but can be overridden if need be) - Nicer for users since that would solve the “Data”-space-in-the-breadcrumb issue (i.e. they wouldn’t see /Data/ in the breadcrumb when on app-generated pages)

WDYT?

Thanks -Vincent

...

+1 for A

other important pros IMO: already protected against edition by anyone else than admin, allow extension to do have to deal with that with some hypothetical "XWikiAdminGroup" group that may or may not exist

On Fri, Apr 29, 2016 at 3:31 PM, Denis Gervalle <[email protected]> wrote:

...

Hi Devs,

Appart from the “conventional” application that manage their own data subset, there is more general application, that are either providing wiki-wide feature without data, or that are managing data in the whole wiki, providing additional features. For example, the Administration application, the CKEditor, … and other application actually mixed in the XWiki space.

For those applications, the code/data space separation has no real meaning, but I think it would also be nice to have the code of those applications under a common root, in place of having all of them creating a space at the root of the wiki. For example, currently the UI of the CKEditor is in a CKEditor space at the root, and I have no easy way to distinguish it from a normal space (except that it is invisible), and it is also holding a space name. I agree, there is little chance that a user wants to create an editorial space by the name, but it could happen, and depends on the application space name, there could be more common cases.

My proposal is to put such application inside a common space. There is several options for the name of that space:

A) Reuse the existing “XWiki” space Pros: - not holding a new name at root - always available - nice place to move application already mixup in that space to their own space Cons: - it is currently a mess - it holds users (but shouldn’t we move them to Users space ? I know it is not easy)

B) Create a new space for this purpose B1) XWikiApplications B2) XWikiExtensions B3) WikiApplications B4) WikiExtensions B5) Wiki B6) … ?

wdyt ?

On Fri, Nov 20, 2015 at 9:53 PM, [email protected] < [email protected]> wrote:

...

Hi Ludovic,

On 20 Nov 2015 at 19:30:26, Ludovic Dubost ([email protected](mailto: [email protected])) wrote:

> On this subject, while showing 7.3 in an internal meeting, we saw that the > Data page/space is the parent of all content pages in an AWM, but does not > actually exist, so in the breadcrumb if you click on "Data" you get an > error.

Thanks for reporting, see http://jira.xwiki.org/browse/XWIKI-12836#

-Vincent

> Ludovic > > --*Ludovic Dubost* > *Founder and CEO* > [email protected] > skype: ldubost > Blog: http://blog.ludovic.org > > On Fri, Nov 20, 2015 at 5:10 PM, Anca Luca wrote: > >> On Sat, Nov 14, 2015 at 3:17 PM, [email protected] >> wrote: >> >>> Hi Anca, >>> On 14 Nov 2015 at 10:57:24, Marius Dumitru Florea ( >>> [email protected]) wrote: >>> >>> Hi Anca, >>> >>> On Fri, Nov 13, 2015 at 8:51 PM, Anca Luca wrote: >>> >>>> Hello all, >>>> >>>> my 2 cents on the "Data" or "Entries" subspace. >>>> ( But too late, since I see the issue was already closed :( ) >>> Thanks for taking the time to participate. >>> >>>> I'm afraid that, even if technically it seems like a nice idea, it's >> not >>>> that nice for a "regular non-developer user" which perceive an >>> application >>>> as only having data. >>> >>> >>> >>>> They don't need to and won't know that the code of >>>> that application is also stored on the wiki, in another subspace that >> is >>>> called "Code". >>> >>> >>> The Code space is still hidden so a regular user doesn't see it. There's >> no >>> change in this regard. >>> >>> >>>> There is complaint about the size and the amount of bloat in >>>> the XWiki URLS (the /xwiki/bin/view/ part) and this would be an extra >>> one, >>>> for the case of applications. I don't think url rewrite should be >>>> considered so easily as an option because it's technically not so easy >> to >>>> achieve and I think that there can be an issue with colision (e.g. >>> between >>>> MyApp/WebPreferences and MyApp/Data/WebPreferences). >>>> >>> >>> So you think having MyApp and MyAppCode is better? >>> You need to read the whole discussion thread and see that we’ve discussed >>> about what you said already and we’ve weighted pros and cons to decide in >>> the end that all things considered the Code and Data subspaces were >>> probably the best solution. >> >> >>> If you think they are not, please make a proposal that you think would be >>> better (ideally taking into account the arguments that we’ve already >>> discussed) and we can discuss updating what’s been already done. >>> >> >> Actually, I read the discussion and I re-read it now. And, depending on how >> the "delete application data" is implemented (IIRC In the UI now) we could >> more go for detailed delete options (by default and in the app withim >> minutes itself). All the arguments that were brought in the discussion are >> correct, I just think that in some of them the 80-20 rule was wrongly >> estimated: >> * deleting a whole application data is frequent, but not _that_ frequent >> (20%). >> * it was said that a url rewrite should be doable (people really bothered >> by the Data particle should be able to do it). No, it's not that easy (less >> than 20% of the people bothered by the Data particle can do it). >> * less than 20% of usecases have an application within minutes that has two >> data spaces. Actually, I am wondering how is that an app within minutes >> still, because out of my knowledge this is not a known feature of app >> within minutes, and it means that some customization has been done to that >> application. For me, if an application was customized, it's still an >> application but not "within minutes" anymore. >> * if we're talking about applications in general, I think just as frequent >> is the case when the same application has multiple data spaces (e.g. having >> multiple blogs, each in a different space, in a different point in the >> hierarchy). Having multiple subspaces in the application space would not >> help much in this case. >> * for the rights issue, in 80% of the cases the code authors are data >> authors as well, there are just additional rights on the code (sub) space, >> so it's normal that code space inherits from app space. >> * deleting a space without some of its subspaces is a larger problem than >> app within minutes, so a more generic solution for that could be >> interesting. Also, I think it would be a frequent problem (80%), so having >> a flexible solution for it can be interesting. >> >> Actually, the only thing on which I have a doubt that it would affect 80% >> of the usecases is the Data particle itself in the url :) (maybe more like >> 50-50 :D) . However, from the discussions in the thread I kind of had the >> feeling that it being annoying is considered to fall in the 20% bucket, >> compared to the other arguments which would be 80. I have the opposite >> feeling, as I explained above in the bullet list. >> >> It's a good thing that it's configurable, though. >> >> In what concerns the more generic topic of best practices: In the cases of >> larger customizations that I met so far (on non-nested spaces, though), the >> isolation was much more important: all the code for all the applications >> and all the customizations is in one space, in order to be able to manage >> it together as a group (rights, UI settings, deployment, search, etc), >> while the data was spread around in spaces that are dedicated exclusively >> to data, potentially more data spaces for all the different areas of >> applications coded by that code. Note that this would not fit in the case >> of a standard app within minutes anyway. I haven't thought yet about how >> this strategy would adapt for nested spaces, if each code space should be >> nested under its application space or still keep it all isolated... >> >> Thanks, >> Anca >> >> >>> >>>> But I guess this is really too late now... >>> It’ s not too late. This was done recently and we can still tune things >> if >>> there’s a better proposal. >>> >>> The location where the application stores its data is configurable. >>> What we need (and the topic of this thread) is a best practice, ie. >> what’s >>> used by default. We want apps by default to use these best practices, >> even >>> if they’re configurable (that should be the exception). So it would be >> nice >>> to have Anca and all the devs on this list to agree to use the best >>> practices :) >>> >>> Thanks >>> >>> -Vincent >>> >>> Thanks, >>> Marius >>> >>> >>>> >>>> Thanks, >>>> Anca >>>> >>>> On Tue, Oct 27, 2015 at 11:34 AM, Guillaume "Louis-Marie" Delhumeau < >>>> [email protected]> wrote: >>>> >>>>> Hello. >>>>> >>>>> Why not using "Entries" instead of "Data" for the name? It will be >>> shown >>>>> both in the URL and in the breadcrumb, and fit with most of the >>>> use-cases. >>>>> >>>>> Users can still change the title of the "Entries" space to have a >> more >>>>> specific name such as "Ideas", "Meetings", etc... >>>>> >>>>> Just my 2 cents. >>>>> >>>>> 2015-10-26 10:45 GMT+01:00 Marius Dumitru Florea < >>>>> [email protected]>: >>>>> >>>>>> On Fri, Oct 23, 2015 at 5:06 PM, Clemens Klein-Robbenhaar < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> >>>>>>>> On Wed, Sep 30, 2015 at 11:16 AM, Guillaume "Louis-Marie" >>>> Delhumeau < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>>> 2015-09-30 10:58 GMT+02:00 [email protected] < >>> [email protected] >>>>> : >>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 30 Sep 2015 at 10:53:48, Thomas Mortagne ( >>>>>> [email protected] >>>>>>>>>> (mailto:[email protected])) wrote: >>>>>>>>>> >>>>>>>>>>> I think what I like best is some option in the refactoring >> API >>>> to >>>>>>>>>>> indicate that you want to delete only final documents in the >>>> space >>>>>> (so >>>>>>>>>>> skipping space home page and spaces). >>>>>>>>>> >>>>>>>>>> That could be interesting for some use cases but it’s risky >> for >>>>> this >>>>>>> one. >>>>>>>>>> Several apps may generate terminal pages and users could >> create >>>>>>> terminal >>>>>>>>>> pages in app spaces too. So that would not just remove the >> app >>>>>>> technical >>>>>>>>>> pages, it could remove more. >>>>>>>>>> >>>>>>>>> >>>>>>>>> The idea of Thomas is an option to only delete *terminal* >> pages >>>>>> located >>>>>>> in >>>>>>>>> the space with a depth of 1. Said differently, the direct and >>>>> terminal >>>>>>>>> children of the page. >>>>>>>>> >>>>>>>>> This way, you can delete all data located in the space without >>>>>> removing >>>>>>> the >>>>>>>>> code (because the code would be located in a deeper depth), >> but >>> it >>>>>> works >>>>>>>>> only if the app generates data as terminal pages. It is the >> case >>>>> right >>>>>>> now, >>>>>>>>> but new apps should work differently and create their data as >>>>> regular >>>>>>>>> Nested Pages. >>>>>>>>> >>>>>>>> >>>>>>>> I don't agree at all on this later statement. New apps _may_ >> work >>>>>>>> differently and create nested pages, but it _should_ not. >>>>>>>> Anyway, this is why I am wondering about properly separating >>>> WebHome, >>>>>>> Code >>>>>>>> and Data. >>>>>>>> I do not think we need stable names, but the structure matter. >> If >>>>> Data >>>>>>> does >>>>>>>> not look nice, you may leave apps decide for themselves, the >>> rules >>>>>> being >>>>>>>> put your data in subspaces, and code in the Code subspace, or >>>>> something >>>>>>>> like that. Please note that using "space" in the previous rules >>>> looks >>>>>> bad >>>>>>>> to me, since we do not have space anymore ;) >>>>>>>> >>>>>>> [...] >>>>>>> >>>>>>> >>>>>> >>>>>>> Just another random thought: some applications might really want >> to >>>>> have >>>>>>> two "data" spaces; >>>>>>> for example currently in the blog you cannot have a category and >> a >>>> blog >>>>>>> post with the same name. >>>>>>> If both end up in their respective "subfolders" "Blog.Posts" and >>>>>>> "Blog.Categories", the problem goes away. >>>>>>> >>>>>> >>>>>> Indeed, but I don't think it contradicts the rule. IMO the best >>>> practice >>>>>> should be to group the application data in one or more subspaces >>> under >>>>> the >>>>>> application space. If the application generates only one type of >> data >>>>> (e.g. >>>>>> Events) then it makes sense to have only one Data subspace. If the >>>>>> application generates two or more types of data (Categories and >>> Posts) >>>>> then >>>>>> it may need more subspaces. The only question is whether we should >>>> group >>>>>> these subspaces under a Data subspace, e.g. >>>>>> >>>>>> App / Data / Categories >>>>>> >>>>>> or leave them directly under the application space: >>>>>> >>>>>> App / Categories >>>>>> >>>>>> I prefer the second option. >>>>>> >>>>>> Another thing to decide is whether the Data space should be named >>>> "Data" >>>>> or >>>>>> some domain-specific name. Considering that we can set the title of >>> the >>>>>> home page to anything we want, I prefer to use "Data" as name, so >>> that >>>>> the >>>>>> code deals with a generic "Data" space, even though the user sees >>>>> "Events" >>>>>> in the breadcrumbs. >>>>>> >>>>>> >>>>>>> On the other hand if the application pages end up directly inside >>> the >>>>>> main >>>>>>> page, then e.g. you cannot have a category "Code" in the Blog. >>>>>>> (You cannot have a blog post with it either, but that might be a >>>>> smaller >>>>>>> nuisance) >>>>>>> >>>>>> >>>>>> Good point, and another reason to group the application data in >>> nested >>>>>> spaces under the application space. >>>>>> >>>>>> Thanks, >>>>>> Marius

Hi, On 22 Oct 2015 at 15:46:01, Marius Dumitru Florea ([email protected](mailto:[email protected])) wrote:

On Wed, Sep 30, 2015 at 10:48 AM, Denis Gervalle wrote:

...

Well, I have not yet look in details the new features for page manipulation, but I was wondering if there will be a simple way to delete application data without deleting the application itself with the model you propose ?

Most applications generate structured data so if you know the application xclass then it's easy to write a query that selects all the application entries (excluding the template) from any given location (application space, data space, whatever). Deleting the application entries is not a problem IMO. The problem is setting different access rights for the code space and the data space. If the code space is nested inside the data space then you need to be careful with the rights inheritance. So I'm +1 for

App |- Code |- Data

Having /Data/ in the URL is not a big issue for me. 

I think it’s nice to have Data/ and Code because it provides a clear structure. I was worried about the URL but we think it’s not a problem then I’m fine too. After all it’s generated data and not content pages so it’s probably ok to have a bit more technical URL. And in any case we need some URL alias features in the future.

What can be an issue is having the word "Data" in the breadcrumbs. But we could partially fix this by setting a title on the Data.WebHome using a translation key whose value can be set by the application creator. The following is acceptable IMO:

Mocca Calendar / Events / Seminar 2015 Weekly Activity / Reports / Week 18 to 24 August Task Manager / Tasks / Improve the marketing page FAQ / Questions / What is the meaning of life

but there are applications where this doesn't look good

Meeting / Meetings / Roadmap 7.3 Ideas / Ideas / Send people to Mars

so the application creator will have to settle for

Ideas / Entries / Send people to Mars

Indeed. So default rule would be Entries and if possible find a more application-oriented name. Looks good to me. Thanks -Vincent  

Thanks, Marius

I know there is already issue with that about the WebHome which

...

is usually an entry point to the application, but deleting a space was possible. If the code is nested under the data, isn't it an issue. It looks like the opposite of the general way (not xwiki way, but in application in general), where the code abstract more or less the location of the data and is the "main" part.

So, I am not sure actually, that this is the best way. Maybe code and data should be side by side under a entry point documents ?

On Wed, Sep 30, 2015 at 8:22 AM, [email protected] wrote:

...

Ping! There’s only Thomas and Gaby who answered so far :)

Thanks -Vincent

On 27 Sep 2015 at 21:19:43, [email protected] ([email protected]) wrote:

Hi devs,

Following our implementation of NS/NP in 7.2 I’d like to propose 2 new best practices for app dev that we would list at

http://dev.xwiki.org/xwiki/bin/view/Community/ApplicationDevelopmentBestPrac...

...

1) New rule 1: “Code” subspace

Current text: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC,

AppWithinMinutes,

...

etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations.

New version: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations. * Technical pages should be put in a subspace named “Code”

Note: this rule can only be applied for new applications for now since the EM doesn’t know how to follow renames currently so for example if I move pages from the FAQCode space to the FAQ.Code space, when EM upgrades the app, it’ll display all pages in FAQCode as deleted (basically it considers all pages in FAQ.Code as new pages and pages in FAQCode as deleted pages). Note: I’ve created http://jira.xwiki.org/browse/XWIKI-12622 for this.

2) New rule 2:

* Technical pages without children must be terminal pages.

WDYT?

Thanks -Vincent

On 03 Oct 2016, at 13:03, Ecaterina Moraru (Valica) <[email protected]> wrote:

+1 for Rule 1) about the Code space

-0 for Rule 2) we shouldn't encourage terminal pages anymore. I know is simpler to write scripts without the need to write "WebHome" all over, but the problem is that, unless you plan all your application first in the head, you cannot know if you will need to break it under multiple children pages (macros, etc.) Starting first as terminal and then switching is not fun either, or trying to remember every time to check the terminal option because that's the rule, not fun either. Or at the end of the development process seeing some technical pages don't have children and make them terminal, just to apply with the rule, is kind of anti productive. If we switch the rule from "must be terminal pages" to "might be terminal pages" that maybe will suit me more, but then it will actually not be a rule.

Thanks Caty. Some ideas that come to mind on this: * We have a history of having terminal pages for technical page so deciding to allow non terminal pages now is actually what would be a new rule and it means that you’d find apps with terminal pages (all existing apps) and others without terminal pages (for tech pages) so not that good for consistency. The most important point is that it wouldn’t bring much. * There are cons for both approaches as you mention but in term of inconvenience it’s clearly less inconvenient on the code as terminal pages: ** You create a page once (and thus you have to be careful of creating it terminal) ** vs you use it several times (at least once) and you need to pay attention to add the artificial “WebHome” at the end of the reference everywhere you use it. * Having “WebHome” as the xclass name (for example) is really not very nice. More generally, having WebHome everywhere in code pages is not very nice at all. * You mention about having to rename a tech page if, by some chance, it requires a children in the future. This is the same kind of problem as having to rename a tech page because you initially chose a name that is not fitting, or having to split one, or… It happens all the time and we have a rename feature for this. Anyway I see you’re -0 so you don’t like it but you’re still ok. In any case, as I mentioned above, this is about continuing what we’ve always done FTM so I don’t really see a problem with that. We can still decide to change and use nested pages for tech docs later on in the future. What do others think? Thanks -Vincent

Thanks, Caty

On Mon, Oct 3, 2016 at 1:09 PM, Vincent Massol <[email protected]> wrote:

...

Hi,

This thread has been hijacked by several other proposals which were not part of my initial proposal which consisted of only 2 rules.

I’d like to progress and agree about those 2 rules **only** (for the moment). I’d like to officially put them on http://dev.xwiki.org/xwiki/ bin/view/Community/ApplicationDevelopmentBestPractices

I got the following answer related to my proposal: * Vincent: ok (obviously) * Thomas: ok * Gabriela: ok

Does anyone disagree with those 2 rules?

Barring any negative feedback, I’ll move them to http://dev.xwiki.org/xwiki/bin/view/Community/ ApplicationDevelopmentBestPractices this afternoon.

Then we can iterate on the rest of what was proposed in this thread: * Data dir * Locations for apps

Thanks -Vincent

...

On 27 Sep 2015, at 21:19, [email protected] wrote:

Hi devs,

Following our implementation of NS/NP in 7.2 I’d like to propose 2 new best practices for app dev that we would list at http://dev.xwiki.org/xwiki/bin/view/Community/ ApplicationDevelopmentBestPractices

1) New rule 1: “Code” subspace

Current text: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations.

New version: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations. * Technical pages should be put in a subspace named “Code”

Note: this rule can only be applied for new applications for now since the EM doesn’t know how to follow renames currently so for example if I move pages from the FAQCode space to the FAQ.Code space, when EM upgrades the app, it’ll display all pages in FAQCode as deleted (basically it considers all pages in FAQ.Code as new pages and pages in FAQCode as deleted pages). Note: I’ve created http://jira.xwiki.org/browse/ XWIKI-12622 for this.

2) New rule 2:

* Technical pages without children must be terminal pages.

WDYT?

Thanks -Vincent

+1 for 1) +0.5 for 2). I would like to be able to create "subdirectories" inside the "Code" space, like java packages, so it means I need some non-terminal pages to create these subspaces. Otherwise, I agree. 2016-10-03 13:38 GMT+02:00 Alexandru Cotiuga <[email protected]>:

Hi Here's my +1 for these 2 rules. For the first one, it looks like is almost inevitable to not have an empty SomePage.Code.WebHome. For the second one, I would prefer to not pollute the wiki with useless WebHomes and I would also avoid adding children to class, template, sheet and translation documents(which I would definitely mark as terminal). Classes are used everywhere in queries and it would be nice to not use SomeClass.WebHome'.

Thanks, Alex

On Mon, Oct 3, 2016 at 2:21 PM, Vincent Massol <[email protected]> wrote:

...

...

On 03 Oct 2016, at 13:03, Ecaterina Moraru (Valica) <[email protected]

wrote:

...

+1 for Rule 1) about the Code space

-0 for Rule 2) we shouldn't encourage terminal pages anymore. I know is simpler to write scripts without the need to write "WebHome" all over,

but

...

the problem is that, unless you plan all your application first in the head, you cannot know if you will need to break it under multiple children pages (macros, etc.) Starting first as terminal and then switching is

not

...

...

fun either, or trying to remember every time to check the terminal option because that's the rule, not fun either. Or at the end of the development process seeing some technical pages don't have children and make them terminal, just to apply with the rule, is kind of anti productive. If we switch the rule from "must be terminal pages" to "might be terminal pages" that maybe will suit me more, but then it will actually not be a rule.

Thanks Caty. Some ideas that come to mind on this:

* We have a history of having terminal pages for technical page so deciding to allow non terminal pages now is actually what would be a new rule and it means that you’d find apps with terminal pages (all existing apps) and others without terminal pages (for tech pages) so not that good for consistency. The most important point is that it wouldn’t bring much.

* There are cons for both approaches as you mention but in term of inconvenience it’s clearly less inconvenient on the code as terminal pages: ** You create a page once (and thus you have to be careful of creating it terminal) ** vs you use it several times (at least once) and you need to pay attention to add the artificial “WebHome” at the end of the reference everywhere you use it.

* Having “WebHome” as the xclass name (for example) is really not very nice. More generally, having WebHome everywhere in code pages is not very nice at all.

* You mention about having to rename a tech page if, by some chance, it requires a children in the future. This is the same kind of problem as having to rename a tech page because you initially chose a name that is not fitting, or having to split one, or… It happens all the time and we have a rename feature for this.

Anyway I see you’re -0 so you don’t like it but you’re still ok. In any case, as I mentioned above, this is about continuing what we’ve always done FTM so I don’t really see a problem with that. We can still decide to change and use nested pages for tech docs later on in the future.

What do others think?

Thanks -Vincent

...

Thanks, Caty

On Mon, Oct 3, 2016 at 1:09 PM, Vincent Massol <[email protected]> wrote:

...

Hi,

This thread has been hijacked by several other proposals which were not part of my initial proposal which consisted of only 2 rules.

I’d like to progress and agree about those 2 rules **only** (for the moment). I’d like to officially put them on http://dev.xwiki.org/xwiki/ bin/view/Community/ApplicationDevelopmentBestPractices

I got the following answer related to my proposal: * Vincent: ok (obviously) * Thomas: ok * Gabriela: ok

Does anyone disagree with those 2 rules?

Barring any negative feedback, I’ll move them to http://dev.xwiki.org/xwiki/bin/view/Community/ ApplicationDevelopmentBestPractices this afternoon.

Then we can iterate on the rest of what was proposed in this thread: * Data dir * Locations for apps

Thanks -Vincent

...

On 27 Sep 2015, at 21:19, [email protected] wrote:

Hi devs,

Following our implementation of NS/NP in 7.2 I’d like to propose 2 new best practices for app dev that we would list at http://dev.xwiki.org/xwiki/bin/view/Community/ ApplicationDevelopmentBestPractices

1) New rule 1: “Code” subspace

Current text: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations.

New version: * Generally, put all your pages in a single space dedicated for the application you're developing (e.g. Faq, Scheduler, IRC, AppWithinMinutes, etc). The name must be as short as possible while still being understandable of course and without overusing abbreviations. * Technical pages should be put in a subspace named “Code”

Note: this rule can only be applied for new applications for now since the EM doesn’t know how to follow renames currently so for example if I move pages from the FAQCode space to the FAQ.Code space, when EM upgrades the app, it’ll display all pages in FAQCode as deleted (basically it considers all pages in FAQ.Code as new pages and pages in FAQCode as deleted pages). Note: I’ve created http://jira.xwiki.org/browse/ XWIKI-12622 for this.

2) New rule 2:

* Technical pages without children must be terminal pages.

WDYT?

Thanks -Vincent

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

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

-- Guillaume Delhumeau ([email protected]) Research & Development Engineer at XWiki SAS Committer on the XWiki.org project