Re: [HACKYSTAT-DEV-L] Is it possible to allow multiple CategorySeries with the same name in CategoryDataModel?

[(Cedric) Qin ZHANG]

It depends on user input. An obvious sample would be:
streams mystreams() = {"description", "unitLabel",  MyReducer()}
chart mychart() = {"chartTitle", mystream(), mystream()}

Though it does not make too much sense in reality, it's perfectly legal 
and I cannot allow exception to be thrown for legal input.

A more subtle example used to appear on the telemetry wall. It's very 
real. (If you are really interested, I can spend some time dig it up.) 
That's the reason why I initially introduced the workaround.

Cheers,

Cedric





Philip Johnson wrote:
Cedric,

Just out of curiosity, what is the situation in which you would prefer 
series with the exact same name?  Doesn't every trend line have some 
sort of unique specification?  Or am I misunderstanding things?

Thanks,
Philip

--On Monday, March 27, 2006 5:26 PM -1000 Hongbing Kou 
<[EMAIL PROTECTED]> wrote:

Hi, Cedric,

I think it is reasonable to disallow identical series name in chart
because you will not be able to tell which line is for which series if
two of them are identical. For instance, the project member active time
series must have developer's ID or email attached to distinguish 
category
series on active time.

I remember the restriction is on hackyCore_Report. If you really want
same series name and there is good justification you can go ahead to
change the internal implementation of CategoryDataModel. I think there
will not have other ripple effects once all unit tests pass.

Thanks,
Hongbing

(Cedric) Qin ZHANG wrote:
Hi, Philip and Hongbing,

I am cleaning Core_Telemetry code and there is some workaround I
really want to get rid of.

Current CategoryDataModel blows up when you add more than one
CategorySeries with the same name. I have to use pretty arbitrary
workaround by adding stars to category name in case of duplication.

I am not sure whether this is a restriction in JFreeChart or
Core_Report. My understanding is this is caused by CategoryDataModel's
internal use of Map and keys CategorySeries by name. If I am right,
then it won't be hard to remove this restriction.

Thanks,

Cedric