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