[Seaside] comanche modules design

[Avi Bryant]

On Mon, 14 Apr 2003, Stephen Pair wrote:

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

Fair enough.  What about a Context object, then?  Rather than pass
separate request/session/user along, and rather than have a set of
implicit, dynamic bindings, pass an explicit context instead - it can be,
for example, request + response + dictionary of other bindings.

You can implement a default handler maybe like:

processHttpContext: aContext
  aContext response: (self processHttpRequest: aContext request)