PHP standardization Fig Namespaces

Asked

Viewed 118 times

0

I have a PHP application with my mvc framework and follow the following template:

Namespace         Diretorio                              Desc
Nautilus\         root/Nautilus/src/Nautilus_Web/        Aplicação principal
Nautilus\Service  root/Nautilus/src/Nautilus_Service/    Serviços
Nautilus\Domain   root/Nautilus/src/Nautilus_Domain/     Modelos e repositórios

I am standardizing my project according to PHP-Fig and as the documentation the namespace should correspond to the physical directory.

I wonder if the standardization is being done the wrong way since the Nautilus Service and Nautilus Domain should include the classes from the directory of the Nautilus namespace that would be:

root/Nautilus/src/Nautilus_web/....

If my namespace calls Nautilus the physical directory should be:

root/Nautilus/src/Nautilus_Web/Nautilus no? or else rename the namespace to Nautilus\Web then the directory .../src/Nautilus_web would correspond, correct?

Thank you!

  • What standard are you implemented, psr-4 or psr-0 ?

  • I am implementing all PSR-0 to PSR-4!

  • psr-4 overrides psr-0, so why you implement both?

  • The PSR-4 does not overlay everything but redefines some specifications!

  • @gmsantos You’re right, in the PS4 description it says that is an improvement in definitions but reset everything without exception!

  • reset everything without exception? Wrong. na psr-0, _ are converted to directories, which does not happen in psr-4 for example: http://www.php-fig.org/psr/psr-0/

  • On PSR0 _ was converted into directories, as you said, on PSR4 _ is treated as part of the namespace so the attribution given to _ has been reset. Thanks for the help!

Show 2 more comments

1 answer

2


I believe I’m seeing three questions so I’ll answer them in the order that makes the most sense: Directory structure, namespaces and content.

Like every framework or component/library, whether proprietary or 3rd-Party is custom, independent of PSR, from the root directory if you have a subdirectory normally called vendor and, within it, a directory for each resource:

|-\
| |-\Application
|   |-\Application\Portal
|      |-\Application\Portal\Models
|      |-\Application\Portal\Views
|      |-\Application\Portal\Controllers
|   |-\Application\Portal
|      |-\Application\Admin\Models
|      |-\Application\Admin\Views
|      |-\Application\Admin\Controllers
| |-\vendor
|   |-\vendor\Symfony
|   |-\vendor\Doctrine
|   |-\vendor\Nautilus

Frameworks namespaces or libraries/components escape the rule of being started from the root directory mainly because of autoloaders which almost always take into account the include_path who must be modified at runtime to include, among what you need, this directory vendor:

set_include_path(
    '.' . PATH_SEPARATOR . realpath( './vendor' )
);

Finally, the location of the content. Once you solve the two problems above, you solve the latter also because all autoloader should work from the root directory and as the vendor is already part of the include_path every time you instantiate a new class or import a resource (with use), as long as this has not yet been declared in the scope of the summoner (otherwise there is no autoloader intervention) you will always be "positioned" in the Rai of the Application.

That is, imagine that Nautilus\Web\Domain needs some resource of Nautilus\Web\Service. Even though abos stretch in completely separate directories, both will be under the wings of the same parent namespace, Nautilus

Ah! And by the way, except for the modification of include_path, forget the concept of relative paths. ;)

Browser other questions tagged

You are not signed in. Login or sign up in order to post.