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