[OpenLayers-Dev] Rule subclasses and 2.6

[Tim Schaub]

Hey-

Christopher Schmidt wrote:
> On Mon, Apr 07, 2008 at 07:40:59AM -0600, Tim Schaub wrote:
>> Christopher Schmidt wrote:
>>> On Sat, Apr 05, 2008 at 03:30:16PM -0600, Tim Schaub wrote:
>>> I don't like encouraging users towards things that are going to change
>>> in the next release, but I prefer it over not documenting what I
>>> consider an incredibly useful new aspect of working with OpenLayers in
>>> 2.6.
>> Cool.  Glad we see things the same way.  I'd rather let out a limited 
>> set of functionality that we think is more solid.
> 
> It sounds to me like we don't see things the same way, in that case? If
> so, we should remove Rule subclasses from the OpenLayers code, and not 
> include filters, since they're not solid (being only 12 hours old)?
> 
> Perhaps you mean 'let out' in a different way than I do. 

Well, I also said I thought it would make sense to branch prior to a 
release - so we could add new features to the trunk and let them settle 
(I still hold that sandboxes are good for development, but not for real 
user testing).

Anyway, I still think we agree.  Rule subclasses are getting new names. 
  Would be very nice if this wasn't being done this late in the process. 
  I apologize for not raising a fuss earlier and appreciate your help 
this late.

> 
>>>> * The most useful shortcuts I see are for adding groups of rules to a 
>>>> style map.  
>>> Ignoring, for the moment, that I still don't comprehend when to use a
>>> Style vs. a StyleMap, I agree so strongly with this that I've actually
>>> already started pondering coding equal interval rule creation stuff. 
>> Re: StyleMap
>>
>> You give a vector layer a style map.  This is functionally a dictionary 
>> of named styles.  You can specify a different style for different 
>> situations.  A common pattern is to specify a different style when the 
>> user selects a feature.  The key in the style map is referred to as the 
>> rendering intent.  A typical application might render with one style 
>> when sketching a temporary feature, with another style when a feature is 
>> persisted, and with another style when a feature is selected.
>>
>> The Style class gives you a place to collect groups of rules (color 
>> populated cities this way, color ghost towns that way).
>>
>> The StyleMap class gives you a way to organize multiple Style instances 
>> for use in different situations (switch to this style when user clicks 
>> on a feature).
> 
> Yeah, I'd gotten that far, except I can't figure out how to make a
> StyleMap *do* anything: I thought that the way to do it was something
> like StyleMap({default: style, select: select_style}), but then adding
> that, when I select a feature, it doesn't change, so I guess I'm just
> doing it wrong. 
> 

Hmm.  Could be a spelling error somewhere.  The georss-flickr.html 
example creates a StyleMap with a "select" rendering intent.

The default renderIntent for the SelectFeature control is "select" 
(http://trac.openlayers.org/browser/trunk/openlayers/lib/OpenLayers/Control/SelectFeature.js#L101). 
  This renderIntent is sent in the drawFeature call.

The drawFeature method now works with a renderIntent 
(http://trac.openlayers.org/browser/trunk/openlayers/lib/OpenLayers/Layer/Vector.js#L418).

All this is more complex and error prone than it needs to be - in the 
name of backwards compatibility.  If your feature has a style property, 
if your layer has a style property, or if your control has a selectStyle 
property the renderIntent will not be respected.

In the future (3.0), this can be simplified significantly.

If this is not working as expected, we should fix it prior to release.

>> Re: equal interval rule creation stuff
>>
>>>> OpenLayers.StyleMap.addRuleGroup({
>>>>      intents: ["default"], // this would be the default
>>>>      type: OpenLayers.Rule.CLASS_BREAKS,
>>>>      property: "population",
>>>>      values: [0, 10000, 20000, 30000],
>>>>      symbolizers: array // length of values.length -1
>>> hm, -1, or plus one? Ah, I guess Infinity can be a number, so -1 is
>>> good.
>> Confused.  The idea above was that you create a rule for each interval 
>> between items in the values array.  That means the number of symbolizers 
>> is one less than the length of the values array (one symbolizer for 
>> 0>=x>10000, one for 10000>=x>20000, and one for 20000>=x>30000). 
>> Anyway, also for later.
> 
> Right, I was trying to figure out how this works when you want a rule
> for "Anything above this point", which I had assumed was a default; once
> I realized that could be explicitly stated, there was no longer a need
> for it to be implicit, so my confusion went away. 
> 

Ah, got it.  Yeah, something like the following works:

     values: [Number.NEGATIVE_INFINITY, 0, Number.POSITIVE_INFINITY]


>> So, in the future, you shouldn't be hand writing OpenLayers rules -
>> just like you shouldn't be hand writing SLD.
> 
> To me, this statement reads the same as "you shouldn't be hand writing
> OpenLayers Layer definitions -- just like you shouldn't be hand writing
> WMC." I agree with the latter, but not with the former in all cases.
> It seems that there are sets of common rules that are easily constructed
> in code -- the example above seems simple enough to me. (Serializing out
> to SLD from that is an obvious next step if you care about things other
> than OpenLayers.) I don't think that it suffers anymore than doing web
> site design without a WYSIWYG editor does: You can still pick out colors
> using your color dropper and writing them into code (or in the HTML
> case, CSS) without a graphical editor needing to be involved.

Again, I think we agree.  No absolutes here.  We (you and I) will 
continue to code by hand.  I was using "you" more generally above.  I 
think tools for configuring a map w/o writing code would be of general use.

Tim

> 
> Regards,