[
https://issues.apache.org/jira/browse/SLING-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated SLING-3733:
-----------------------------------
Fix Version/s: (was: Sling Eclipse IDE 1.2.2)
Sling Eclipse IDE 1.2.4
> 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.2.4
>
>
> 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
(v7.6.3#76005)
