[API Review]: RT-28148 - Add createSymbols Property to AreaChart / StackedAreaChart
Mark Fortner
phidias51 at gmail.com
Tue Mar 26 15:19:00 PDT 2013
The problem that I have with the Callback interface is that there are no
semantics around it. You use the same interface to handle getting values
as you do rendering them. At least with a Swing CellRenderer you knew what
was expected.
The other problem is that the generics around the Callback make it
virtually unreadable. If you want to extend Callback to provide a more
meaningful interface, that might work.
The other thing I'd like to see is more injection points for basic types of
rendering. A SeriesRenderer interface for example that lets you inject how
you want a series rendered. A LegendItemRenderer to let you determine how
to render a legend item. Zooming and Panning algorithms and controls, are
just a few of the things that spring to mind.
Cheers,
Mark
On Tue, Mar 26, 2013 at 2:48 PM, Paru Somashekar <
parvathi.somashekar at oracle.com> wrote:
> Hi Sven,
>
> I shall review the patch attached to RT-28148 and test it, I can check it
> in once Rich approves of the change.
> I have created a new JIRA for additional flexibility for symbol creation
> in charts.
> https://javafx-jira.kenai.com/**browse/RT-29232<https://javafx-jira.kenai.com/browse/RT-29232>.
> We can add the discussion to the comments in the JIRA.
>
> thanks,
> Paru.
>
>
> On 3/26/13 12:54 PM, Sven Reimers wrote:
>
>> Hi guys,
>>
>> it seems to me that nobody objected to go forward with this tweak - what
>> are the next steps?
>>
>> Thanks
>>
>> -Sven
>>
>>
>> On Thu, Mar 14, 2013 at 3:40 PM, Sven Reimers<sven.reimers at gmail.com**
>> >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<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>
>>>>>>>>>> <
>>>>>>>>>>
>>>>>>>>> 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>
>>>>>>>>>>> <
>>>>>>>>>>>
>>>>>>>>>> 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<http://community.java.net/netbeans>
>>>>> Desktop Java:
>>>>> http://community.java.net/**javadesktop<http://community.java.net/javadesktop>
>>>>> * Duke's Choice Award Winner 2009
>>>>> * Blog: http://nbguru.blogspot.com
>>>>>
>>>>> * XING: https://www.xing.com/profile/**Sven_Reimers8<https://www.xing.com/profile/Sven_Reimers8>
>>>>> * LinkedIn: http://www.linkedin.com/in/**svenreimers<http://www.linkedin.com/in/svenreimers>
>>>>>
>>>>> Join the NetBeans Groups:
>>>>> * XING: http://www.xing.com/group-**20148.82db20<http://www.xing.com/group-20148.82db20>
>>>>> * NUGM: http://haug-server.dyndns.org/**display/NUGM/Home<http://haug-server.dyndns.org/display/NUGM/Home>
>>>>> * LinkedIn: http://www.linkedin.com/**groups?gid=1860468<http://www.linkedin.com/groups?gid=1860468>
>>>>> http://www.linkedin.com/**groups?gid=107402<http://www.linkedin.com/groups?gid=107402>
>>>>> http://www.linkedin.com/**groups?gid=1684717<http://www.linkedin.com/groups?gid=1684717>
>>>>> * Oracle: https://mix.oracle.com/groups/**18497<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<http://community.java.net/netbeans>
>>> Desktop Java:
>>> http://community.java.net/**javadesktop<http://community.java.net/javadesktop>
>>> * Duke's Choice Award Winner 2009
>>> * Blog: http://nbguru.blogspot.com
>>>
>>> * XING: https://www.xing.com/profile/**Sven_Reimers8<https://www.xing.com/profile/Sven_Reimers8>
>>> * LinkedIn: http://www.linkedin.com/in/**svenreimers<http://www.linkedin.com/in/svenreimers>
>>>
>>> Join the NetBeans Groups:
>>> * XING: http://www.xing.com/group-**20148.82db20<http://www.xing.com/group-20148.82db20>
>>> * NUGM: http://haug-server.dyndns.org/**display/NUGM/Home<http://haug-server.dyndns.org/display/NUGM/Home>
>>> * LinkedIn: http://www.linkedin.com/**groups?gid=1860468<http://www.linkedin.com/groups?gid=1860468>
>>> http://www.linkedin.com/**groups?gid=107402<http://www.linkedin.com/groups?gid=107402>
>>> http://www.linkedin.com/**groups?gid=1684717<http://www.linkedin.com/groups?gid=1684717>
>>> * Oracle: https://mix.oracle.com/groups/**18497<https://mix.oracle.com/groups/18497>
>>>
>>>
>>
>>
>
More information about the openjfx-dev
mailing list