14 Nov
2015
14 Nov
'15
3:17 p.m.
Hi Anca,
On 14 Nov 2015 at 10:57:24, Marius Dumitru Florea (mariusdumitru.florea(a)xwiki.com) wrote:
Hi Anca,
On Fri, Nov 13, 2015 at 8:51 PM, Anca Luca <lucaa(a)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.
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(a)xwiki.com> wrote:
to
terminal
right
WebHome,
something
> > > like that. Please note that using "space" in the previous rules
looks
blog
group
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(a)xwiki.com>gt;:
> On Fri, Oct 23, 2015 at 5:06 PM, Clemens Klein-Robbenhaar <
> c.robbenhaar(a)espresto.com> wrote:
>
> >
> > > 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
:
> > >>
> > >>>
> > >>> 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
> > >>>> 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 >>
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 > 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 >
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 bad
have
> > two "data" spaces;
> > for example currently in the blog you cannot have a category and a > to me, since we do not have space anymore
;)
>
[...]
> Just another random thought: some applications might really want to > > 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 > 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