Hi, my 2 cents on using a "Data" space: I think it's not a good UX practice. Here's the rationale:
- You build an AWM which creates a "Data" space and a "Code" space - You add entries => their breadcrumb is therefore MyApp > Data > Entry - A normal user looks at the tree navigation: he sees only "Data", not "Code" - So for most users, there's this unnecessary, confusing "Data" thing => I'm in the Blog, where are my articles? What are they doing over there in "Data"? Though I understand how we got here, I prefer the "Program Files" proposal in that it keeps a simple app structure for end users. End users should not be exposed to the technical part of apps (and make no mistake, a "Data" space is a technical thing). Thanks, Guillaume On Mon, May 2, 2016 at 10:01 AM, Vincent Massol <[email protected]> wrote: > > > 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 > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
