[
https://issues.apache.org/jira/browse/IMAGING-159?focusedWorklogId=650331&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-650331
]
ASF GitHub Bot logged work on IMAGING-159:
------------------------------------------
Author: ASF GitHub Bot
Created on: 14/Sep/21 03:16
Start Date: 14/Sep/21 03:16
Worklog Time Spent: 10m
Work Description: gwlucastrig edited a comment on pull request #116:
URL: https://github.com/apache/commons-imaging/pull/116#issuecomment-918761710
I saw the note you posted on the Commons mailing list about the design of
this. If you're still looking for ideas for alternate approaches, maybe this
will help. I'm wondering if just a simple brute-force approach might do the
trick. So I will throw out a wild idea (which I'd be the first to admit I have
not thought through thoroughly).
We have a number of issues:
1. Handle cases where applications pass in null imaging parameters (just use
defaults)
2. Handle cases where applications pass in an instance of the generic
ImagingParameters base class.
3. Handle cases where applications pass in an instance of the subject-matter
imaging parameters (i.e. TiffImagingParameters, PngImagingParameters, etc.).
4. Handle cases where applications pass in the wrong thing.
```
TestStuff testStuff = new TestStuff(); // works on TIFFs (for example)
testStuff.aTypicalMethod(null);
testStuff.aTypicalMethod(imgParams);
testStuff.aTypicalMethod(tiffParams);
testStuff.aTypicalMethod(pngParams); // throws exception
```
And we'd like to make the contents of "aTypicalMethod" be pretty compact.
In this case, using TiffImagingParameters as an example, what if
TiffImagingParameters (and all its brothers and sisters) had a static method
called resolveParameters(ImagingParameters) that worked like:
```
void aTypicalMethod(ImagingParameters imagingParameters) {
TiffImagingParameters params =
TiffImagingParameters.resolveParameters(imagingParameters);
// now do some work using the parameters
}
```
**How we make this work**
The base class would define two constructors. A no-argument constructor and
a "copy constructor".
```
public ImagingParameters(){
}
public ImagingParameters(ImagingParameters source) {
this.bufferedImageFactory = source.bufferedImageFactory;
this.fileName = source.fileName;
this.pixelDensity = source.pixelDensity;
this.strict = source.strict;
}
```
Subject-matter specific parameters classes would implement compatible
constructors:
```
public TiffImagingParameters(){
}
public TiffImagingParameters(ImagingParameters imagingParameters){
super(imagingParameters);
}
```
Finally, each parameters class would implement a static method:
```
static public TiffImagingParameters resolveParameters(ImagingParameters
imagingParameters) {
TiffImagingParameters params;
if (imagingParameters == null) {
return new TiffImagingParameters();
} else if (imagingParameters instanceof TiffImagingParameters) {
return (TiffImagingParameters) imagingParameters;
} else if (ImagingParameters.class.equals(imagingParameters.getClass()))
{
// the specified class is the generic, base class.
// so just copy it's content into a new TiffImagingParameters instance
return new TiffImagingParameters(imagingParameters);
} else {
// In this case, the calling application gave us an instance of an
// incompatible parameters class.
throw new IllegalArgumentException(
"Invalid imaging parameters class "
+ imagingParameters.getClass().getSimpleName());
}
}
```
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@commons.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 650331)
Time Spent: 9.5h (was: 9h 20m)
> There should be a Parameters class
> ----------------------------------
>
> Key: IMAGING-159
> URL: https://issues.apache.org/jira/browse/IMAGING-159
> Project: Commons Imaging
> Issue Type: Improvement
> Components: imaging.*
> Affects Versions: 1.0-alpha2
> Reporter: Benedikt Ritter
> Assignee: Bruno P. Kinoshita
> Priority: Major
> Labels: github
> Fix For: 1.0-alpha3
>
> Time Spent: 9.5h
> Remaining Estimate: 0h
>
> Currently options for image I/O are defined as Maps. The leads to the problem
> that our code has to validate parameter types when they are used:
> {code:java}
> final Object value = params.get(PARAM_KEY_COMPRESSION);
> if (value != null) {
> if (!(value instanceof Number)) {
> throw new ImageWriteException(
> "Invalid compression parameter, must be numeric: "
> + value);
> }
> compression = ((Number) value).intValue();
> }
> {code}
> This can be simplified if we define a Parameters class that provides
> additional methods like {{public int getInt(String key)}}. The implementation
> could then look up the value from the map through an exception if it is null
> or not a number.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
