[OpenLayers-Dev] Rule subclasses and 2.6

[Christopher Schmidt]

On Sat, Apr 05, 2008 at 03:30:16PM -0600, Tim Schaub wrote:
> Here's the problem.
> 
> Currently, you can do:
> 
> var popRule = new OpenLayers.Rule.Comparison({
>      minScaleDenominator: 50000,
>      symbolizer: {fillColor: "red"},
>      type: OpenLayers.Rule.Comparison.GREATER_THAN_OR_EQUAL_TO,
>      property: "Population",
>      value: 10000
> });
> 
> var catRule = new OpenLayers.Rule.Comparison({
>      minScaleDenominator: 100000,
>      symbolizer: {fillColor: "blue"},
>      type: OpenLayers.Rule.Comparison.EQUAL_TO,
>      property: "Category",
>      value: "city"
> });
> 
> var logRule = new OpenLayers.Rule.Logical({
>      type: OpenLayers.Rule.Locical.AND,
>      rules: [popRule, catRule]
> });
> 
> Now, when you create a style using the logRule, your expectations are 
> likely not to be met.
> 
> Logical filters have child filters.  Filters do not have scale 
> constraints or symbolizers.

Okay. That's fair.

> I know you could say that the OpenLayers.Rule.Logical wrapper strips the 
> scale constraints and symbolizers from the child rules, but I think this 
> defies logic.  I've already been asked if symbolizers from child rules 
> extend symbolizers of the parent rule.  This is not convenient, this is 
> confusing.

Agreed.

> If we want convenience methods (shortcuts to the code I proposed below), 
> I suggest we put them elsewhere (on OpenLayers.Rule, OpenLayers.Style, 
> or OpenLayers.StyleMap).

Yep.

> Frankly, I'd rather wait until we identify common patterns before 
> deciding on what is going to be the most convenient API.  I know that 
> Andreas was trying to simplify the style stuff and felt that adding too 
> many classes would make it harder to get the code in.  I think we'd all 
> rather see it done right.  Convenience can come later*.

Okay. What does this mean for a 2.6 that is released without Filters? A
2.6.1 which adds them, and moves Rules to API Properties? Do we leave
the example, and document in the example that anything using it will
need to change in the future?

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.

> * 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. 

> The addUniqueValueRules mehtod is an example of this.  Other 
> common rule groupings are class breaks, equal interval, proportional 
> symbol, etc.  Having methods to quickly produce groups of rules for 
> these would vastly improve style creation.  If you have to add one rule 
> at a time, you're doing something wrong.

As is typically the case for me :)

> 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.

> });

So, with this, I'm convinced that:
 * In 2.7, Rule.Logical won't exist (or won't do what it does now).
 * In 2.6, We can drop API* from it 

Does that sufficiently solve the problem for 2.6 such that we can move
forward?

Regards,
-- 
Christopher Schmidt
MetaCarta