Configuring Tracking Strategy

> Hello,
>
> I am porting Seaside 3.1 to VisualWorks. I have come across something that I
> am not sure is the intended use of configuration options.
>
> The default ‘trackingStrategy’ configuration is set in
> WAApplicationConfiguration and WARegistryConfiguration, in their respective
> #describeOn: methods. In both, the default is set as
> ‘WAQueryFieldHandlerTrackingStrategy new’, inserting an instance of it
> (rather than the class itself) in the #trackingStrategy configuration
> parameter. However, in WAApplicationConfiguration, the list of valid options
> (self trackingStrategyClasses) returns a list of classes (not instances).
>
> This has two implications:
>
> 1) when I try to configure an application in VW (e.g.,
> http://localhost:7777/tests/functional), I get an unhandled exception
> ‘WAQueryFieldHandlerTrackingStrategy doesNotUnderstand: #name’ in
> WAClassListAttribute >> #stringForValue: method. The argument in
> #stringForValue: suggests aClass should be passed in, but it’s an instance
> instead.
>
> 2) when I try to do the same in Pharo, I’ll see ‘a
> WAQueryFieldHandlerTrackingStrategy’ as the value next to the 'Tracking
> Strategy’ label, telling me it’s an instance that is set in the
> configuration. However, when I click the ‘Override’ button next to it, the
> value will be set to a class. In Pharo, you don’t see a problem because of
> the default Object >> #name implementation that returns ‘self printString’,
> and so the method #stringForValue: doesn’t complain even though it receives
> the wrong kind of object.
>
> Remedy:
>
> I got around the problem by changing both WAApplicationConfiguration and
> WARegistryConfiguration to use the class, rather than instance, and by
> changing the WARegistry >> #trackingStrategy method to:
>
>   ^ (self configuration at: #trackingStrategy) new
>
> This fixed my problem, but it might not be in line with the intentions of
> the designer. Seeing that most of the tracking strategy classes (i.e.,
> subclasses of WAHandlerTrackingStrategy) do not use any instance variables,
> I see no problem with this change.