On Sat, Nov 14, 2015 at 3:17 PM, vincent@massol.net <vincent@massol.net> wrote:
Hi Anca, On 14 Nov 2015 at 10:57:24, Marius Dumitru Florea ( mariusdumitru.florea@xwiki.com) wrote:
Hi Anca,
On Fri, Nov 13, 2015 at 8:51 PM, Anca Luca <lucaa@xwiki.com> 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 < gdelhumeau@xwiki.com> 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@xwiki.com>:
On Fri, Oct 23, 2015 at 5:06 PM, Clemens Klein-Robbenhaar < c.robbenhaar@espresto.com> wrote:
On Wed, Sep 30, 2015 at 11:16 AM, Guillaume "Louis-Marie"
Delhumeau <
gdelhumeau@xwiki.com> wrote:
> 2015-09-30 10:58 GMT+02:00 vincent@massol.net < vincent@massol.net : > >> >> On 30 Sep 2015 at 10:53:48, Thomas Mortagne ( thomas.mortagne@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
devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs