[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
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:
--
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
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:
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
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:
3579
days inactive
3583
days old
6 comments
3 participants
participants (3)
-
Jean SIMARD -
Thomas Mortagne -
vincent＠massol.net