[xwiki-devs] [Proposal] Reorganize a bit various Entity Reference Serializer by introducing some new ones
15 Jun
2015
15 Jun
'15
4:31 p.m.
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
15 Jun
15 Jun
4:32 p.m.
On 15 Jun 2015 at 16:31:43, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) 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
6:01 p.m.
On 15 Jun 2015 at 16:32:28, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
On 15 Jun 2015 at 16:31:43, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) 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
> 
6:17 p.m.
On Mon, Jun 15, 2015 at 6:01 PM, vincent(a)massol.net <vincent(a)massol.net> wrote:
--
Thomas Mortagne
On 15 Jun 2015 at 16:32:28, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
As a readability improvement you might want to unescape " " and "-"
which are escaped by URLEncoder but don't need to be.
On 15 Jun 2015 at 16:31:43, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) 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
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 
16 Jun
16 Jun
11:19 a.m.
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, vincent(a)massol.net
<vincent(a)massol.net> wrote:
--
Jean Simard
jean.simard(a)xwiki.com
Research engineer at XWiki SAS
http://www.xwiki.com
Committer on the XWiki.org project
http://www.xwiki.org
On 15 Jun 2015 at 16:32:28, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
As a readability improvement you might want to unescape " " and "-"
which are escaped by URLEncoder but don't need to be.
On 15 Jun 2015 at 16:31:43, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) 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
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
11:30 a.m.
Hi Jean,
On 16 Jun 2015 at 11:19:50, Jean SIMARD
(jean.simard@xwiki.com(mailto:jean.simard@xwiki.com)) 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,
vincent(a)massol.net wrote:
--
Jean Simard
jean.simard(a)xwiki.com
Research engineer at XWiki SAS
http://www.xwiki.com
Committer on the XWiki.org project
http://www.xwiki.org
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
On 15 Jun 2015 at 16:32:28, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
As a readability improvement you might want to unescape " " and "-"
which are escaped by URLEncoder but don't need to be.
On 15 Jun 2015 at 16:31:43, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) 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
>
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
19 Jun
19 Jun
9:32 a.m.
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, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
On 15 Jun 2015 at 16:32:28, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) wrote:
On 15 Jun 2015 at 16:31:43, vincent(a)massol.net
(vincent@massol.net(mailto:vincent@massol.net)) 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
>
3377
days inactive
3381
days old
6 comments
3 participants
participants (3)
-
Jean SIMARD -
Thomas Mortagne -
vincent＠massol.net