26 Jan
2011
26 Jan
'11
10:05 p.m.
I see. this is still far away from decision but in my own opinion:
1. Document content should be in a separate file where it is easily accessible, the file
extension
would probably have to be standardized to something like .xwiki2
2. document content, metadata and objects should all be integrated in the same directory
structure.
This will allow for easy storage, backup, and define an alternative and more robust
import/export
format.
Caleb
On 01/26/2011 03:37 PM, Paul Libbrecht wrote:
Caleb,
My question below was about the page content.
(in the future it might apply to several other fields of objects, such as panel source).
paul
Le 26 janv. 2011 à 21:21, Caleb James DeLisle a écrit :
On 01/26/2011 02:10 PM, Paul Libbrecht wrote:
_______________________________________________
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
Le 26 janv. 2011 à 18:59, Caleb James DeLisle a écrit :
Yes, the attachment content goes into a file named whatever the attachment is named.
It will be something like this:
<storage dir>/xwiki/Sandbox/Test/~this/attachments/file.txt/file.txt
The metadata such as date, uploader, and version will be made into an XML file by the
serializer.
That will look something like this:
<?xml version="1.0" encoding="UTF-8"?>
<attachment serializer="attachment-meta/1.0">
<filename>file1</filename>
<filesize>10</filesize>
<author>me</author>
<version>1.1</version>
<comment>something whitty</comment>
<date>1293045632168</date>
</attachment>
serializer="attachment-meta/1.0"
That is the component lookup name of the serializer which makes way for future xml
serializer
implementations.
Versions of the file will be in the same directory:
The naming rule is as follows:
The filename is URL encoded and the version has "~v" prepended so that it
cannot be
mistaken for part of the filename.
If the filename contains one or more '.' characters then the version is inserted
before
the last '.' character. Otherwise it is appended to the file name.
This means a file such as:
file.txt version 1.1 will become file~v1.1.txt and will still be recognized by a text
editor
A file with no extension such as myUnknownFile version 1.1 will become
myUnknownFile~v1.1
Because of URL encoding, a file named file~v1.3.txt of version 1.1 will become
file%7Ev1.3~1.1.txt and thus will not collide with file.txt version 1.1.
Caleb
Hello,
Here's an update on the current state of new filesystem attachment storage:
This is real cool.
[...]
* Serialization - Finished refactoring of
XMLWriter and generic Serializer and XMLSerializer.
Is this actually exporting the content in a separate file? And is the extension of this
file somewhat configurable (at least .grv, .html, or .vm) ? The XML deserialization would
then use XInclude.
The interest is that it would allow back-end changes and/or svn commits and updates in a
way that is compatible with IDEs. [...]
Since this contains a large amount of code and all storage code is critical, I think this
should go
through a release cycle in the platform but disabled by default so that it can be beta
tested before
it becomes official. WDYT?
To me this sounds like the best approach.
paul
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs