Action Methods vs. Public Methods in PHP Frameworks

There are many PHP frameworks that many of you know, and I'm interested in your thoughts on this: Zend Framework has so-called action controllers, which must contain at least one action method, a method whose name ends in Action. For instance:

public function indexAction() {}

      

The word "Action" is important, without it you cannot directly access this method via a URI. However, in some other frameworks like Kohana, you have public and private methods where the public methods are available and the private ones are not. So my question is what do you think is the best approach? From a reliable point of view, I would vote Zend's approach, but I'm curious to see what others think.

+2


a source to share


5 answers


Based on preference, I am good at approaching zend framework. It has proper controller encapsulation. Yes, you have to add a word action and create a script view (optional) to access it via a URL. However, you can use private, protected, and public functions in the controller for additional logic.



+1


a source


This preference is valid. Using some kind of naming convention is more versatile (and in fact, that's what Kohana 3 is doing right now) as it allows for public methods that are not actions that might be useful.



Of course, the ideal solution is to use some kind of code metadata like .NET attributes or Java annotations , but unfortunately this feature doesn't exist in PHP.

+1


a source


It has less to do with safety than the design of the ZF. As you said, methods are not available when called through a URL, but this is solely due to the way Zend Framework processes handle requests.

Quoting reference guide :

The workflow is Zend_Controller

relatively straightforward. The request is received Zend_Controller_Front

, which in turn calls Zend_Controller_Router_Rewrite

to determine which controller (and the action in that controller) to dispatch.

Zend_Controller_Router_Rewrite

decomposes the URI to set the name of the controller and action in the request. Zend_Controller_Front

then enters the dispatch loop. It calls Zend_Controller_Dispatcher_Standard

, passing it a request, to dispatch to the dispatcher and the action specified in the request (or use the default values).

Method names are formatted in Zend_Controller_Dispatcher_Abstract

:

/**
 * Formats a string into an action name.  This is used to take a raw
 * action name, such as one that would be stored inside a Zend_Controller_Request_Abstract
 * object, and reformat into a proper method name that would be found
 * inside a class extending Zend_Controller_Action.
 *
 * @param string $unformatted
 * @return string
 */
public function formatActionName($unformatted)
{
    $formatted = $this->_formatName($unformatted, true);
    return strtolower(substr($formatted, 0, 1)) . substr($formatted, 1) . 'Action';
}

      

The action suffix is ​​hardcoded so the dispatcher will always look for the action method no matter what. So when you request /user/show/

, you are calling UserController::showAction()

because of how the request is handled. This is not a safety feature, though, or a replacement for visibility. Make it showAction()

secure and you no longer have access to it via the url. And, technically, you could pretty much call non-action methods from a URI if you don't run them through normal configuration. You can create your own Dispatcher and change how ZF action name formats are easy.

The nice thing about Action Suffix is ​​that it makes action methods clearly distinguishable from other methods in the controller.

+1


a source


Zend has this because in PHP 4 you didn't have private / public access, so they had to rely on naming conventions. It's more secure for both public / private and naming.

0


a source


I would say this is a personal preference. there are many variations here, for example the codeigniter version is that any method name that starts with _ is private and anything else is a controller method.

personally speaking, I would say that anything using the built-in language controls (e.g. public function

vs private function

) would be the most intuitive.

edit: as frank says, the MOST SECURE method will use as many functions as possible (for example, private

as well as the method name).

0


a source







All Articles