Currently there are two differences in the FileSystemAccess implementations:
ProtectedRegionJavaIoFileSystemAcces: charSetProvider is not curried with outputName because file is already derived by outputName
ProtectedRegionEclipseResourceFileSystemAccess2: charSetProvider is curried with outputName but file is already derived by outputName
If the file is relative, the output configuration dir is prepended. If the file is absolute, the dir is not prepended.
There should be no difference of the presentation of a file location (relative vs absolute). The location should be a normalized uri. The output configuration dir should be used only once to determine a file location (and not twice: for the folder and for the contained file).
ProtectedRegionJavaIoFileSystemAccess
val (File)=>Charset charsetProvider = [file |
val URI uri = URI::createURI(file.toURI)
val encoding = getEncoding(uri)
if (Charset::isSupported(encoding)) Charset::forName(encoding) else Charset::defaultCharset
]
class JavaIoFile extends File {
val java.io.File file
override getPath() {
file.path
}
override toURI() {
file.toURI.toString
}
// ...
}
// defined in JavaIoFileSystemAccess
protected String getEncoding(URI fileURI) {
IResourceServiceProvider resourceServiceProvider = registry.getResourceServiceProvider(fileURI);
if(resourceServiceProvider != null)
return resourceServiceProvider.getEncodingProvider().getEncoding(fileURI);
else
return encodingProvider.getEncoding(fileURI);
}
Example (charSetProvider is not curried with outputName because file is already derived by outputName):
override setOutputPath(String outputName, String path) {
logger.debug("setOutputPath('{}', '{}')", outputName, path)
super.setOutputPath(outputName, path)
val file = file("", outputName)
support.read(file, charsetProvider)
}
// in support.read
val charset = charsetProvider?.apply(file)
ProtectedRegionEclipseResourceFileSystemAccess2
val (String,File)=>Charset charsetProvider = [outputName, file |
val encoding = getEncoding(getFile(file.path, outputName))
if (Charset::isSupported(encoding)) Charset::forName(encoding) else Charset::defaultCharset
]
class EclipseResourceFile extends File {
protected val IResource resource
override getPath() {
resource.location.toPortableString
}
override toURI() {
resource.location.toFile.toURI.toString
}
// ...
}
// defined in EclipseResourceFileSystemAccess2
protected IFile getFile(String fileName, String outputName) {
OutputConfiguration configuration = getOutputConfig(outputName);
IFolder folder = getFolder(configuration);
return folder.getFile(new Path(fileName));
}
// defined in EclipseResourceFileSystemAccess2
protected String getEncoding(IFile file) throws CoreException {
return file.getCharset(true);
}
Example (charSetProvider is curried with outputName but file is already derived by outputName):
override setOutputPath(String outputName, String path) {
logger.info("setOutputPath("+ outputName +", "+ path +")")
super.setOutputPath(outputName, path)
val file = file(getOutputConfig(outputName))
support.read(file, charsetProvider.curry(outputName))
}
// in support.read
val charset = charsetProvider?.apply(file)
Currently there are two differences in the FileSystemAccess implementations:
If the file is relative, the output configuration dir is prepended. If the file is absolute, the dir is not prepended.
There should be no difference of the presentation of a file location (relative vs absolute). The location should be a normalized uri. The output configuration dir should be used only once to determine a file location (and not twice: for the folder and for the contained file).
ProtectedRegionJavaIoFileSystemAccess
Example (charSetProvider is not curried with outputName because file is already derived by outputName):
ProtectedRegionEclipseResourceFileSystemAccess2
Example (charSetProvider is curried with outputName but file is already derived by outputName):