[API Review]: RT-28148 - Add createSymbols Property to AreaChart / StackedAreaChart

Mark Fortner phidias51 at gmail.com
Tue Mar 26 17:13:23 PDT 2013

Let's suppose that you're trying to display some financial data.  Let's say
that some arbitrary series contains data from a specific stock.  Let's say
that another arbitrary series contains data from an arbitrary index fund,
or from a share index like  S&P500, Dow Jones Average, etc.  The only way
to distinguish these series is by a Series userObject (stocks use a Stock
POJO, index funds use an IndexFund POJO, etc).

For stocks we want to use dashed lines, and we want to configure it to use
a specific symbol to display a popup and display share information for a
particular date (perhaps you want to display the share-related news on that
date, so you can correlate it's crappy performance against the news for
that day).  For index funds, we want a different symbol and popup (like
information about the contributions of each security in the fund), and we
want solid lines instead of dashed lines.

Now we know that on the first day of the project the PM is going to ask for
this functionality, and on the second day, he's going to realize that he
also wants to add data from mutual funds, or some other security type that
only he and God know.

So how do I configure this to simply inject a new type of symbol and popup
for a given type of series without constantly touching this code?  Do I
create something that I call a Factory that implements Callback and
register new symbol and popups with that factory via my favorite DI
framework?  Could I store this type of configuration data in FXML? Could I
use with SceneBuilder to bind it with  data, and register Symbols, and
popups.  Ideally, you would want any solution to be both codeable and

Anyway, just wanted to give you guys some idea of the landscape of
injection points that people typically want when using charts and why they
want them.


On Tue, Mar 26, 2013 at 4:10 PM, Richard Bair <richard.bair at oracle.com>wrote:

> > 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.
> Just real quickly on this point, with Lambda's this should all melt away.
> Lambda's bring with them some additional type inference which will be able
> (in most cases, and I think in all cases with Callback) to remove all the
> noise. So it becomes:
> foo.setOnWhateverCallback((arg) -> { something });
> And that's it.

More information about the openjfx-dev mailing list