[
https://issues.apache.org/jira/browse/SLING-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14980684#comment-14980684
]
Andreas Schaefer commented on SLING-3733:
-----------------------------------------
Together with that File Path Strings should be replaced by a API class that
models the duality of a resource (local file on the file system, path inside
Sling). Also the file system paths should be OS independent (Windows vs. Unix)
to avoid unnecessary translations.
> Remodel API for more natural usage of IO operations
> ---------------------------------------------------
>
> Key: SLING-3733
> URL: https://issues.apache.org/jira/browse/SLING-3733
> Project: Sling
> Issue Type: Improvement
> Components: IDE
> Reporter: Robert Munteanu
> Priority: Critical
> Fix For: Sling Eclipse IDE 1.1.0
>
>
> The current approach for working with I/O is a bit convoluted. To make sure
> we integrate properly with multiple potential environments - Eclipse,
> IntelliJ, Netbeans, CLI - our APIs work mainly with Strings and InputStreams
> ( or byte-arrays ).
> Although it works fine, it's starting to become awkward, as a single
> operation can consist of multiple calls to API methods due to this
> back-and-forth. For instance:
> {code}
> // Sling IDE API
> String serializationFilePath =
> serializationManager.getSerializationFilePath(resourceLocation,
> serializationKind);
> // Eclipse API
> IPath serializationFilePath2 =
> Path.fromPortableString(serializationFilePath);
> // Eclipse API
> IResource serializationResource =
> syncDirectory.findMember(serializationFilePath2);
> // a bit later...
> // Sling IDE API
> serializationManager.readSerializationData(serializationFilePath,
> serializationResource.getContents();
> {code}
> We should overhaul the I/O-based APIs to work with I/O abstractios ( e.g.
> FileReader -> EclipseFileReader ) and make those operations more coherent.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
