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