Re: [Openinteract-dev] About the Action class

[<an...@io...>]

A new try - last versio of this mail disappeared :(

Chris Winters wrote:
> That's probably a good idea. I moved the code to assign these from  the 
> request into a separate subroutine as well, so you can do:
> 
>   # assign the additional parameters from the Request object
>   $action->url_additional_param_from_request;
>   my @values = url_additional_param;

What if all of the assigning would be done already in the actionresolver?

This way you wouldn't need to store tha url params in request at all. 
You would pass _only_ the relative url to an actionresolver and the 
actionresolver would return you an action which has task, language, 
params from additional and params from request.

Language and request params could be fetched using action's interface so 
that if they are not set for the action, they will be fetched from 
CTX->request, but if they are set, the set values would be used instead.

I think this would not only add new possibilities by making the action 
truly independent fron the request, but it would also simplify the 
execution process.


> It's not a bad idea. (That Action class just keeps growing... :-)

Well if you can move task validation and additional parameter populating 
  from execute to actionresolver, it wouldn't be a huge addition for the 
Action to add the possibility to make action run independently from the 
request but still using similiar ways to control actions behaviour.

This would make it possible to do a gateways that would make it possible 
to call normal requests but get the results in a filtered form 
(returning pages in ajax-readable form for example).

Also this would make it possible to build a public gateway so that if 
requests are called through this gateway, they would send correct HTTP 
headers so that for example squid could timecache them, but the requests 
could be called by others normally getting the latest data.

Like this:

/public/request/myaction/mytask/myadditional/

sub request {
   my ( $self ) = @_;

   my $sub_action = MyActionResolver->resolve(
     join '/', $self->param('other_additional')
   );

   # maybe set some extra params
   # maybe override language or request params
   # issue correct cache headers

   return $sub_action->execute;
}


> Creating a shortcut to fill the URL_PARAMS with default values, or to  
> be smarter to associate some additional parameters with named values  
> (like your 'area_id' above) seems application-specific, and may be  more 
> appropriate a base Action class in your app.

Well generally you are correct - if you don't know how the urls are 
parsed (since any of the actionresolvers might get it), you don't know 
how they are generated either. This is probably only for us then.

- Antti