On Wed, Sep 21, 2016 at 10:41 AM, Vincent Massol <vinc...@massol.net> wrote: > >> 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.
Well except that an application need to be very careful to keep working when moved to another space which is hard right now in most cases. It's actually much easier for an application to do what Denis said (provide way to put data where you want and have actual code in a central place). > * 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 I tough about it but not sure it's a real use case (other than testing). Something more interesting for me is the use case where some team has a dedicated space and would like to use some application in it without polluting the others and without the need to be admin of the whole wiki. > > 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 <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? Extension framework support installing extensions in any namespace right now but it does not yet properly support namespace inheritance on several levels (all namespaes inherit root namespace). It's the same thing for classloaders right now. In fact there is no concept of inheritance other than with root in namespaces right now so this would need to be added. On platform side ComponentManager hacked its own thing but it does not really know which namespace inherit what. It just follow the context. For example if you ask for the ComponentManager associated with namespace space:mywiki:MySpace the parent won't be a the ComponentManager associated with "wiki:mywiki" but a dynamic WikiComponentManager which look at the context everytime you call it. About that it looks like we don't support nested spaces at all (current space is tested then it fallback on current wiki). On UI side there is probably a lot of work to present it properly. And then you have to actually write an extensions that work on a different spaces. This one is very hard right now if you manipulate classes so an application would need to explicitly declare it supports spaces namespaces since it's probably not the case for most of the exciting XAR extensions. >>> >>> Do we already have a JIRA for this (couldn’t find one)? This require several jiras. Creating the one about ComponentManager not supported nested spaces. >>> >>> Thanks >>> -Vincent > > _______________________________________________ > devs mailing list > devs@xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs -- Thomas Mortagne _______________________________________________ devs mailing list devs@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs
