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
>