[Seaside] [FIX] SeasideServiceSyncToSeaside2.3
Stephen Pair
stephen at pairhome.net
Tue Apr 8 17:00:40 CEST 2003
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
More information about the Seaside
mailing list