Hi,
Not really. A dev could just feed the DeviceMapClient a configuration map
with InputStreams for the required data sources. Let's not limit ourselves
to thinking only in file system abstractions and allow devs to build their
own logic for loading some data sources.
This is how I thought to modify the DeviceMapClient:
public DeviceMapClient(Map<String, Object> configuration) throws
InitialisationException, IOException {
devices = new HashMap<String, Device>();
patterns = new HashMap<String, Device>();
Loader loader = new Loader();
BufferedReader br;
if (configuration == null || configuration.isEmpty()) {
throw new InitialisationException("Cannot initialise the
DeviceMapClient without a configuration map.");
}
InputStream builderDataSourceIS = (InputStream)
configuration.get(DEVICE_DATA_SOURCE_PROP_NAME);
if (builderDataSourceIS == null) {
throw new
InitialisationException(buildErrorMessageForIS(DEVICE_DATA_SOURCE_PROP_NAME));
}
br = new BufferedReader(new InputStreamReader(builderDataSourceIS));
loader.loadDeviceData(br);
builderDataSourceIS.close();
InputStream builderDataSourcePatchIS = (InputStream)
configuration.get(DEVICE_DATA_SOURCE_PATCH_PROP_NAME);
if (builderDataSourcePatchIS != null) {
br = new BufferedReader(new
InputStreamReader(builderDataSourcePatchIS));
loader.loadDeviceData(br);
builderDataSourcePatchIS.close();
}
loader.setParentAttributes();
InputStream deviceDataSourceIS = (InputStream)
configuration.get(BUILDER_DATA_SOURCE_PROP_NAME);
if (deviceDataSourceIS == null) {
throw new
InitialisationException(buildErrorMessageForIS(BUILDER_DATA_SOURCE_PROP_NAME));
}
br = new BufferedReader(new InputStreamReader(deviceDataSourceIS));
loader.loadDevicePatterns(br);
deviceDataSourceIS.close();
InputStream deviceDataSourcePatchIS = (InputStream)
configuration.get(BUILDER_DATA_SOURCE_PATCH_PROP_NAME);
if (deviceDataSourcePatchIS != null) {
br = new BufferedReader(new
InputStreamReader(deviceDataSourcePatchIS));
loader.loadDevicePatterns(br);
deviceDataSourcePatchIS.close();
}
devices = loader.getDevices();
createIndex();
}
As you can see no one but us has to know the internal logics. A consumer
would just have to provide a configuration object which can be thoroughly
documented regarding its expected values.
Thanks,
Radu
On Mon, Jun 24, 2013 at 9:10 PM, Reza <[email protected]> wrote:
> Right, so if you look in the DeviceMapClient, there is a convenience
> method:
>
> loadFromFolder(String folder)
>
>
> This is kind of a remnant from OpenDDR, but basically there is a resource
> folder that is filled with xml files. Simply point the client to the folder
> and it will do the rest. Remember, there are at least 4+ xml files which
> all contribute to the index. Also, there are several internal compilation
> steps which need to be done inbetween loading these files. Right, the
> actual names of the files should be configurable, just didnt get to that
> step yet.
>
> The optimal way to do this is to detect the DeviceMap data jar in the
> classpath and load the resources without asking the user.
>
> So what you are asking for is to expose the inner methods of the Loader
> and have the developer open the device and builder files and the patch
> files and manually feed them in? They then need to know when to kick off
> the internal compiling methods too. So this would all have to be exposed.
> Not sure if an off the shelf developer is going to be able to comprehend
> the inner guts of this package and properly execute all of this...
>
> The simplest approach would be to auto detect the resource jar and use it.
> Also, create a method for the developer to load files from the local file
> system. I think its reasonable to make the actual filenames configurable
> but having the developer drive the file loading and indexing doesn't seem
> like a good feature.
>
> Also, I just moved some classes around into a package hierarchy.
>
>
> ________________________________
> From: Radu Cotescu <[email protected]>
> To: devicemap-dev <[email protected]>
> Sent: Monday, June 24, 2013 1:57 PM
> Subject: Re: devicemap java client cleanup
>
>
> Hi Reza,
>
>
> > 1 and 2) There is a generic Loader (org.apache.devicemap.client.Loader)
> > which takes in Readers (like an inputstream but it has an encoding:
> UTF8).
> > FileLoader then wraps this and loads files and I was planning on
> creating a
> > JarLoader which will detect and load resources from a jar. So it should
> > probably be organized a bit better (interface and package), but I think
> if
> > there is a new loading method, just wrap Loader, no?
>
>
> Why should we provide multiple loaders and try to imagine all the use cases
> when we could have only one way to initialise the client? The final users
> of our client are developers. I'm sure they can wrap whatever type of data
> source into an InputStream - files from the file system, files from a JAR,
> JCR nodes, Apache Sling resources, URLs, etc.
>
> I'm in favour of keeping things as simple as possible.
>
> WDYT?
>
> Cheers,
> Radu
>
