Re: [xwiki-devs] [Proposal] 2 new rules for Application Best Practices

On 02 May 2016, at 09:56, Vincent Massol <vincent(a)massol.net> wrote: > On 02 May 2016, at 09:32, Thomas Mortagne <thomas.mortagne(a)xwiki.com>

Not quite. Program Files is for all apps (see below for a real “program

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

* 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

|_ Blog |_ Code |_ <app pages, i.e. technical pages, no data for the user, can

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

* Have user-related data in a nested space under the User profile’s page

* Have data generated for users (wiki wide) in some other location.

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

|_ Blog |_ <app pages, i.e. technical pages, no data for the user, can

|_ Blog |_ <blog-generated user data, i.e. blog posts> 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

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 &lt;dgl(a)softec.lu&gt; 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

>> XWiki space. >> >> For those applications, the code/data space separation has no real

>> but I think it would also be nice to have the code of those

>> under a common root, in place of having all of them creating a space

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

>> normal space (except that it is invisible), and it is also holding a

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

>> space >> Cons: >> - it is currently a mess >> - it holds users (but shouldn’t we move them to Users space ? I know

>> 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, vincent(a)massol.net <

>> wrote: >> >>> Hi Ludovic, >>> >>> On 20 Nov 2015 at 19:30:26, Ludovic Dubost (ludovic(a)xwiki.com(mailto: >>> ludovic(a)xwiki.com)) wrote: >>> >>>> On this subject, while showing 7.3 in an internal meeting, we saw

>>> the >>>> Data page/space is the parent of all content pages in an AWM, but

>>> not >>>> actually exist, so in the breadcrumb if you click on "Data" you get

>>>> error. >>> >>> Thanks for reporting, see http://jira.xwiki.org/browse/XWIKI-12836# >>> >>> -Vincent >>> >>>> Ludovic >>>> >>>> --*Ludovic Dubost* >>>> *Founder and CEO* >>>> ludovic(a)xwiki.com >>>> 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, vincent(a)massol.net >>>>> wrote: >>>>> >>>>>> Hi Anca, >>>>>> On 14 Nov 2015 at 10:57:24, Marius Dumitru Florea ( >>>>>> mariusdumitru.florea(a)xwiki.com) 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

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

>>>>> minutes itself). All the arguments that were brought in the

>>> are >>>>> correct, I just think that in some of them the 80-20 rule was

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

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

>>>>> still, because out of my knowledge this is not a known feature of

>>>>> within minutes, and it means that some customization has been done

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

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

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

>>> 80% >>>>> of the usecases is the Data particle itself in the url :) (maybe

>>> like >>>>> 50-50 :D) . However, from the discussions in the thread I kind of

>>> the >>>>> feeling that it being annoying is considered to fall in the 20%

>>>>> compared to the other arguments which would be 80. I have the

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

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

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

>>>>> 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 < >>>>>>> gdelhumeau(a)xwiki.com&gt; 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 < >>>>>>>> mariusdumitru.florea(a)xwiki.com&gt;gt;: >>>>>>>> >>>>>>>>> On Fri, Oct 23, 2015 at 5:06 PM, Clemens Klein-Robbenhaar < >>>>>>>>> c.robbenhaar(a)espresto.com&gt; wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> On Wed, Sep 30, 2015 at 11:16 AM, Guillaume "Louis-Marie" >>>>>>> Delhumeau < >>>>>>>>>>> gdelhumeau(a)xwiki.com&gt; wrote: >>>>>>>>>>> >>>>>>>>>>>> 2015-09-30 10:58 GMT+02:00 vincent(a)massol.net < >>>>>> vincent(a)massol.net >>>>>>>> : >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> On 30 Sep 2015 at 10:53:48, Thomas Mortagne ( >>>>>>>>> thomas.mortagne(a)xwiki.com >>>>>>>>>>>>> (mailto:thomas.mortagne@xwiki.com)) 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 >>>>>>