27 Oct
2015
27 Oct
'15
2:02 p.m.
On Tue, Oct 27, 2015 at 11:37 AM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
On 27 Oct 2015 at 11:35:13, Guillaume Louis-Marie Delhumeau (
gdelhumeau@xwiki.com(mailto:gdelhumeau@xwiki.com)) wrote:
First that come to mind, is configuration. You may as well need to store
temporary data, cached data, etc… I am not sure all apps should be
considered close to AWM.
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…
It’s true that Entries is less technical than Data so I would also prefer
it. However can we foresee some generated data that won’t be Entries?
Thanks
-Vincent
--
Guillaume Delhumeau (gdelhumeau(a)xwiki.com)
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Denis Gervalle
SOFTEC sa - CEO
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 :
> > >>
> > >>>
> > >>> 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,
> > 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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs