16 Nov
2015
16 Nov
'15
10:23 a.m.
On 16 Nov 2015 at 09:57:24, Marius Dumitru Florea
(mariusdumitru.florea@xwiki.com(mailto:mariusdumitru.florea@xwiki.com)) wrote:
On Fri, Nov 13, 2015 at 8:19 PM, vincent(a)massol.net
wrote:
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
Hi Edy,
On 13 Nov 2015 at 19:06:33, Eduard Moraru (enygma2002(a)gmail.com(mailto:
enygma2002(a)gmail.com)) 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=co…
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, vincent(a)massol.net
> > 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