WAClassListAttribute >> #stringForValue: send for tracking strategies and tracking strategy classes

[GoogleCodeExporter]

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.

Original issue reported on code.google.com by philippe...@gmail.com on 26 Oct 2014 at 11:40

[GoogleCodeExporter]

Name: Seaside-Core-pmm.832
Author: pmm
Time: 26 October 2014, 12:43:11 pm
UUID: 47ccc12f-b490-4e72-bccd-902979d107cc
Ancestors: Seaside-Core-pmm.818

Issue 835:  WAClassListAttribute >> #stringForValue: send for tracking 
strategies and tracking strategy classes
- https://code.google.com/p/seaside/issues/detail?id=835

Name: Seaside-Tools-Web-pmm.122
Author: pmm
Time: 26 October 2014, 12:43:43 pm
UUID: b3cf7805-aa0e-42c5-8b81-7426ebf1c35c
Ancestors: Seaside-Tools-Web-pmm.121

Issue 835:  WAClassListAttribute >> #stringForValue: send for tracking 
strategies and tracking strategy classes
- https://code.google.com/p/seaside/issues/detail?id=835

Original comment by philippe...@gmail.com on 26 Oct 2014 at 11:44

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

I noticed this was only committed in the 3.1 repo. 
Shouldn't this also be included in the 3.2 repo?

Original comment by jo...@yesplan.be on 26 Dec 2014 at 3:16

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

Yes it should be. I was just waiting for a verification.

Original comment by philippe...@gmail.com on 27 Dec 2014 at 10:25

• Added labels: ****
• Removed labels: ****

[marschall]

Fix has been confirmed to work in VW

Name: Seaside-Core-pmm.873
Author: pmm
Time: 22 August 2016, 2:37:01.185838 pm
UUID: 06cea1b1-ebdd-44b1-b39e-e2ed3c41748d
Ancestors: Seaside-Core-pmm.872, Seaside-Core-pmm.832

WAClassListAttribute >> #stringForValue: send for tracking strategies and tracking strategy classes #835

• merge from 3.1