Re: [Openinteract-dev] About the Action class

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

Chris Winters wrote:
> So if you're creating actions in by themselves without a request  
> available it should just do the right thing. Are you not seeing this?

Yes this was one of the things i noticed when I really started working 
on what I was doing. Even in the actionresolver worked without a 
request, which was nice :)

Anyway I had to do some tweaks of my own to get things working, since I 
had to make the same action to work while using a normal request, while 
being called from an another request with the user privileges and also 
while being called without a given request or a user at all, skipping 
all securities.

The problem was that I needed values that were normally acquired using 
CTX but couldn't use CTX, since it had the state my initial action used 
and I needed a different state to run my action correctly. In the end I 
just added some extra accessors to my base Action class and set all the 
needed values there already in the actionresolver so it didn't have to 
call CTX (for other than lookups) at all when executed.

Ideally (for my use) actionresolver would, in addition to what it does 
now, determine the _actual_ task, store additional url parameters to the 
action instead of the request and assign these parameters to accessors 
based on url_additional config. It could possibly even copy the request 
parameters to the action if request exists (I didn't need this myself 
this time). I personally store also the current language to the action 
and use that language for _msg calls, but I'm not sure if this is a 
common need.

Maybe a good approach, at least for request params, would be to allow 
assigning this data to action's accessors and if they are not set, then 
try to fetch them from the request? Anyway all this data should be 
accessible from actions methods.

I'm really not sure how vital this separation would be in the common 
use, but it might also make the structure easier to understand if 
actions were more self contained.. maybe ;)

By the way, assigning url_additional automatically according to 
configuration is a brilliant idea in many ways :) I just started to 
think of it more and concluded that if the task could be determined 
before execute then we could assign url_additional before execute, we 
possibly wouldn't need the additional url parameters in action anymore, 
thus separating us from the request.. nice :)

>> Also after this, could it be possible to find out the task and  
>> additional parameters before execute?
>
> This is a good idea, although we'll have to add a couple more  
> properties so that we don't recheck the task validity and reassign  
> params. (Not a big deal.). Did you create a JIRA task for this?

Well I was not, and still am not sure of the actual things that should 
be done ;) So I prefer discussing them instead of creating misinformed 
and stupid JIRA issues ;)

- Antti