ATTN: David Gilbert: JFreeChart classes missing key methods

[TXAggie]

I have been fairly new to JFreeChart and have only had the opportunity to work with it within the last month. I have bought the Developers Guide more to help the efforts of JFreeChart than anything else. While utilizing the charting package I have notice that there seems to be some key methods left out of some classes I have been using.

XYPlot
addRangeMarker() PRESENT
addDomainMarker() PRESENT
removeRangeMarker() LEFT OUT
removeDomainMarker() LEFT OUT

IntervalMarker
getStartValue() PRESENT
getEndValue() PRESENT
setStartValue() LEFT OUT
setEndValue() LEFT OUT

Have had problems with Plot.addBackgroundImage() and Marker.setAlpha(). Used other work-arounds to accomplish these.

It didn't take much effort to add these methods myself, but thought I would bring it to your attention for future releases perhaps.

Thanks

[skunk]

There are many, many more cases just like this. For examples, all flavours of Annotation are immutable. So you are forced to either copy and paste blocks of code into a local class, or resort to subclassing and exposing the object state using hackish overrides.

[TXAggie]

I'm sure you're right. I haven't worked with Annotation yet, but the methods I was referring to (i.e. a setter to go with the getter) don't require subclassing or exposing the object state. They more or less seem left out.

These lines in IntervalMarker:

Code: Select all

    public void setStartValue(double startValue){
        this.startValue = startValue;
    }
    
    public void setEndValue(double endValue){
        this.endValue = endValue;
    }

What was the reason for these to be left out? It lets you update current markers.

And these methods I added in XYPlot:

Code: Select all

    public void removeRangeMarker(Marker marker)throws RangeMarkerDoesNotExistException{
        removeRangeMarker(marker, Layer.FOREGROUND);
    }
    
    public void removeRangeMarker(Marker marker, Layer layer) throws RangeMarkerDoesNotExistException{
        removeRangeMarker(0,marker,layer);
    }
    
    public void removeRangeMarker(int index, Marker marker, Layer layer) throws RangeMarkerDoesNotExistException{
        Collection markers;
        if (layer == Layer.FOREGROUND) {
            markers = (Collection) this.foregroundRangeMarkers.get(
                    new Integer(index)
                    );
            if (!markers.contains(marker)){
                throw new RangeMarkerDoesNotExistException(marker);
            } else
                markers.remove(marker);
        } else if (layer == Layer.BACKGROUND) {
            markers = (Collection) this.backgroundRangeMarkers.get(
                    new Integer(index)
                    );
            if (!markers.contains(marker)){
                throw new RangeMarkerDoesNotExistException(marker);
            } else
                markers.remove(marker);
        }
        notifyListeners(new PlotChangeEvent(this));
    }

I did add Two new classes for this to work:

Code: Select all

public class MarkerException extends Exception{
    private Marker marker;
    public MarkerException(Marker marker){
        this.marker = marker;
    }
    
    public Marker getMarker(){
        return this.marker;
    }
}

public class RangeMarkerDoesNotExistException extends MarkerException{
    public RangeMarkerDoesNotExistException(Marker marker) {
        super(marker);
    }
}

The same goes for DomainMarkers.
I realize there are a lot of cases like this, but my thought process on bringing this to attention was, "Why have a getter and not a setter? Why add something individually if it can't be removed individually?" Why not bring them up so as to help with a more robust new version?

Thanks

[david.gilbert]

Thanks for the feedback. The removeXXX() methods for the domain and range markers can be added fairly easily, and you are right - they should be there.

The setters for the markers is a little more complex. The markers were initially intended to be immutable, to avoid having to implement a change event notification mechanism for them (if you can modify a marker value, then it would need to notify listeners that it has changed in order to trigger an automatic chart repaint). The same goes for annotations. As it turns out, the implementation looks like it is too restrictive and so I'll probably add the change event mechanism and put in the setter methods for the markers and annotations.