[Seaside] [FIX] SeasideServiceSyncToSeaside2.3

[Stephen Pair]

Frank Sergeant wrote:

>Stephen Pair <stephen at pairhome.net> wrote:
>  
>
>>Does this fix work with earlier versions of Seaside as well?
>>    
>>
>>>"Change Set:		SeasideServiceSyncToSeaside2.3
>>>Date:			8 April 2003
>>>Author:			Frank Sergeant
>>>
>>>This updates WAKomNG in SeasideService package to work with Seaside 2.3.
>>>Note, this probably should not be applied if you are using an earlier
>>>version of Seaside.  I copied WAKom>>process: to
>>>WAKomNG>>processHttpRequest:"!
>>>      
>>>
>
>I think it does not.  It looks like Seaside 2.3, WAKom>>request: uses
>the WARegistry instance to handle the request, i.e.
>
>	response _ WARegistry default handleRequest: request.
>
>while in Seaside 2.2, WAKom>>request: used the WAApplication class to
>handle the request, i.e.
>
>
>	response _ WAApplication handleRequest: request.
>
>I gathered you changed the name of the process message in ComancheNG to
>#processHttpRequest: rather than #process and that you were basically
>tracking Avi's WAKom>>process: with your WAKomNG>>processHttpRequest:,
>so all I did was move the method body from Avi's WAKom>>process: to your
>WAKomNG>>processHttpRequest: .
>
That's correct.  I wanted to clean up the services framework in 
Comanche.  WAKom was a good example of why this needed to be done.

>Is there a better way of keeping these in sync?
>
WAKomNG could be included as part of the Seaside release, that would 
eliminate the problem (since each release of Seaside could have it's own 
version of WAKomNG).  But, you would probably have to conditionally load 
it based on whether or not ComancheHttpService is present (since WAKomNG 
subclasses it).  Also, WAKomNG>>processHttpRequest: could simply 
delegate to a class method in Seaside somewhere.  Or, perhaps I could 
add a PluggableHttpService to ComancheNG that is instantiated with a 
block (as an inst var) that processes the incoming http requests.  
Starting Seaside might then look something like:

  PluggableHttpService
        handler: [ :komRequest | WARegistry processKomRequest: komRequest ];
        startOn: 8080

The only issue with the pluggable approach might be performance since we 
would probably need to be careful about copying the block to allow for 
concurrent evaluations.  With block closures, it wouldn't be as much of 
an issue.

I think I would lean toward moving the request handling code into 
WARegistry class>>processKomRequest: (or similar), but not going the 
Pluggable route (just have WAKomNG>>processHttpRequest: call the class 
method).

- Stephen