Re: Koala update

Hannes Mehnert wrote:

Hej,

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

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

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

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+)$") =>
       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.

What I'd like to have in addition but have no idea how to implement it:
Instead of only writing

   post ("^(?P<name>\w+)$") => if (user-can-edit?) ...

it would be even a lot more helpful to write

    post ("^(?P<name>\w+)$") => if (user-can-edit?(name)) ...

where 'name' is named regex-group name.

Can I go for that or are there any improvements (regarding
functionality and/or syntax) or even objections?

kind regards,
   Bastian
--

-- 
Gd-hackers mailing list
Gd-hackers <at> gwydiondylan.org
https://www.opendylan.org/mailman/listinfo/gd-hackers