[Seaside-dev] Can WAServerAdaptor be split up?
Norbert Hartl
norbert at hartl.name
Sun Jan 6 11:48:19 UTC 2013
I'm experimenting at the moment with setups to serve static files from a one click image without using file libraries. I'm trying to serve static files from within a one click distribution directory. Therefor I create a zinc server myself and I want to plug in seaside as a handler. Here is a snippet
start
"file delegate serves from a neighbor directory 'web'"
staticFileDelegate := ZnStaticFileServerDelegate new directory: (
FileDirectory default containingDirectory directoryNamed: 'web').
server := (ZnServer on: self port)
delegate: (
"the next class just maps the first path element of a uri to a handler"
NTedContextDispatcherDelegate new
map: 'css' to: staticFileDelegate;
map: 'js' to: staticFileDelegate;
defaultHandler: (ZnSeasideServerAdaptorDelegate with: ZnZincServerAdaptor new) ).
server start
Whenever I start my server there is another adaptor created on port 8080. This is due to ZnZincServerAdaptor is an instance of WAServerAdaptor and always starts a server instance with a default being port 8080.
In my opinion WAServerAdaptor has too many responsibilities. It does server management as well as request conversion. From a seaside point of view (being monolithic) this seems not to be a problem. But if seaside is _just_a_ handler it strikes back.
I would like to divide the server management code from the request conversion. The request conversion/adaptor class could also be used in zinc directly. Meaning the only difference would be if seaside is the only zinc delegate or is a composited delegate.
If it is important to keep a WAServerAdaptor as it is there could be one class having self as delegate resembling the current behavior.
Any opinions? I would do the split up but I wanted to ask first if there is anything speaking against it.
Norbert
More information about the seaside-dev
mailing list