14 Nov
2015
14 Nov
'15
3:08 p.m.
On 13 Nov 2015 at 19:19:06, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
Hi Edy,
On 13 Nov 2015 at 19:06:33, Eduard Moraru
(enygma2002@gmail.com(mailto:enygma2002@gmail.com)) wrote:
Also the idea is to have an API to generate the ZIP URLs so that the user should never use
the URL format directly. I’ve added this precision to UC2:
"UC2: Script Service to generate the URLs from UC1 so that users never use the URL
directly. We'll mention in the documentation that the URL format is subject to
change”
This should win us some time to change the format later on if we want.
Thanks
-Vincent
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/zip
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
> >
> > _______________________________________________
> > devs mailing list
> > devs(a)xwiki.org
> > http://lists.xwiki.org/mailman/listinfo/devs
> >
> _______________________________________________
> devs mailing list
> devs(a)xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs