[Gd-hackers] Koala update

[Bastian M?üller]

Carl Gay wrote:

Hej,

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

That's a nice solution to the error-problem. With the error-slots we 
don't need the control-flow anymore and can use hannes' proposal. The 
only thing that came in my mind was control-flow, but that's even better.


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

respond-to is used for pages. But until now you'll have to do what the 
macro above does in the "define directory responder" with a lot of 
boilerplate code like that. We won't need it anymore.

>> 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?
Yeah, there was a "get-page;" or something like that missing.

Thanks for your ideas.

kind regards,
   Bastian