[Seaside-dev] Configuring Tracking Strategy

[Philippe Marschall]

On Wed, Oct 22, 2014 at 10:54 PM, Jerry Kott <jkott at cincom.com> wrote:
> 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.

Sorry for not responding earlier. Thanks for reporting the issue. I
would rather not change 3.1 to store classes because:
- it's a pain in GemStone (we're working on a fix for this in 3.2)
- it's a pain to upgrade for people who are already on 3.1

A fix with less impact in my opinion would be to:
- change the suggested type (?) in WAClassListAttribute >>
#stringForValue: from aClass to anObject
- make sure WAClassListAttribute >> #stringForValue: is not sent with classes
- change WAUserConfigurationEditorVisitor >> #visitClassListAttribute:
to uphold the above contract

I committed Seaside-Core-pmm.832 and Seaside-Tools-Web-pmm.122 into
the 3.1 repository. Can you check if they fix the issue for you?

Cheers
Philippe