> On 11 Apr 2016, at 15:07, Vincent Massol <[email protected]> wrote: > >> >> On 08 Apr 2016, at 10:42, Thomas Mortagne <[email protected]> wrote: >> >> On Fri, Apr 8, 2016 at 10:10 AM, Vincent Massol <[email protected]> wrote: >>> >>>> On 08 Apr 2016, at 10:00, Thomas Mortagne <[email protected]> >>>> wrote: >>>> >>>> I'm hesitating, the thing is that what webjars really want to know in >>>> practice is the namespace since that what it will provide to >>>> ClassLoaderManager so maybe the best is to indicate the namespace >>>> instead of the wiki in the URL. It means that webjar service can >>>> support both wiki and users right now and any future namespaces >>>> (document, space, etc). >>> >>> Don’t you think that we need the wiki in order to validate permissions: >>> >>> "// 2) so that we can set the current user in the Context and at the same >>> time verify that the current user has >>> // View Rights on this wiki" >>> >>> At >>> https://github.com/xwiki/xwiki-platform/blob/4f2f6fa823d3d222851f7001237b0bd5cee2d242/xwiki-platform-core/xwiki-platform-webjars/xwiki-platform-webjars-api/src/main/java/org/xwiki/webjars/internal/WebJarsResourceReferenceHandler.java#L120-L120 >>> >> >>> Of course we could generalize and say that we pass a serialized entity >>> reference (or resource reference) instead of the wikiId. Note that we would >>> also need to pass the entity type (or resource reference type), so it would >>> need to be something like “/wiki:wikiId/…”. >> >> "wiki:wikiId" is a the namespace for wiki with id "wikiId". >> >>> >>> Maybe this is too much for now. It’s more work and I’m not sure about the >>> use cases... >> >> It's not really that simple IMO. You will have to change the URL >> format and find an alternative that can work along with the old format >> to not break it. The thing is you could have an extension in any >> namespace, the standard UI just give you wikis choice but it's not the >> case for classloadersmanager/extensionmanager API. As for the user >> case, I don't think installing an extension in a space would be so >> weird compare to installing an extension in a wiki. It does not really >> make much difference for Extension Manager. > > However we still need to have the wikiId somewhere in the URL because we'll > need to set the current wiki (at least to validate permissions). > > So what you’re saying (I think) is that we need 2 more info in the URL: > wikiId + namespace, right?
BTW, AFAICS , the ContextNamespaceURLClassLoader class only deals with a wiki namespace ATM. Are you saying that we should modify this to handle other use cases? Or that WebJarsResourceReferenceHandler should not use the current thread CL? Thanks -Vincent > So something like: > > /<context>/webjars/mywiki/wiki:mywiki/application-ckeditor-webjar/1.4/ckeditor.js > > Generic format: > > /<context>/webjars/<wikiId>/<namespace where to find > resource>/<path/to/resource> > > Unless the namespace is absolute but I don’t know what’s the format right > now. Does a space namespace also specified the wiki? > > Thanks > -Vincent > >>> Thanks >>> -Vincent >>> >>> >>>> On Fri, Apr 8, 2016 at 9:06 AM, Vincent Massol <[email protected]> wrote: >>>>> Hi devs, >>>>> >>>>> In order to fix http://jira.xwiki.org/browse/XWIKI-13276, I’m proposing: >>>>> >>>>> * Use Case 1: No wiki specified: >>>>> >>>>> $services.webjars.url('org.xwiki.contrib:application-ckeditor-webjar', >>>>> 'ckeditor.js’) >>>>> >>>>> would generate: >>>>> >>>>> /<context>/webjars/<currentWikiId>/application-ckeditor-webjar/1.4/ckeditor.js >>>>> >>>>> * Use Case 2: Wiki specified: >>>>> >>>>> $services.webjars.url('org.xwiki.contrib:application-ckeditor-webjar', >>>>> 'ckeditor.js', {'wiki': 'mywiki’) >>>>> >>>>> would generate >>>>> >>>>> /<context>/webjars/mywiki/application-ckeditor-webjar/1.4/ckeditor.js >>>>> >>>>> Generic format: >>>>> >>>>> /<context>/webjars/<wikiId>/path/to/resource >>>>> >>>>> WDYT? >>>>> >>>>> I prefer this over having to deal with domain vs path-based; I also find >>>>> it more clear. >>>>> >>>>> Thanks >>>>> -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
