On Fri, Nov 13, 2015 at 8:19 PM, [email protected] <[email protected]> wrote:
> Hi Edy, > > On 13 Nov 2015 at 19:06:33, Eduard Moraru ([email protected](mailto: > [email protected])) wrote: > > > Hi, > > > > About the URL format, why not implement it as a REST extension of the > > /attachment/ resource? > > > > Maybe .../attachments/{attachmentName}/zipExplorer/{zipPath} or something > > like that. > > That’s a good generic remark: we need to decide what to do going forward > between REST-module type of URLs and Action-module type of URLs. > > Ideally I think we would use the following strategy: > * For human-readable URLs: use the Action-module type > * For programmatic URLs (get, webjars, zip, etc): use the REST-module type > > However, right now the Action-module type (Resource module to be precise) > are much more powerful than the REST ones (see > http://design.xwiki.org/xwiki/bin/view/Design/ActionModule). For example > you can execute action after others, or before or replacing them. You vzn > register new actions dynamically in Extensions (which is not possible as > REST components ATM). etc. > > So while I agree with you in general, I wouldn’t want to do this now for > the zip module because of this. > > Now, we shouldn’t care too much about this since it’s only implementation > details. What we should care about is the URL format. > > Right now the format I’m proposing is: > > > .../zip/space1.space2.page@attachment/path/inside/zi > Be careful with putting the serialized (attachment) reference in the URL. Special characters are escaped in the reference using \ (backslash) which may cause problems even when URL encoded (e.g. for Tomcat). See http://jira.xwiki.org/browse/XWIKI-11528?focusedCommentId=84410&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-84410 Thanks, Marius > > Following your suggestion would lead to something like (of course if we > were using the REST module we wouldn’t have the “zip” action): > > > …/zip/wikis/wiki/spaces/space1/spaces/space2/pages/page/attachments/attachment/zippath/some/file/in/zip > > I’m not sure which one is best. All I know is that I find this later > format to be very verbose. But this is the case for our REST format ATM. > > We could imagine supporting an alternate RESTful format like: > > /rest/reference/space1.space2.page@attachment/zippath/some/file/in/zip > > So taking all this into account, at this point in time, I think I prefer > my proposal so far. > > WDYT? > > I also agree that we should clarify our strategy and have some action plan > to improve the REST module to make it really component-based and merge it > with the Resource/URL modules. > > Thanks and have a great weekend! :) > -Vincent > > > Thanks, > > Eduard > > > > On Fri, Nov 13, 2015 at 5:08 PM, [email protected] > > wrote: > > > > > Hi devs, > > > > > > Following the need to support Nested Spaces in the Zip Explorer plugin > > > (see http://jira.xwiki.org/browse/XWIKI-12448) I think it’s time to > bite > > > the bullet and reimplement the feature using components ( > > > http://jira.xwiki.org/browse/XWIKI-12815). > > > > > > I’ve started a design page at > > > http://design.xwiki.org/xwiki/bin/view/Proposal/ZipExplorerComponent > > > > > > I’m especially interested in ensuring that I have all use cases taken > into > > > account. > > > > > > Could you have a quick look and see whether it looks fine or not? > > > > > > I’m also interested in any feedback on the URL format + API. > > > > > > Thanks a lot > > > -Vincent > > > > > > _______________________________________________ > > > devs mailing list > > > [email protected] > > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > _______________________________________________ > > devs mailing list > > [email protected] > > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
