> On 02 May 2016, at 09:56, Vincent Massol <[email protected]> wrote:
>
>
>> On 02 May 2016, at 09:32, Thomas Mortagne <[email protected]> wrote:
>>
>> So basically you want to introduce the "Program Files" of XWiki ?
>
> Not quite. Program Files is for all apps (see below for a real “program
> files” proposal).
>
> From Denis’ proposal I also prefer option A.
>
> Denis Proposal A
> ==============
>
> Right now I think the proposal is twofold:
> * Apps with Data continue to create a top level Space containing both Code
> and Data (i.e. apps that generate user-related data)
> * Apps without Data under the XWiki space (option A)
>
> Example:
>
> [ROOT]
> |_ XWiki
> |_ Applications
> |_ CKEditor
> |_ <app pages, i.e. technical pages, no data for the user, can contain
> config data>
> |_ Blog
> |_ Code
> |_ <app pages, i.e. technical pages, no data for the user, can contain
> config data>
> |_ Data
> |_ <blog-generated user data, i.e. blog posts>
>
> "Program Files” Proposal
> ====================
>
> * Have all apps under the XWiki space (ie the “Program Files” of Windows for
> XWiki)
> * Have user-related data in a nested space under the User profile’s page
> (would need to be converted to a space first)
> * Have data generated for users (wiki wide) in some other location. Right now
> that would be a top level space named after the app.
>
> So in this proposal we would have for example:
>
> [ROOT]
> |_ XWiki
> |_ Applications
> |_ CKEditor
> |_ <app pages, i.e. technical pages, no data for the user, can contain
> config data>
> |_ Blog
> |_ <app pages, i.e. technical pages, no data for the user, can contain
> config data>
> |_ Blog
> |_ <blog-generated user data, i.e. blog posts>
There’s also an alternative if we wish to cleanly separate app-generated data
from content spaces, which is to put all app-generated data under a different
root. For example:
[ROOT]
|_ XWiki
|_ Applications
|_ CKEditor
|_ <app pages, i.e. technical pages, no data for the user, can contain
config data>
|_ Blog
|_ <app pages, i.e. technical pages, no data for the user, can contain
config data>
|_ Applications (or another name - FTR Windows uses AppData but it’s hidden)
|_ Blog
|_ <blog-generated user data, i.e. blog posts>
|_ <content spaces under root>
Thanks
-Vincent
> Pros:
> - All apps located in the same place
> - App Code protected by default (but can be overridden if need be)
> - Nicer for users since that would solve the “Data”-space-in-the-breadcrumb
> issue (i.e. they wouldn’t see /Data/ in the breadcrumb when on app-generated
> pages)
>
> WDYT?
>
> Thanks
> -Vincent
>
>> +1 for A
>>
>> other important pros IMO: already protected against edition by anyone
>> else than admin, allow extension to do have to deal with that with
>> some hypothetical "XWikiAdminGroup" group that may or may not exist
>>
>>
>> On Fri, Apr 29, 2016 at 3:31 PM, Denis Gervalle <[email protected]> wrote:
>>> 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, [email protected] <[email protected]>
>>> wrote:
>>>
>>>> Hi Ludovic,
>>>>
>>>> On 20 Nov 2015 at 19:30:26, Ludovic Dubost ([email protected](mailto:
>>>> [email protected])) wrote:
>>>>
>>>>> 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*
>>>>> [email protected]
>>>>> 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, [email protected]
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Anca,
>>>>>>> On 14 Nov 2015 at 10:57:24, Marius Dumitru Florea (
>>>>>>> [email protected]) 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 <
>>>>>>>> [email protected]> 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 <
>>>>>>>>> [email protected]>:
>>>>>>>>>
>>>>>>>>>> On Fri, Oct 23, 2015 at 5:06 PM, Clemens Klein-Robbenhaar <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> On Wed, Sep 30, 2015 at 11:16 AM, Guillaume "Louis-Marie"
>>>>>>>> Delhumeau <
>>>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> 2015-09-30 10:58 GMT+02:00 [email protected] <
>>>>>>> [email protected]
>>>>>>>>> :
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 30 Sep 2015 at 10:53:48, Thomas Mortagne (
>>>>>>>>>> [email protected]
>>>>>>>>>>>>>> (mailto:[email protected])) 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
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
