[OpenLayers-Dev] Rule subclasses and 2.6

[Christopher Schmidt]

On Thu, Apr 03, 2008 at 10:21:39AM +0200, Andreas Hocevar wrote:
> On Thu, Apr 3, 2008 at 6:14 AM, Tim Schaub <tschaub at openplans.org> wrote:
> >  The new style work includes the addition of OpenLayers.Rule and
> >  subclasses.  The base Rule class corresponds well to the sld:Rule
> >  element in the SLD spec (min/max limits constraints, symbolizers, etc.).
> >
> >  The subclasses of Rule (Comparison, FeatureId, and Logical) correspond
> >  well to ogc:Filter elements in the Filter Encoding specification.
> >  Though our Rule subclasses can have a symbolizer, an ogc:Filter knows
> >  nothing of a symbolizer - in SLD, an ogc:Filter element is a child of an
> >  sld:Rule that has a symbolizer.
> 
> To me, a logical step would be to have one Rule class, which has
> minScale, maxScale, symbolizer, and a filter property. There would be
> a new class OpenLayers.Filter with subclasses with the filter-related
> code of the current Rule subclasses. I think that is in line with what
> you think.
> 
> >  1) Do no mark Rule subclasses as part of the API.  Later, change them so
> >  they are Filter subclasses and require that they be added to a Rule
> >  (with a symbolizer) for things like styling.  They could also be used
> >  alone (without rules) for things like WFS.  This would also require
> >  changing the georss-flickr.html example (that uses Rule.Comparison) and
> >  the wiki page on styling.
> 
> I am in favour of that option. We do not encourage people to touch
> rules directly anyway (except for the georss-flickr example).
> 
> Also, the proposed change does not look like too much work to me.

I must be missing something.

We've got significant new functionality that allows you to style
features based on their attributes via the Style/Rule system, a I
understand it.

This allows me to, for example, take a list of places named Cambridge,
around the world, with their population values, and give them different
sizes and colors according to population:

  http://crschmidt.net/mapping/cambridge-geojson.html

As much as I feel that the current system is somewhat complex, I do
think it's pretty cool. Not a lot of code, given how much has to be
done: it's not an easy problem to solve. This seems to me to have a
clear benefit for thematic mapping: it fits neatly into what used to be
forced into the application space, I think.

I can't figure out how to do this without using OpenLayers.Rule
subclasses.

Are we saying we're going to not make a committment to supporting
applications written against this system in 2.6 going forward? That my
cambridge-geojson example may break in the future?

I understand that perhaps we chose the wrong name. I'm cool with that;
we may want to change it in the future. But from what I understand,
Filters would replace Rule subclasses pretty directly: there wouldn't be
some *other* kind of Rule.Comparison that we would want that namespace
for, it would just be moving to Filter.Comparison instead. (If I'm wrong
on this, that would be good to know.)

Given that, I don't see how stating that we will maintain these classes
going forward hurts us. If users find that they transition their
applications, they can simply exclude the Rule subclasses from their
personal build profile, and they'll have the support they need. Heck, we
could even pull them out of the default build profile, with specific
instructions on how to keep them around, if file size is the concern.
I do believe that we should not require application authors who write
against this code in 2.6 to have to change their applications before
they can use 2.7. If we go that route, in my opinion, we're abondoning
the feature for this release... before it's even been used.

Regards,
-- 
Christopher Schmidt
MetaCarta