Hi folks, Been having a look at polyline coloring i.e. stroke and fill colors and I think it would be good to standardise on how the color data is passed on to the underlying provider and also a few of the provider files have defaults defined so would be good to pull these out into core instead. Currently, for the most part, whatever value is passed in to the Polyline setColor() and setFillColor() methods is passed straight on to the provider with the exception of Microsoft maps which passes it through the Color class first in order to split the value into RGB integers. If a mistake is made in setting this color then the first the dev user will know about it is when they get an exception from the provider API. They''ll need to check their stack trace, navigate back through the Mapstraction calls to their code in order to find out what is going on - quite a lot of work. I think we should change the methods in core to store the color value as a Color object, i.e. as soon as the dev user calls one of the methods the value they pass in is validated and if it''s not a valid color they''ll get an error. If it is valid then the provider code can make use of the Color object, explicitly requesting the color in the correct format rather than passing the value on and hoping for the best. It would be nice for the methods to support all these overloads: setColor(strHTMLColor) which accepts formats #000000, #000, 000000, 000 setColor(intRed, intGreen, intBlue) setColor(objColor) where objColor is a new mxn.util.Color It a relatively small change (I''ve pretty much done it already) but thought I''d get some opinions from the list as to whether you think it''s a worthwhile addition or not. Thanks, Derek -- Derek Fowler m. +44 (0) 7966 512 369 e. dezfowler at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20091219/0c63bb1d/attachment.htm>
Derek Fowler wrote:> Hi folks, > > Been having a look at polyline coloring i.e. stroke and fill colors > and I think it would be good to standardise on how the color data is > passed on to the underlying provider and also a few of the provider > files have defaults defined so would be good to pull these out into > core instead.I''m actually working on styling colors right now as well. :) I like this idea - so long as it doesn''t add much overhead? But creates a nice buffer with any other providers that may have alternate color mechanisms as well.> > Currently, for the most part, whatever value is passed in to the > Polyline setColor() and setFillColor() methods is passed straight on > to the provider with the exception of Microsoft maps which passes it > through the Color class first in order to split the value into RGB > integers. If a mistake is made in setting this color then the first > the dev user will know about it is when they get an exception from the > provider API. They''ll need to check their stack trace, navigate back > through the Mapstraction calls to their code in order to find out what > is going on - quite a lot of work. > > I think we should change the methods in core to store the color value > as a Color object, i.e. as soon as the dev user calls one of the > methods the value they pass in is validated and if it''s not a valid > color they''ll get an error. If it is valid then the provider code can > make use of the Color object, explicitly requesting the color in the > correct format rather than passing the value on and hoping for the best. > > It would be nice for the methods to support all these overloads: > > setColor(strHTMLColor) which accepts formats #000000, #000, 000000, 000 > setColor(intRed, intGreen, intBlue) > setColor(objColor) where objColor is a new mxn.util.Color > > It a relatively small change (I''ve pretty much done it already) but > thought I''d get some opinions from the list as to whether you think > it''s a worthwhile addition or not. > > Thanks, > Derek > > -- > Derek Fowler > m. +44 (0) 7966 512 369 > e. dezfowler at gmail.com <mailto:dezfowler at gmail.com> > ------------------------------------------------------------------------ > > _______________________________________________ > Mapstraction mailing list > Mapstraction at lists.mapstraction.com > http://lists.mapstraction.com/listinfo.cgi/mapstraction-mapstraction.com >-- Andrew Turner m: 248.982.3609 e: andrew at highearthorbit.com t: @ajturner b: http://highearthorbit.com w: http://geocommons.com Introduction to Neogeography - http://oreilly.com/catalog/neogeography -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mapstraction.com/pipermail/mapstraction-mapstraction.com/attachments/20091219/43af3b45/attachment.htm>