21 Sep
2016
21 Sep
'16
10:41 a.m.
On 21 Sep 2016, at 10:28, Denis Gervalle
<dgl(a)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 another
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
http://platform.xwiki.org/xwiki/bin/view/Features/WikiVsNestedPages).
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 spaces.
But that’s the point of this brainstorming: see if there’s value in this or not. I see
some value.
What about others?
Thanks
-Vincent
--
Denis Gervalle
SOFTEC sa - CEO
On mar., sept. 20, 2016 at 4:41 PM, Vincent Massol <vincent(a)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/DeprecatingSpaceAndSpaceRef…
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 <vincent(a)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