On 16 Nov 2015 at 09:57:24, Marius Dumitru Florea
([email protected](mailto:[email protected])) wrote:
> On Fri, Nov 13, 2015 at 8:19 PM, [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 for raising this: I’ve sent a mail on this topic:
http://markmail.org/message/ft3245cbq4ehedct
However this issue is more global than for this use case and it should be fixed
globally. I don’t think it should affect too much this discussion.
Thanks
-Vincent
> 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
