[Seaside] comanche modules design

[Stephen Pair]

Avi Bryant wrote:

>On Mon, 14 Apr 2003, Stephen Pair wrote:
>
>  
>
>>My tendency here is to make the request avaialable as a dynamic binding
>>(through 'HttpRequest binding'), do lazy initialization of 'HttpResponse
>>binding', and keep the current protocol of #processHttpRequest: (where
>>the returned HttpResponse is what gets sent to the client).
>>
>>Any thoughts?
>>    
>>
>
>I like 'HttpSession current' better than 'HttpSession binding' - it
>specifies what the method does, not how it's implemented.
>
>But I don't actually see what's wrong with #processHttpRequest:session:.
>Just have a default implementation that looks like
>
>processHttpRequest: aRequest session: aSession
>  ^ self processHttpRequest: aRequest
>  
>

What about the following case? ...I plug a Session module into the base 
ComancheHttpService.  Then I put a ChieftainModule behind the Session 
module and it's going to want to dispatch #processHttpRequest: not 
#processHttpRequest:session:...at which point, you've lost the session 
info and any modules you plug in behind the Chieftain can't access the 
session info.  The problem is compounded when you consider that you will 
likely want some type of module that resolves a user based on the 
session.  Extending this pattern, you'd then need to add 
#processHttpRequest:session:user: and #processHttpRequest:user: to all 
Modules.

I find it acceptable that certain modules can only work in the presence 
of others (such as a user resolver requiring a session resolver), but I 
don't think I like the restriction that a Chieftain cannot sit behind a 
Session resolver.

- Stephen