Menu
▾
▴
Re: [Geobject-core] Re: Geobject meeting
|
From: Robert H. \(old\) <rha...@sa...> - 2002-12-10 06:17:54
|
First, a comment/question about the javadoc.=20
"An implementation may also implement
other line patterns not listed here by creating instances
of a <code>DashPattern</code>.</p>"
I thought, maybe incorrectly (it's the hair), that the USER of the =
implementation would be able to create new instances of DashPattern, if =
the implmentation supported user-defined DashPattern's. Custome =
LinePattern's like -> -> -> would be created by the impl creating it's =
own subsclass of LinePattern say NeatoLinePatterns with several enums =
that are only supported by the Neato impl of geobject.
Note that, if you are using two different impls of Geobject in the same =
VM your list of LinePatterns is going to be the union of the =
LinePatterns. This might be what you want. However, exposing getArray =
encourages USER's to serialize the getValue() int, but that's a bad =
thing to do from impl to impl. As defined, the extensible nature of =
Geobject means that the serialization should be in the framework (that =
is the framework has it's own fixed idea of line-patterns and it just =
tries to find the right geobject linepattern at run-time), or in =
Geobject itself. Ad hoc use of getByValue will not work from impl to =
impl.
I was also thinking that implementers would want to get from an index to =
an instance so that they could easily handle the various LinePatterns. =
Rather, I'd like to be able to go from an instance of LinePattern =
directly to some code for handling that LinePattern. But I was imagining =
all that code to be tucked away in the impl. This is not what I want to =
do:
if (LinePattern.NONE =3D=3D a_pattern) {
// do some code for none.
} else if (LinePattern.DASHED =3D=3D a_pattern) {
// do some dashed code
}
Rather something like this:
LinePatternImplementation impl =3D dashed_pattern_impl;
if (a_pattern.getValue() < map_line_pattern_to_impl.length) {
LinePatternImplementation impl =3D =
map_line_pattern_to_impl[a_pattern.getValue()];
}
impl.doSomeCodeForYourStyle(...);
How to build map_line_pattern_to_impl for my Geobject implementation.
One time code like this?
static LinePatternImplementation[] map_line_pattern_to_impl;
static void buildPatternMapping() {
map_line_pattern_to_impl =3D new =
LinePatternImplementation[LinePattern.getNumberOfPatterns()];
static class Pair {
public Pair(LinePattern s, LinePatternImplementation i) { m_pattern =
=3D s; m_impl =3D i; }
public LinePattern m_pattern;
public LinePatternImplementation m_impl;
};
Pair[] pairs =3D {
new Pair(LinePattern.NONE, LinePatternImpl.NONE),
new Pair(LinePattern.DASHED, LinePatternImpl.DASHED),
new Pair(LinePattern.DOTTED, LinePatternImpl.NOT_SUPPORTED),
...
}
for (int i =3D 0; i < pairs.length; i++) {
map_line_pattern_to_impl[pairs[i].m_pattern.getValue()] =3D =
pairs[i].m_impl];
}
// sparse fix up nulls
for (int i =3D 0; i < map_line_pattern_to_impl.length; i++) {
if (map_line_pattern_to_impl[i] =3D=3D null) {
map_line_pattern_to_impl[i] =3D LinePatternImpl.NOT_SUPPORTED;
}
}
=20
}
pairs should also be the source to GeobjectCapabilites...
Robert
----- Original Message -----=20
From: jesse crossley=20
To: Robert Hastings (old)=20
Cc: geo...@li... ; Dale McIntosh=20
Sent: Monday, December 09, 2002 6:28 PM
Subject: Re: [Geobject-core] Re: Geobject meeting
i can dynamically update the array as new styles are created.=20
see the attached code.=20
it seems to be (mostly) a huge pain,=20
so i'm thinking i'll rip out my code that used to care about storing =
out the=20
odder style parameters for the time being.=20
(and i'm not sure if it's a simple matter of serializing or not,=20
as my overlay objects were doing weird LeifReference (XIS specific) =
things=20
in order to restore themselves).=20
i dunno if what i was thinking of last week in LinePattern makes any =
sense,=20
but at least i could get further in my compile of the new XIS =
Geobject2.0impl ;->=20
but as DashPattern extends LinePattern and due to the way i made =
things add=20
themselves to the complete array, any LinePattern or subclass instance =
of=20
LinePattern should make it into this array.=20
but it's prolly not safe, as i rarely seem to think through all of the =
cases where=20
someone could go in and break my code.=20
=20
jdc=20
=20
"Robert Hastings (old)" wrote:=20
I'm probably confused, but it seems like GeobjectCapabilities (GC =
is garbage collection in another context) is THE place where you know =
all of the LineStyles your implementation supports not LineStyle. Why is =
it easier to have the array at LineStyle and not GeobjectCapabilities? =
Most impl's cannot just call getArray on LineStyle because they don't =
support every line style (I guess you can see I'm pretty must against =
LineStyle.getArray). Since we allow styles to be created that did not =
exist before the style must contain all the information an =
implementation will need to render it. Many implementations will not =
support user defined line styles, yet another capability? Otherwise, we =
could allow these created styles to be registered with capabilities so =
that anyone asking for what can be done can rendevou there. However, I'm =
leaning on created styles being managed by the outer framework. OK, so =
what your really after is a way to serialize line style. Should we just =
make the LineStyle Serializable. "Effective Java" decribes a way to make =
enum's serializable: public class LineStyle implements Serializable { =
private static int next_ordinal =3D 0; private final int ordinal =3D =
next_ordianl++; private static final LineStyle[] private_values =3D { =
LINE_STYLE1, LINE_STYLE2, ... } private Object readResolve() throws =
ObjectStreamException { return private_values[ordinal]; }} The only =
problem with this approach is that we we later add a LINE_STYLE to the =
spec or remove one all of the ordinals will move. We can either agree to =
maintain the ordering by, allways adding to the end and replacing =
removed contants with dummy values, or we can try to use strings for =
each, ala a hashmap. However, even with a hashmap if we remove a line =
style in the future we will cause problems since the style will not =
resolve once removed. We can agree never to remove a style, just mark it =
as deprecated. User defined should store all of the state a geobject =
impl will need to draw the line style. Again all this could be done =
outside of Geobject. So that Geobject itself is not serializable, but =
your application framework makes serializable objects to store in files, =
etc. public class LineStyleState implements Serializable { private =
transient LineStyle m_line_style; private int ordinal; public =
LineStyleState(GeobjectCapabilities gcap, LineStyle wrapped_style) { =
LineStyle[] styles =3D gcap.getLineStyles(); for (int i =3D 0; i < =
styles.length; i++ ) { if (styles[i] =3D=3D wrapped_style) { =
ordinal =3D i; } } LineStyle getStyle() { return m_line_style; =
}} public class CustomLineStyleState implements Serializable { private =
transient LineStyle m_line_style; private int[] pixels_on_off; private =
Object readResolve() throws ObjectStreamException { return new =
LineStyleState(pixels_on_off); } public getStyle() { return =
m_line_style; } public LineStyleStyle(int []p) { m_line_style =3D new =
LineStyle(p); }}=20
----- Original Message -----
From: jesse crossley
To: Robert Hastings (old)
Cc: geo...@li... ; Dale McIntosh
Sent: Monday, December 09, 2002 1:06 PM
Subject: Re: [Geobject-core] Re: Geobject meeting
because unless it is very craftily written,=20
you don't actually get all of the styles or patterns,=20
especially now that they are all concrete classes=20
and users can make their own instances of them.=20
in our impl of GeobjectCapabilities, anyway,=20
we returned hardcoded arrays of styles and patterns=20
but i don't think that'll work anymore. currently,=20
i would impl the GC method by having it call the static=20
method on the style/pattern class.=20
i added the getArray() method just because it was a simple=20
thing to put in there. what i really wanted was the=20
getThingByValue(int) methods. we serialize a lot of our=20
objects, and so i need to somehow store the patterns and=20
styles. if i store the int value, then MOST of the time i can=20
restore it by fetching the style/pattern by value. obviously,=20
for userdefined things, this ain't gonna work, but at least i'm=20
trying...=20
"Robert Hastings (old)" wrote:=20
Jesse, If you want all line patterns why not just call public =
LineStyle[] getSupportedLineStyles();RobertOne who misses meetings.=20
----- Original Message -----
From: jesse crossley
To: geo...@li...
Cc: Dale McIntosh
Sent: Monday, December 09, 2002 12:20 PM
Subject: [Geobject-core] Re: Geobject meeting
still need to discuss the use of OrientationSources, as not =
everyone is satisfied with the new usage.=20
need to discuss the possibility of overloading some primitive =
methods with LatLonAlt instead of just=20
CoordinateSource to save time and pain within the primitive =
methods.=20
tasks now assigned to me:=20
62718: copy Style.implHints=20
(i assume this just needs to be noted in the =
setPropertiesFrom method? this is actually gonna be a pain,=20
because we don't have any way to get the implHint keys. =
we could just say that in java the implHints must=20
be a Map, and then we could getImplHints and copy the Map =
into our new one)=20
62769: unit params missing=20
i'll keep looking. i noticed that GeoIcon's setRotation =
was wrong (not yet taking an OrientationSource)=20
but most of the rest looked good.=20
60937: resolve consume on GeobjectEvent.=20
why don't we just make concrete Event classes? is there =
anything to be gained by leaving them as interfaces?=20
67308: combine the EnumerationTypes.=20
have the code working on my machine, just need to check it =
in. BUT, while digging through the ETs and extending=20
classes, it seemed to me that we could still offer a =
'getPatternByValue' or 'getStyleByValue' even though we have=20
things like DashPattern extending LinePattern. we REALLY =
need this capability, even if it won't necessarily jive=20
between the times we run a GeobjectImpl. for example, =
maybe i create three LinePatterns. the code i worked on=20
will put the new LinePatterns in the array of all =
LinePatterns, LinePattern then has a static getArray() method (which=20
should return a clone for safety) and a static =
getPatternByValue(int) method. however, the next time i run, maybe=20
i don't create the three LinePatterns, and so requesting =
one of them by value could fail or return a different pattern=20
altogether. but at least within one running of a JVM i =
could get ahold of all LinePatterns. let me know if you want=20
to see the code before i check it in.=20
add get/setLabelColor to Style=20
and thoroughly document everything. my intention is to =
doc as follows: labelColor is the color for a Geobject's label=20
(which is specified within its Style object). foreground =
is for foreground colors (line colors, icon colors, GeoLabel's text=20
color), background is for background colors (fills, =
essentially).=20
this will create a difference from the Jm text object =
thingy, but if i recall correctly, this behaviour was okay with those of =
us that bothered to come to last week's meeting...=20
document that Canvases should accept other Impls' Geobjects.=20
(a documentation task, should outline possible =
implementation)=20
add Map2DCanvasCapabilities (should also have =
GeoCanvasCapabilities then, too, separate from GeobjectCapabilities?)=20
the Map2D version will add the getSupportedProjections() =
method.=20
=20
remaining questions:=20
what does 'add the URL methods to GeoIcon and =
GeoScaledImage' mean?=20
=20
that's about all i've got from the mediocre notes i took. =
anyone recall anything i missed?=20
=20
jdc=20
=20
Rich Kadel wrote:=20
Dale, Jesse,Can you send me the decisions made yesterday and =
any actions assigned? Are we going to make the concrete LatLonAlt and =
other coord classes "new"able?Thanks,Rich -- Rich Kadel=20
Chief Technology Officer=20
Polexis, Inc.=20
Direct: 619-542-7213=20
Fax: 619-542-8675=20
http://www.polexis.com/=20
transforming data into knowledge
|
