> On 21 Sep 2016, at 10:28, Denis Gervalle <d...@softec.lu> wrote:
> Hi Vincent,
> Regarding the improvements to avoid absolute references, and increasing our 
> ability to relocate application, this is a big +1, since it would be already 
> helpful during refactoring of existing code, to avoid trivial breakage.
> Now, about the idea of installing an extension multiple time in the same 
> wiki, I am not sure the benefits really outweighs the inconveniences, and a 
> first step IMO would be to evaluate that. In particular, what is the benefit 
> of having the exact same application code multiple times compared to having 
> that code in a central place but using data in several space, and being 
> simply visible in those specified spaces. My first reaction is that 
> duplicating code looks like breaking good practices.
> wdyt ?

I see at least 3 advantages:
* The application doesn’t need extra development work to support being used 
from several locations. See the existing apps. Almost none support multiple 
usage inside a given wiki. If they could be installed in several places 
suddenly this makes it possible. Actually this is similar to apps being 
installed in several wikis. It’s also code duplication.
* The users get the UI in different places (i.e. in situ) and they don’t need 
to navigate to a central location to use the app.
* This allows to upgrade the apps used in several places independently from one 

So the question you ask can be asked at the wiki level too since it’s also code 
duplication. The idea here is to be able to do the same but inside one wiki. 
Technically, XWiki could have implemented what it did at the level of subwiki 
as spaces and I think it’s a nice direction to increase what XWiki can do at 
the level of spaces (right now, see 

Note that I’m not saying that apps should be developed to support being used at 
multiple locations. I’m saying that in the same way as we can install apps in 
several wikis, I see no major reason to not be able to do at the level of 

But that’s the point of this brainstorming: see if there’s value in this or 
not. I see some value.

What about others?


> --
> Denis Gervalle
> On mar., sept. 20, 2016 at 4:41 PM, Vincent Massol <vinc...@massol.net> wrote:
> Note that it’s very very hard ATM to write an app that will work when 
> installed in any space. Some gotchas:
> * xobject references in wiki pages are absolute
> * class sheet bindings are absolute
> Before we can do this we need to work on inventing the new syntax for 
> relative references, see 
> http://design.xwiki.org/xwiki/bin/view/Proposal/DeprecatingSpaceAndSpaceReference#HNewreferencesyntax283F29
> For example we need to be able to write in a class sheet binding xobject: 
> .XXXSheet (or ..SomePage.XXXSheet).
> And we need to save xobject references as relative in the DB.
> Basically we need to have everything stored relative in the DB…
> Thanks
> -Vincent
>> On 20 Sep 2016, at 13:41, Vincent Massol <vinc...@massol.net> wrote:
>> Hi devs,
>> Now that we support Nested Pages, I think it would be nice if we had the 
>> option to install an Extension in a space (i.e. a page from a user POV).
>> Technically at the Component Manager level, we can already register a 
>> component at the farm level (root), in the current wiki, in the current 
>> space or for the current user.
>> We already have the option to install an extension in a wiki and it would be 
>> nice to extend that concept to a space.
>> We also already have the concept of space admin UI.
>> Of course the app should tell whether it supports being installed in several 
>> spaces or not.
>> The use case is simply to be able to install several times a given 
>> application.
>> From a UI perspective, when you go the the space admin UI (called the Page 
>> Administration for users), you’d have the option to list installed 
>> extensions and install new extensions (basically what you currently have at 
>> the wiki level).
>> Now, the same should be doable also for importing XARs, i.e. also have an 
>> Import option in the Page Administration UI.
>> WDYT?
>> How complex would it be to do that?
>> Do we already have a JIRA for this (couldn’t find one)?
>> Thanks
>> -Vincent

devs mailing list

Reply via email to