> 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> > > 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)
Little note for WebHomes of apps: * Apps that have UI (WebHome for example) should provide a WebHome for users (i.e. in Blog.WebHome in the example above). That WebHome can do an include of generic content from XWiki.Applications.Blog.* pages. FTR this is what the FAQ apps already does so that the user doesn’t himself on a page with FAQCode in the breadcrumb. Thanks -Vincent > > 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
