Opened 7 years ago
Closed 3 years ago
#16338 closed feature (patchwelcome)
Improve charting API: simple helper for specifying dates for an axis
| Reported by: | dylan | Owned by: | cjolif |
|---|---|---|---|
| Priority: | high | Milestone: | 1.13 |
| Component: | Charting | Version: | 1.8.1 |
| Keywords: | Cc: | dylan | |
| Blocked By: | Blocking: |
Description
A frequent request we receive for dojox/charting is to make it as easy as other toolkits to specify that an axes is a set of dates. I added a simple test created by Mike Wilcox to trunk/dojox/charting/tests/test_axes_dates.html that shows a current approach for plotting dates, but it doesn't show how to specify that the data being provided comes from a list of dates. Our other tests are simply hard coded strings for months, etc.
I think this is a very common use case, and we should simply the effort required to be able to say "the data I'm feeding this axis is a collection of dates, please handle that automatically".
Change History (6)
comment:1 Changed 7 years ago by
comment:2 Changed 7 years ago by
slightly off topic... but i'd fully support any effort to remove/redesign scaler and break backwards compatibility sooner rather than later. the whole scaler API is so frustrating and i'd even go so far as to call it a broken design because you can't override it or work around it per instance. it makes it virtually impossible to do any axis customization (eg a y-axis with log scale). i'm glad to hear that you agree it needs to be redesigned.
i think it would be good to see something before 2.0 so that we can refine the APIs if necessary before being locked into them for 2.0.
comment:3 Changed 6 years ago by
Another common request are "category" axis. Being able to create axis based on labelled categories without having to map indexed to labels. A re-design of the axis architecture to be more open would allow that.
comment:5 Changed 6 years ago by
| Milestone: | 1.9 → future |
|---|
moving to future, as I confirm I won't have time for that myself. Obviously if someone else wants to step in. That said I still think implementing #16530 which probably require breaking things is a better target.
comment:6 Changed 3 years ago by
| Milestone: | future → 1.12 |
|---|---|
| Resolution: | → patchwelcome |
| Status: | new → closed |
Given that no one has shown interest in creating a patch in the past 2+ years, I'm closing this as patchwelcome.
Yes I full agree. More generally I think that to do it cleanly the axis / scaler API should be redesigned to make this doable and more easily customizable by users. That's why I think this is more of a 2.0 thing as this probably needs to break some compatibility here.