26 Oct
2015
26 Oct
'15
10:45 a.m.
On Fri, Oct 23, 2015 at 5:06 PM, Clemens Klein-Robbenhaar <
c.robbenhaar(a)espresto.com> wrote:
Code
On Wed, Sep 30, 2015 at 11:16 AM, Guillaume
"Louis-Marie" Delhumeau <
gdelhumeau(a)xwiki.com> wrote:
> 2015-09-30 10:58 GMT+02:00 vincent(a)massol.net <vincent(a)massol.net>et>:
>
>>
>> On 30 Sep 2015 at 10:53:48, Thomas Mortagne (thomas.mortagne(a)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, 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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs