Configuring Tracking Strategy

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Configuring Tracking Strategy

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


Jerry Kott
Smalltalk Development, Cincom Systems
PGP fingerprint: 07D0987E142BE7D39A3F99D71DAF1CF392A9236F


_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev

signature.asc (507 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Configuring Tracking Strategy

Philippe Marschall
On Wed, Oct 22, 2014 at 10:54 PM, Jerry Kott <[hidden email]> 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
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev