[Seaside-dev] Can WAServerAdaptor be split up?

[Julian Fitzell]

Hi Norbert,

Sounds like a reasonable argument... so you'd have a RequestAdaptor and a
ServerAdaptor or something?

Two thoughts:
1) It might make sense to do this on the 3.1 branch as it's sort of an
architectural change, though I guess it can be done backwards-compatibly,
so maybe not necessary. (actually, we'll need to look at pulling new
changes from 3.0 over to 3.1—there's not much in there yet, but it would be
nice to get the continuation-as-request-handler stuff soonish)
2) I've been experimenting in that branch (but haven't committed yet) with
making ServerAdaptor a subclass of RequestHandler. This works really nicely
because it can sit in the handler stack and represent the root of the path:
it can provide the default codec, the base URL of the server, allows
wrapping with decorations, and so on. One question I've had is whether
there should be a composition rather than subclass relationship here; maybe
the RequestAdaptor is the thing that should be a RequestHandler and the
ServerAdaptor should be responsible for setting the codec and URL properly
on the RequestAdaptor.

Don't worry about making the RequestHandler change unless you're interested
(in fact, probably better to do the refactoring in a separate step anyway),
but worth keeping that in mind as you're doing the split.

Julian

On Sun, Jan 6, 2013 at 11:48 AM, Norbert Hartl <norbert at hartl.name> wrote:

> 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_______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20130107/efffec7b/attachment.htm