[Seaside] comanche modules design
Avi Bryant
avi at beta4.com
Mon Apr 14 15:10:50 CEST 2003
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)
More information about the Seaside
mailing list