[API Review]: RT-28148 - Add createSymbols Property to AreaChart / StackedAreaChart
Jonathan Giles
jonathan.giles at oracle.com
Tue Mar 26 14:40:24 PDT 2013
I've purposefully stayed clear of this discussion, however I was just
talking to Paru (owner of all things charts-related in JavaFX), and
wanted to give my opinion based on controls API.
I would rather not introduce a SymbolFactory interface and would instead
suggest following the approach taken by cell factories / page factories
/ date picker / etc in UI controls. Namely, use the Callback interface
to pass in an object (which may be a wrapper around a number of objects
(e.g. a SymbolFeatures class which contains the Series and data item),
and which returns a Node).
Paru has opened RT-29232 for this discussion to be tracked / continued in.
-- Jonathan
On 15/03/2013 3:40 a.m., Sven Reimers wrote:
> 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
>>>
>>
>
More information about the openjfx-dev
mailing list