Jet\MVC_Controller_Router_Action

After we have introduced the Jet\MVC_Controller_Router class, it remains to describe the Jet\MVC_Controller_Router_Action class, which represents a defined microrouter action and its rules.

Overview of methods

Method	Meaning of
public __construct( MVC_Controller_Router $router, string $controller_action, string $module_action )	You will never call the controller separately, because the action instance is created by the microrouter when calling its addAction method. Therefore, the meanings of the parameters of the constructor are the same as the parameters of the mentioned method.
public setResolver( callable $resolver ): static	As we have already shown in the previous chapters, this is a very important method that defines the logic that decides the relevance of the action in the form of a callback (usually an anonymous function). Callback has no parameters, but it should return bool.
public resolve( ): bool\|string	The method decides whether the action is relevant. In practice, you won't use it yourself because it is called by the microrouter.
public setURICreator( callable $URI_creator ): static	The URL generation function has been mentioned only marginally so far, so let's take a closer look at it here. As mentioned earlier, the microrouter can also be used to generate URLs for individual actions. Let's show it right away with a concrete example. We have a view and in the view we need the address of an action for editing some entity that the module should manage (for example, an article, an item in an e-shop, etc.). View script is not supposed to solve logic. The View script does not know what this address should look like and it should not deal with how to handle permissions and permission to perform the action. The View script is only interested in getting or not getting the address and then generating/not generating the appropriate button accordingly. In the view script we can do the following: `$edit_URI = $this->controller->getControllerRouter()->action('edit')->URI( $id );` View gets what it needs, but you have the control logic where it should be - in the controller. By the way... Now you can see why the view keeps the controller instance and the controller keeps its microrouter instance. It's not an end in itself. It is related and has a logic behind it. Now we move from view back to controller. Of course, the microrouter and its actions can't just read the URL from the stars. This is logical. Therefore, when defining the microrouter and its rules, a callback must be defined that creates the action address. Let's show this right away with an example:`$this->router->action('edit')->setURICreator( function( $id ) { return Http_Request::currentURI( ['id' => $id] ); } );` As you can see in the example, the address builder can (but does not have to) have parameters in the number you need.
public URI( ...$arguments ): string\|bool	See the setURICreator method.
public authorize( ): bool	Checks whether the action is available in terms of permissions. If the action is not mapped to an ACL action of the application module, then access is automatically granted. Otherwise, a permission check is performed via the authentication and authorization system. The method is used by the microrouter, but in practice you can use it wherever you need it (applications can easily check permissions using this method).
public router( ):MVC_Controller_Router	Returns the instance of the microrouter to which the action belongs.
public controller( ):MVC_Controller	Returns the controller instance to which the microrouter to which the action belongs belongs.
public getControllerAction( ): string	Returns the name of the action.
public getModuleAction( ): string	Returns the name of the application module ACL action.