2015-09-30 11:55 GMT+02:00 [email protected] <[email protected]>: > > > 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. >
Except when there are a lot of pages, and we need pagination for this. We could do like gmail does: only remove pages that are visible in the livetable and not all of them, except when an option to delete everything is enabled. (it's the same problem with a tree) > > 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 > -- 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
