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/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 -- Thomas Mortagne _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
