29 Apr
2016
29 Apr
'16
3:31 p.m.
Hi Devs,
Appart from the “conventional” application that manage their own data
subset, there is more general application, that are either providing
wiki-wide feature without data, or that are managing data in the whole
wiki, providing additional features. For example, the Administration
application, the CKEditor, … and other application actually mixed in the
XWiki space.
For those applications, the code/data space separation has no real meaning,
but I think it would also be nice to have the code of those applications
under a common root, in place of having all of them creating a space at the
root of the wiki. For example, currently the UI of the CKEditor is in a
CKEditor space at the root, and I have no easy way to distinguish it from a
normal space (except that it is invisible), and it is also holding a space
name. I agree, there is little chance that a user wants to create an
editorial space by the name, but it could happen, and depends on the
application space name, there could be more common cases.
My proposal is to put such application inside a common space. There is
several options for the name of that space:
A) Reuse the existing “XWiki” space
Pros:
- not holding a new name at root
- always available
- nice place to move application already mixup in that space to their own
space
Cons:
- it is currently a mess
- it holds users (but shouldn’t we move them to Users space ? I know it is
not easy)
B) Create a new space for this purpose
B1) XWikiApplications
B2) XWikiExtensions
B3) WikiApplications
B4) WikiExtensions
B5) Wiki
B6) … ?
wdyt ?
On Fri, Nov 20, 2015 at 9:53 PM, vincent(a)massol.net <vincent(a)massol.net>
wrote:
Hi Ludovic,
On 20 Nov 2015 at 19:30:26, Ludovic Dubost (ludovic(a)xwiki.com(mailto:
ludovic(a)xwiki.com)) wrote:
_______________________________________________
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
On this subject, while showing 7.3 in an internal
meeting, we saw that
the
Data page/space is the parent of all content
pages in an AWM, but does
not
actually exist, so in the breadcrumb if you click
on "Data" you get an
error.
Thanks for reporting, see http://jira.xwiki.org/browse/XWIKI-12836#
-Vincent
Ludovic
--*Ludovic Dubost*
*Founder and CEO*
ludovic(a)xwiki.com
skype: ldubost
Blog: http://blog.ludovic.org
On Fri, Nov 20, 2015 at 5:10 PM, Anca Luca wrote:
> On Sat, Nov 14, 2015 at 3:17 PM, vincent(a)massol.net
> wrote:
>
> > 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 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(a)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(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
> > > 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