Mario Ivankovits wrote:
Philippe Poulard wrote:
xmldbRaweb2004:xyl://user:[EMAIL PROTECTED]/path/to/file.xml
^^^^^^^^^^^^^^
this is not the xmldb scheme, as recommended by XML:DB
I didnt mean to rename the provider, but to provide a mechanism where
one can tie a set of FileSystemOptions to a specific provider.
However, there is also another way to solve this. You can pass the
FileSystemOptions to the resolveFile method.
FileObject fo = FileSystemManager.resolveFile(String name,
FileSystemOptions fileSystemOptions)
Any subsequent call to "fo" (e.g. FileObject.resolveFile) will be able
to access these options.
What if we create a new method "FileObject.createFile(Map attributes)"?
That way there is no need to change the contract of the IMAGINARY
file type and it makes clear that if you would like to create a new
file with special attributes you have to call that method.
in this case, because of the particularity of all this stuff, it will
be more suitable to override the getAttributes() method (or another, i
will look the code) to perform the operation without checking the file
type
The best is to find a clean solution. The http filesystem might also
profit from it as it might be needet to send the content-type of a file
to the sever.
The problem with the solution to allow IMAGINARY Files to have
attributes is the setAttribute Method. Its passed down to
AbstractFileObject.doSetAttribute(final String atttrName, final Object
value)
which might immediately access the filesystem. But with IMAGNIARY files
there is no file where the filesystem can attach those attribute then.
So why is it that bad to have a "FileObject.createFile/Folder(Map
attributes)" isnt it a clean entry point to create a File/Folder with
specific attributes?
Afterwards one can use setAttribute/getAttribute to modify them (if
possible)
ok, that's clean
thanks
Also its needet to separate the attributes into FileSystemAttributes and
FileAttributes.
You might not see any difference when you use your active tags. But
there are differences if you use VFS in your code.
*) You have to pass the FileSystemAttributes only to the first resolveFile.
*) With every different set of FileSystemAttributes VFS will create a
new FileSystem. So if you access two clusters VFS internally maintains
two filesytems.
xmldb:xyl://user:[EMAIL PROTECTED]/path/to/file.xml with cluster=Raweb2004
is different to
xmldb:xyl://user:[EMAIL PROTECTED]/path/to/file.xml with cluster=Raweb1998
this solution doesn't suit to Xyleme, because the idea of cluster is
somewhat unusual : you need it when you store a file, but you may omit
it when you retrieve it !
--
Cordialement,
///
(. .)
-----ooO--(_)--Ooo-----
| Philippe Poulard |
-----------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
