[xwiki-devs] [Proposal] Reorganize a bit various Entity Reference Serializer by introducing some new ones
Hi devs, I’m modifying code for handling NestedSpaces in URLs and a lot of code is doing reference serialization "by hand”. I’d like to rationalize this. Proposal: * Deprecate the “path” resolver/serializer which is currently located in platform-store-filesystem-attachment since “path” is misleading. It’s actually a FS Path (since it uses File.separator). * Introduce a new “fspath” resolver/serializer (copy the “path” one) but put it in the platform-model module since it should be able to be used by any module using the FS. * Introduce a new “file” serializer which will generate a file name out of a reference. UC: when needing to store temporary files (for exports for example) ** use “.” as separator ** escape the “.” using “%2E” as it’s done in the “path” serializer ( URLEncoder.encode(currentReference.getName(), "UTF-8").replace(".", "%2E")); ) hoping that whoever wrote it checked that “%” was a valid char in all File systems… ;) WDYT? Thanks -Vincent
On 15 Jun 2015 at 16:31:43, [email protected] ([email protected](mailto:[email protected])) wrote:
Hi devs,
I’m modifying code for handling NestedSpaces in URLs and a lot of code is doing reference serialization "by hand”. I’d like to rationalize this.
Proposal:
* Deprecate the “path” resolver/serializer which is currently located in platform-store-filesystem-attachment since “path” is misleading. It’s actually a FS Path (since it uses File.separator). * Introduce a new “fspath” resolver/serializer (copy the “path” one) but put it in the platform-model module since it should be able to be used by any module using the FS. * Introduce a new “file” serializer which will generate a file name out of a reference. UC: when needing to store temporary files (for exports for example) ** use “.” as separator ** escape the “.” using “%2E” as it’s done in the “path” serializer ( URLEncoder.encode(currentReference.getName(), "UTF-8").replace(".", "%2E")); ) hoping that whoever wrote it checked that “%” was a valid char in all File systems… ;)
The “file” serializer would also be located in platform-model Thanks -Vincent
WDYT?
Thanks -Vincent
On 15 Jun 2015 at 16:32:28, [email protected] ([email protected](mailto:[email protected])) wrote:
On 15 Jun 2015 at 16:31:43, [email protected] ([email protected](mailto:[email protected])) wrote:
Hi devs,
I’m modifying code for handling NestedSpaces in URLs and a lot of code is doing reference serialization "by hand”. I’d like to rationalize this.
Proposal:
* Deprecate the “path” resolver/serializer which is currently located in platform-store-filesystem-attachment since “path” is misleading. It’s actually a FS Path (since it uses File.separator). * Introduce a new “fspath” resolver/serializer (copy the “path” one) but put it in the platform-model module since it should be able to be used by any module using the FS. * Introduce a new “file” serializer which will generate a file name out of a reference. UC: when needing to store temporary files (for exports for example)
Better hint: “filename” Thanks -Vincent
** use “.” as separator ** escape the “.” using “%2E” as it’s done in the “path” serializer ( URLEncoder.encode(currentReference.getName(), "UTF-8").replace(".", "%2E")); ) hoping that whoever wrote it checked that “%” was a valid char in all File systems… ;)
The “file” serializer would also be located in platform-model
Thanks -Vincent
WDYT?
Thanks -Vincent
On Mon, Jun 15, 2015 at 6:01 PM, [email protected] <[email protected]> wrote:
On 15 Jun 2015 at 16:32:28, [email protected] ([email protected](mailto:[email protected])) wrote:
On 15 Jun 2015 at 16:31:43, [email protected] ([email protected](mailto:[email protected])) wrote:
Hi devs,
I’m modifying code for handling NestedSpaces in URLs and a lot of code is doing reference serialization "by hand”. I’d like to rationalize this.
Proposal:
* Deprecate the “path” resolver/serializer which is currently located in platform-store-filesystem-attachment since “path” is misleading. It’s actually a FS Path (since it uses File.separator). * Introduce a new “fspath” resolver/serializer (copy the “path” one) but put it in the platform-model module since it should be able to be used by any module using the FS. * Introduce a new “file” serializer which will generate a file name out of a reference. UC: when needing to store temporary files (for exports for example)
Better hint: “filename”
Thanks -Vincent
** use “.” as separator ** escape the “.” using “%2E” as it’s done in the “path” serializer ( URLEncoder.encode(currentReference.getName(), "UTF-8").replace(".", "%2E")); ) hoping that whoever wrote it checked that “%” was a valid char in all File systems… ;)
As a readability improvement you might want to unescape " " and "-" which are escaped by URLEncoder but don't need to be.
The “file” serializer would also be located in platform-model
Thanks -Vincent
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Thomas Mortagne
Hi, Not sure I completely understand the discussion so please excuse me if what I'm telling below is out of scope.
From what I understand, you plan to transform URL from
/xwiki/bin/view/Main/WebHome to /xwiki/bin/view/Main.WebHome or /xwiki/bin/view/Main%2EWebHome (if escaped) And more extensively, you would have something like this for multiple level of nested space /xwiki/bin/view/This.is.a.very.long.path.because.there.is.multiple.level.of.nested.spaces.for.accessing.this.really.nice.document And here we are, nested spaces can result in very very long URL paths. So, therefore, I'm asking myself, why can't we replace them by IDs? Something like /xwiki/bin/view/a13542-ce865748-fd5876c Here are 2 reasons why this sounds to me like a solution to consider: * Avoid long URL (see above) * URL is technical, user should only click on links they are provided, not write the URL by hand. And I blame myself here since I often use the URL field to access documents; I know, it sounds like a nice feature in XWiki but in the end, as developers, I have the feeling that we forget the UX since we all use URL to do stuff, therefore, using IDs would force us to improve UX (I know, you don't like me now :-P). Of course, as I said at the beginning, I may be completely out of scope so if this is the case, forgive me and just ignore the email. Thanks, On 15/06/2015 18:17, Thomas Mortagne wrote:
On Mon, Jun 15, 2015 at 6:01 PM, [email protected] <[email protected]> wrote:
On 15 Jun 2015 at 16:32:28, [email protected] ([email protected](mailto:[email protected])) wrote:
On 15 Jun 2015 at 16:31:43, [email protected] ([email protected](mailto:[email protected])) wrote:
Hi devs,
I’m modifying code for handling NestedSpaces in URLs and a lot of code is doing reference serialization "by hand”. I’d like to rationalize this.
Proposal:
* Deprecate the “path” resolver/serializer which is currently located in platform-store-filesystem-attachment since “path” is misleading. It’s actually a FS Path (since it uses File.separator). * Introduce a new “fspath” resolver/serializer (copy the “path” one) but put it in the platform-model module since it should be able to be used by any module using the FS. * Introduce a new “file” serializer which will generate a file name out of a reference. UC: when needing to store temporary files (for exports for example)
Better hint: “filename”
Thanks -Vincent
** use “.” as separator ** escape the “.” using “%2E” as it’s done in the “path” serializer ( URLEncoder.encode(currentReference.getName(), "UTF-8").replace(".", "%2E")); ) hoping that whoever wrote it checked that “%” was a valid char in all File systems… ;)
As a readability improvement you might want to unescape " " and "-" which are escaped by URLEncoder but don't need to be.
The “file” serializer would also be located in platform-model
Thanks -Vincent
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org
Hi Jean, On 16 Jun 2015 at 11:19:50, Jean SIMARD ([email protected](mailto:[email protected])) wrote:
Hi,
Not sure I completely understand the discussion so please excuse me if what I'm telling below is out of scope.
From what I understand, you plan to transform URL from
/xwiki/bin/view/Main/WebHome to /xwiki/bin/view/Main.WebHome or /xwiki/bin/view/Main%2EWebHome (if escaped)
And more extensively, you would have something like this for multiple level of nested space /xwiki/bin/view/This.is.a.very.long.path.because.there.is.multiple.level.of.nested.spaces.for.accessing.this.really.nice.document
And here we are, nested spaces can result in very very long URL paths. So, therefore, I'm asking myself, why can't we replace them by IDs? Something like /xwiki/bin/view/a13542-ce865748-fd5876c
Here are 2 reasons why this sounds to me like a solution to consider: * Avoid long URL (see above) * URL is technical, user should only click on links they are provided, not write the URL by hand. And I blame myself here since I often use the URL field to access documents; I know, it sounds like a nice feature in XWiki but in the end, as developers, I have the feeling that we forget the UX since we all use URL to do stuff, therefore, using IDs would force us to improve UX (I know, you don't like me now :-P).
Of course, as I said at the beginning, I may be completely out of scope so if this is the case, forgive me and just ignore the email.
Thanks for participating but yes you’re out of scope here :) This mail is about some internal technical details (how do we serialize temporary files on disk mostly). Thanks -Vincent
Thanks,
On 15/06/2015 18:17, Thomas Mortagne wrote:
On Mon, Jun 15, 2015 at 6:01 PM, [email protected] wrote:
On 15 Jun 2015 at 16:32:28, [email protected] ([email protected](mailto:[email protected])) wrote:
On 15 Jun 2015 at 16:31:43, [email protected] ([email protected](mailto:[email protected])) wrote:
Hi devs,
I’m modifying code for handling NestedSpaces in URLs and a lot of code is doing reference serialization "by hand”. I’d like to rationalize this.
Proposal:
* Deprecate the “path” resolver/serializer which is currently located in platform-store-filesystem-attachment since “path” is misleading. It’s actually a FS Path (since it uses File.separator). * Introduce a new “fspath” resolver/serializer (copy the “path” one) but put it in the platform-model module since it should be able to be used by any module using the FS. * Introduce a new “file” serializer which will generate a file name out of a reference. UC: when needing to store temporary files (for exports for example)
Better hint: “filename”
Thanks -Vincent
** use “.” as separator ** escape the “.” using “%2E” as it’s done in the “path” serializer ( URLEncoder.encode(currentReference.getName(), "UTF-8").replace(".", "%2E")); ) hoping that whoever wrote it checked that “%” was a valid char in all File systems… ;)
As a readability improvement you might want to unescape " " and "-" which are escaped by URLEncoder but don't need to be.
The “file” serializer would also be located in platform-model
Thanks -Vincent
WDYT?
Thanks -Vincent
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Jean Simard [email protected] Research engineer at XWiki SAS http://www.xwiki.com Committer on the XWiki.org project http://www.xwiki.org _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Some updates: * I don’t think we need a “file” serializer anymore since this can cause problems on long hierarchies leading to file names over 255 characters. It’s better to always create a FS directory structure matching the hierarchy. * Thus I’m just going to move the existing “path” serializer/resolver to xwiki-platform-model and I’ll make some changes to it: ** Also encode “*” since it’s been forgotten in the “path” serializer ** Replace File.separator by ‘/‘ so that this serializer can be used both for Files and for URL paths (Java converts ‘/‘ to the underlying OS separator). Thanks -Vincent On 15 Jun 2015 at 18:01:44, [email protected] ([email protected](mailto:[email protected])) wrote:
On 15 Jun 2015 at 16:32:28, [email protected] ([email protected](mailto:[email protected])) wrote:
On 15 Jun 2015 at 16:31:43, [email protected] ([email protected](mailto:[email protected])) wrote:
Hi devs,
I’m modifying code for handling NestedSpaces in URLs and a lot of code is doing reference serialization "by hand”. I’d like to rationalize this.
Proposal:
* Deprecate the “path” resolver/serializer which is currently located in platform-store-filesystem-attachment since “path” is misleading. It’s actually a FS Path (since it uses File.separator). * Introduce a new “fspath” resolver/serializer (copy the “path” one) but put it in the platform-model module since it should be able to be used by any module using the FS. * Introduce a new “file” serializer which will generate a file name out of a reference. UC: when needing to store temporary files (for exports for example)
Better hint: “filename”
Thanks -Vincent
** use “.” as separator ** escape the “.” using “%2E” as it’s done in the “path” serializer ( URLEncoder.encode(currentReference.getName(), "UTF-8").replace(".", "%2E")); ) hoping that whoever wrote it checked that “%” was a valid char in all File systems… ;)
The “file” serializer would also be located in platform-model
Thanks -Vincent
WDYT?
Thanks -Vincent
participants (3)
-
Jean SIMARD -
Thomas Mortagne -
vincent＠massol.net