[jira] [Commented] (SLING-3733) Remodel API for more natural usage of IO operations

["Andreas Schaefer (JIRA)" <ji...@apache.org>]

    [ 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)