[Gd-hackers] Koala update

[Carl Gay]

On Feb 7, 2008 2:16 PM, Bastian M?üller <turbo24prg at web.de> wrote:
> Hannes Mehnert wrote:
> > Bastian M?üller wrote:
> >>> (4) Create some macros that keep the URL <=> responder mappings
> >>>      at a central place.
> >> New proposal:
> >
> >> define responders
> >>    "/foo/"
> >>       (argument-regex1) => foo-argument-responder1,
> >>       (argument-regex1) => begin
> >>         foo-argument-method1;
> >>         foo-argument-method2;
> >>       end;
> >>    "/baz" () => baz-responder;       // without argument-regex
> >>    "/blub" => blub-responder;        // normal page-responder
> >>    ...
w> >
> >> As there are still no comments, I'd like to encourge anyone who's
> >> working on/with koala to to post his wishes and thoughts.
> >
> > I like the system Allegro Webactions
> > [http://opensource.franz.com/aserve/aserve-dist/webactions/doc/webactions.html]
> > has:
> >  (("main" "main.clp")
> >   ("signin" action-sign-in)
> >   ("choice"   action-check-login "choice.clp")
> >   ("vote"     action-check-login action-vote)
> >   ("thanks"   action-check-login "thanks.clp")))
> >
> > The left hand side are URLs, the right hand side are the actions. There
> > are two different actions available: a function call (like
> > action-check-login) or a website ("thanks.clp", for dynamic content,
> > like dsp). Actions are executed sequentially, stopping if an action
> > returned false.
>
>  > It is quite common that some parts are only accessible after a
>  > successful authentication, that's why I would like to have the
>  > possibility to express this directly in the map. So, my current
>  > proposal for the macro would be:
>
> I understand what you mean and that's a good feature we should have, but
>   the suggested "chain"-approach isn't perfect. What happens if an
> action returns false? The action chain stops and then the user gets a
> blank page. Maybe replacing the action sequence with normal control flow
> statements is a better solution,

I really don't like putting control flow in the url-map.  I think the
whole point of a centralized url mapping is to provide clarity to the
overall design of the application rather than having it spread
throughout the code, and adding code into the map will have a similar
negative affect.  It will quickly balloon into something unreadable.

What about specifying (in the url-map) a default error page for the
entire application and optional error pages for each url prefix?  For
example:

define url-map
  default-error-responder = my-error-responder;
  "/poll/edit" =>
    post => get;   // prevent having to repeat responders when post
                   // and get take the same action.  make this the
                   // default?  Consider allowing "* => get;"?
    get => check-login, edit-poll;   // Note no begin/end.
    error <error> => edit-poll-error-page;
    error <other-error> => other-error-page;
  "/poll/delete" =>
    ...
end url-map;

> > define url-map
> >   "/foo" ("\w/\w/\w") => bind-arguments; "foo.dsp",
> >        ("") => "foo.dsp";
> >   "/bar" ("\d/\d/\w") => authenticated-user?; bind-arguments; "bar.dsp";
> >   "/foobar" () => admin-user?; foobar-responder;
> >   "/barfoo" () => "barfoo.dsp";
> > end;
>
> "/foobar" () => if (admin-user?) foo-bar-responder else
> not-authenticated-responder end;
>
> On the implementation side I thought about the two cases that way:
> For normal actions, like '=> foobar-responder;' we just that method as
> the responder's function. If there's a block on the right-hand side, eg.
> '=> if (admin-user?) foo-b..', it gets wrapped into a method, stored as
> the responder function and applied if it gets called, returning the
> right responder that is finally called.
>
> I'd like to call the macro "define responders", that's more obvious to
> me, because you define responders. But I don't care ... the name isn't
> that important.

Well, it's defining the url->responder mapping, not the actual
responders.

> Another problem that came to my mind (again ...) while looking at the
> blog and wiki sources:
>
>     select (request.request-method)
>           #"get" => case
>           ...
>           #"post" => respond-to(...

They used to define respond-to-get/post methods, not use select,
right?  I thought now they use "define respond-to (meth == #"get", ...)"
now?  (I haven't gone to look at the source to see what you're referring
to.)

> You want to do different things depending on the request method.
> All the responders are full of these. Maybe we should incorporate that?
>
> define responders
>     "/pages"
>        get => list-pages;
>        get ("^(?P<name>\w+)$") =>

something missing here?

>        post => create-page;
>        post ("^(?P<name>\w+)$") => if (user-can-edit?)
>            save-page
>          else
>            not-authenticated-error
>          end if;
>        delete ("^(?P<name>\w+)$") => if (user-can-remove?)
>                     // for web-services
>     ...
> end;
>
> IMHO it's handy and summarizes the web-application structure very well.

I agree, with the exception I noted above.  I would rather not see
control flow code in the url map.

-Carl