[API Review]: RT-28148 - Add createSymbols Property to AreaChart / StackedAreaChart
Sven Reimers
sven.reimers at gmail.com
Thu Mar 14 07:40:59 PDT 2013
My 2$c..
I do not like the idea of having additional Symbol objects - thinking of
large datasets this sounds like a significant overhead in cpu and memory.
I would prefer
public interface SymbolFactory {
/** Get's a series specific symbol. */
Node getSymbol(Series<X,Y> series, Data<X, Y> dataItem);
}
On the other hand - do we want one factory per series? The proposed api
would allow for different symbols for the same series. Do we want to
support this?
As with allmost all things in JavaFX I would say this could be a property
that you can change, and with this the generated symbols change (maybe not
used that much, but consistent non the less). Passing the factory in a
constructor is not good for fxml and other rapid things who like the
builder approach. So we should try to keep this out of the constructor and
make it accessible via a property or at least a set method.
This still looks like more discussion is needed for such an API change,
which does not replace my original API-Review request. I think having
simple facility to switch symbols on /off is a change small enough and
independent of this bigger discussion about general further enhancements of
the charts API, which may be too late for FX8, while the small change maybe
still has a chance of getting into FX8.
So, please let us discuss this in a separate thread and keep the discussion
here focussed on the original change.
-Sven
P.S.Perhaps we can take try to separate things we need in FX standard API's
from things that may be nice to have, but can be implemented as extensions
to the existing charts and provided by a project like jfxtras.org.
On Wed, Mar 13, 2013 at 7:31 PM, Mark Fortner <phidias51 at gmail.com> wrote:
> The SymbolFactory idea should probably be discussed a little further.
>
> It would be useful if there was a simple Symbol interface that you could
> use. This would let you turn any Node subclass into a Symbol.
>
> public interface ISymbol{
>
> Node getNode();
> void setStyle(.....)
> void addEventHandler(....)
> void removeEventHandler(....)
>
> }
>
> The event handler methods would insure that the symbol can always respond
> to mouseover and click events (or any other events the user wants to
> support). The style method makes it easy to make the symbol pretty.
>
> The factory would then do something simple like:
>
> public interface ISymbolFactory {
>
> /** Get's a series specific symbol. */
> ISymbol getSymbol(Series<X,Y> series, Data<X, Y> dataItem);
>
> }
>
>
> Inside the chart, the default implementation of the SymbolFactory could be
> an anonymous inner class or create an external implementation if you wanted
> it to serve as a template for users to extend and customize. You could
> pass new implementations of the SymbolFactory into the class in the
> constructor if you wanted to change the look. You'd want to do this before
> you actually started passing data to the chart, hence the idea of putting
> the factory in a constructor.
>
> Does that sound reasonable?
>
>
> Mark
>
>
>
> On Tue, Mar 12, 2013 at 3:01 AM, Sven Reimers <sven.reimers at gmail.com>wrote:
>
>> I like the idea of a symbol factory as well, but it will need to be in
>> some way configured per series, since a data item (XYChart.Data) does not
>> know about its series.
>>
>> Seems this may be a bigger API change though - Should we track this
>> separately?
>>
>> Any further comments?
>>
>> -Sven
>>
>>
>>
>> On Tue, Mar 12, 2013 at 12:33 AM, Jasper Potts <jasper.potts at oracle.com>wrote:
>>
>>> A symbol factory would also be a good idea, take in data item and return
>>> Node.
>>>
>>> Jasper
>>>
>>> On Mar 11, 2013, at 4:20 PM, Mark Fortner <phidias51 at gmail.com> wrote:
>>>
>>> > I recently came across the "createSymbols" property code in the
>>> LineChart
>>> > and was wondering if there was some reason to write it this way rather
>>> than
>>> > simply having a default implementation of some Symbol interface which
>>> the
>>> > user can replace by simply setting the value.
>>> >
>>> > For my application, I ended up writing some conditional decorators for
>>> the
>>> > symbol, but as I was doing this I thought how much easier it would be
>>> if
>>> > the symbols had a factory where one could register new
>>> implementations, or
>>> > replace the factory itself to provide some conditional switching
>>> logic, etc.
>>> >
>>> > Any thoughts on improving the flexibility of the charts?
>>> >
>>> > Cheers,
>>> >
>>> > Mark
>>> >
>>> >
>>> >
>>> > On Mon, Mar 11, 2013 at 3:53 PM, Paru Somashekar <
>>> > parvathi.somashekar at oracle.com> wrote:
>>> >
>>> >> Ok thanks Jasper. That makes sense. I updated RT-21539 with the our
>>> plan
>>> >> of not adding the API at the Series level.
>>> >>
>>> >> thanks,
>>> >> Paru.
>>> >>
>>> >> On 3/11/13 3:25 PM, Jasper Potts wrote:
>>> >>
>>> >>> I feel like adding "createSymbols" boolean property to Area,&
>>> >>> StackedArea charts makes sense to match LineChart.
>>> >>>
>>> >>>
>>> >>> I don't like the idea of adding API to the series object on XYChart
>>> as
>>> >>> that is more generic and used by many chart types. If the user needs
>>> fine
>>> >>> grain control of symbols like in RT-21539 they can turn auto symbol
>>> >>> generation off with "createSymbols = false" then create their own
>>> symbol
>>> >>> nodes for the cases when they do want them.
>>> >>>
>>> >>> Thanks
>>> >>>
>>> >>> Jasper
>>> >>>
>>> >>> On Mar 8, 2013, at 10:08 AM, Paru Somashekar<parvathi.**
>>> >>> somashekar at oracle.com <parvathi.somashekar at oracle.com>> wrote:
>>> >>>
>>> >>> There is a request for adding the createSymbols flag at the XYChart's
>>> >>>> Series level instead of on Chart.
>>> >>>> JIRA : http://javafx-jira.kenai.com/**browse/RT-21539<
>>> http://javafx-jira.kenai.com/browse/RT-21539>
>>> >>>>
>>> >>>> I think it might be a good idea to add it at the Series level so
>>> that
>>> >>>> one can turn ON / OFF symbols per Series rather than for all the
>>> series of
>>> >>>> a chart.
>>> >>>> The API could continue to be the same - except live at the Series
>>> level.
>>> >>>> Each chart can then create symbols for each of its Series only if
>>> this flag
>>> >>>> is turned on.
>>> >>>> This might however not make much sense for Scatter, Bubble and
>>> BarCharts.
>>> >>>> What do you think Jasper?
>>> >>>>
>>> >>>> -Paru.
>>> >>>>
>>> >>>> On 3/8/13 4:12 AM, Sven Reimers wrote:
>>> >>>>
>>> >>>>> Hi all
>>> >>>>>
>>> >>>>> AreaChart and StackedAreaChart are missing an API to simply
>>> disable the
>>> >>>>> creation of symbols. At the moment this is only possible by
>>> complex css
>>> >>>>> style acrobatics. LineChart on the other hand already provides a
>>> simple
>>> >>>>> way
>>> >>>>> to do this. The proposed tweak takes the existing API from
>>> LineChart and
>>> >>>>> adds this to AreaChart and StackedAreaChart.
>>> >>>>>
>>> >>>>> Desired API change:
>>> >>>>>
>>> >>>>> /**
>>> >>>>> * Indicates whether symbols for data points will be created or
>>> >>>>> not.
>>> >>>>> *
>>> >>>>> * @return true if symbols for data points will be created and
>>> >>>>> false
>>> >>>>> otherwise.
>>> >>>>> */
>>> >>>>> public final boolean getCreateSymbols() { return
>>> >>>>> createSymbols.getValue(); }
>>> >>>>> public final void setCreateSymbols(boolean value) {
>>> >>>>> createSymbols.setValue(value); }
>>> >>>>> public final BooleanProperty createSymbolsProperty() { return
>>> >>>>> createSymbols; }
>>> >>>>>
>>> >>>>> Desired additional CSS property (incldues additional
>>> StyleableProperty):
>>> >>>>>
>>> >>>>> -fx-create-symbols
>>> >>>>>
>>> >>>>>
>>> >>>>> JIRA:
>>> >>>>> http://javafx-jira.kenai.com/**browse/RT-28148<
>>> http://javafx-jira.kenai.com/browse/RT-28148>
>>> >>>>>
>>> >>>>> Thank
>>> >>>>>
>>> >>>>> -Sven
>>> >>>>>
>>> >>>>> P.S. An updated patch will hopefully be available there too.
>>> >>>>>
>>> >>>>>
>>> >>
>>>
>>>
>>
>>
>> --
>> Sven Reimers
>>
>> * Senior Expert Software Architect
>> * NetBeans Dream Team Member: http://dreamteam.netbeans.org
>> * Community Leader NetBeans: http://community.java.net/netbeans
>> Desktop Java:
>> http://community.java.net/javadesktop
>> * Duke's Choice Award Winner 2009
>> * Blog: http://nbguru.blogspot.com
>>
>> * XING: https://www.xing.com/profile/Sven_Reimers8
>> * LinkedIn: http://www.linkedin.com/in/svenreimers
>>
>> Join the NetBeans Groups:
>> * XING: http://www.xing.com/group-20148.82db20
>> * NUGM: http://haug-server.dyndns.org/display/NUGM/Home
>> * LinkedIn: http://www.linkedin.com/groups?gid=1860468
>> http://www.linkedin.com/groups?gid=107402
>> http://www.linkedin.com/groups?gid=1684717
>> * Oracle: https://mix.oracle.com/groups/18497
>>
>
>
--
Sven Reimers
* Senior Expert Software Architect
* NetBeans Dream Team Member: http://dreamteam.netbeans.org
* Community Leader NetBeans: http://community.java.net/netbeans
Desktop Java:
http://community.java.net/javadesktop
* Duke's Choice Award Winner 2009
* Blog: http://nbguru.blogspot.com
* XING: https://www.xing.com/profile/Sven_Reimers8
* LinkedIn: http://www.linkedin.com/in/svenreimers
Join the NetBeans Groups:
* XING: http://www.xing.com/group-20148.82db20
* NUGM: http://haug-server.dyndns.org/display/NUGM/Home
* LinkedIn: http://www.linkedin.com/groups?gid=1860468
http://www.linkedin.com/groups?gid=107402
http://www.linkedin.com/groups?gid=1684717
* Oracle: https://mix.oracle.com/groups/18497
More information about the openjfx-dev
mailing list