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