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

On Sat, Nov 14, 2015 at 3:17 PM, vincent(a)massol.net <vincent(a)massol.net> wrote: not is no to 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 if what’s even nice more API for create app pages but case work If to a data _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs