[udig-devel] Default style on custom file type

[Jody Garnett]

Cool;

So if you can arrange for

fooHandle.resolve( Style.class, monitor ) to return non null then you 
are ready to go.

You have a couple of options:
- You can hard code this into your handle; look at ShpGeoResource on 
trunk for an example of this
- You can add an IResolveAdapaterFactory to add a default style to an 
already coded GeoResource, but it looks like you won't need to since you 
are making up your own thing?

Cheers,
Jody
> I'm trying to write a uDIG plug-in that renders a custom file type *.foo and applies a default drawing style whenever a user opens a file with extension .foo.
>
> The .foo files contain all sorts of feature types to be rendered in different styles. The user shall _not_ be burdened with editing an SLD file, I just want him to open a file and see water features in blue, parks in green, roads in grey etc.
>
> I created an extension fooStyle for net.refractions.udig.project.style that implements the StyleContent interface. My method createDefaultStyle() checks if the IGeoResource is a FooGeoResource, and if so, it reads an SLD file as a resource relative to the current class and builds a Style object from it which will then be placed onto the StyleBlackboard by the caller.
>
> Now the problem is how to ensure that the BasicFeatureRenderer selects my fooStyle instead of the standard sldStyle.
>   
Please try the above approach first, if you need to set up a copy of 
BasicFeatureRenderer that checks a different entry on the style 
blackboard then you can do that as well.
> As far as I can see, the renderer simply takes the first Style object from the blackboard, and I can't figure out how to make sure that my fooStyle appears _before_ the sldStyle.
It should be specifically checking for the "sld" entry on the style 
blackboard, order should not enter into it.
> In fact, I installed my plug-in in several different Eclipse instances, and my  plug-in appears sometimes first and sometimes last in the list.
>   
yeah plugin order is not deterministic.
> Is there a more intelligent way of disabling the default style? Is there a way of defining a filetype-to-style mapping?
>   
See above, and we may need to back port some of the magic to 1.1.x for you?
Jody