[OpenLayers-Dev] Rule subclasses and 2.6

[Tim Schaub]

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.

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

Re: equal interval rule creation stuff

As usual, I'd like to have a big picture talk before adding convenience 
methods piecemeal.  I think we can create a single method that will be 
useful for adding a variety of rule groupings.

This is relevant to creating tools to edit styles visually.  A 
shortcoming of SLD is that rules aren't organized in any way that aligns 
with common sense.  I'd like OpenLayers to adopt conventions in how we 
persist styles (specifically groups of rules) so that they make for more 
intuitive editing.

When we have methods that allow convenient creation of rule groups 
(equal interval rules for example), it makes sense to store something on 
those rules that maintains that logical grouping.  More on this later.

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

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.

As suggested above, the real power of rule based styling will be 
realized when we have decent visual style (and rule) editors.  Ideally, 
people wouldn't have to understand how to hand roll their own rules. 
Also, in the future, hopefully you'll use SLD without knowing it (it's 
just a format for persistence).  If you want to persist OpenLayers 
styles with other application configuration (in JavaScript or JSON), 
that's where OLON comes in handy.  So, in the future, you shouldn't be 
hand writing OpenLayers rules - just like you shouldn't be hand writing SLD.

Tim

> 
>> });
> 
> 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,