Community
Participate
Working Groups
It would be good if there were a way to specify how to resolve relative paths when the Browse Handler returns a absolute path in the filesytem to be able to pass this into a service to allow it to resolve the path relative to its own custom requirements. Here is the preposed service API RelativePathService { String convertToRelative( Path path ); Path convertFromRelative( String path ); }
The bi-directional nature of the proposed service suggests that there may be another approach to handling this... We have a concept of value serialization service, which has encode/decode methods analogous to the methods on the proposed service. I haven't tried it, but the following should work today... 1. Create a Path-type value property. 2. Use @Service annotation to attach a custom ValueSerializationService impl. Implement this service such that decoded path is absolute and encoded path is a relative path per your semantics. 3. Use @AbsolutePath annotation in conjunction with @ValidFileSystemResourceType, @ValidationFileExtensions and @MustExist as appropriate. This will provide native browse dialog and appropriate validation.
I tried this in my model: @Type(base = IPath.class) @XmlBinding(path = "@file") @Label(standard = "file") @AbsolutePath @Service(impl = RelativePathValueSerializationService.class) @ValidFileSystemResourceType(FileSystemResourceType.FILE) @ValidFileExtensions(value = { "xml" }) @MustExist @Required ValueProperty PROP_FILE = new ValueProperty(TYPE, "File"); Value<IPath> getFile(); void setFile(String value); void setFile(IPath value); and in my implementation here is what the "decodeFromString" does @Override protected Object decodeFromString(String value) { IPath absolutePath = new Path(value); IFile modelFile = this.element().adapt(IFile.class); IPath servicePath = modelFile.getLocation(); IPath relativePath = absolutePath.makeRelativeTo(servicePath); return org.eclipse.sapphire.modeling.Path.fromPortableString(relativePath.toPortableString()); } But its not displaying the value that the decodeFromString is returning. In the property field it shows the absolutePath
Ah, yes, that is the problem with that approach. The text field property editor uses Value.getText(), which returns the string form of the value (as specified by ValueSerializationService's encode method). Never mind.
You did find a bug... I was wondering why your property is Value<IPath> insteadof Value<Path>. It looks like a few of system browse action handlers weren't converted properly.
I'd like to find a way to reconcile this proposed enhancement with existing relative path support in the form of @BasePathProvider/BasePathProviderImpl. It would be ideal if there was a single service, but perhaps with default implementations for some methods... RelativePathService { List<Path> roots(); boolean enclosed(); String convertToRelative( Path path ); Path convertFromRelative( String path ); } The return value of true from enclosed() corresponds to the current behavior of BasePathProvider. If false, the relative path can have parent navigation segments. The validation will just call convertFromRelative(). If null, then path is malformed. If not null, validation has the absolute path to proceed to further validation. Browsing will first call enclosed(). If true, the existing dialog would be used. If false, system dialog would be used. After user selects a path, browse support will convertToRelative. If the result is null, conversion is not possible (as in path on another drive). The browse support will signal this somehow to the user and not set the property value. The default implementation of convert methods would support parent navigation if enclosed() returns false. This should be generic enough to allow for arbitrary relative path logic. Even scenarios like path variables should be possible. Thoughts? Did I miss anything?
This look like it would do the trick.
Ok. The new RelativePathService is ready. The old BasePathsProvider API is now gone. I have updated the migration guide and the what's new document. In addition to more flexible architecture at the base, I have also added @ModelRelativePath annotation along with the corresponding relative path service implementation that relativizes paths relative to the location of the model's file. Usage is pretty simple, but I did add an example of this to the gallery sample. Please take a look at the new capabilities and verify.
Updated to build#356 and implemented my relative path service. Its working just as I would like now. Thanks for this new API. Marking as Verified.
closing
