Я понимаю что такое пространство имён и как ими пользоваться, но есть одна проблема я ими не когда не пользовался (Один раз для ознакомления). Я пишу сайт на laravel и не могу разобраться в логике имён, может кто то подскажет как побыстрей их запомнить?
Пример для доступности класса Model надо писать use Illuminate\Database\Eloquent\Model; А как разобраться в такой записи: Код (PHP): use Illuminate\Auth\Access\AuthorizationException; use Illuminate\Database\Eloquent\ModelNotFoundException; use Symfony\Component\HttpKernel\Exception\HttpException; use Illuminate\Foundation\Validation\ValidationException; use Symfony\Component\HttpKernel\Exception\NotFoundHttpException; use Illuminate\Foundation\Exceptions\Handler as ExceptionHandler; А если самому надо будет такое составить? Это ведь как то запомнить надо? Тут ведь логика какая то должна быть? Типо use Пакет\Ещё что то\Ещё что то\Класс;
для доступности класса илюминэйт-дейтабейс-елокент-модэл как модэл в текущем пространстве имён. ну если ты про сторонние приложения то да, наверное запомнить. а если про свое - то ты как бы это сам знать должен. а вообще бояться не надо - любая уважающая себя иде умеет подстановки делать. вбил "юз модэл" а она тебе предложила все фккн-ы которые она знает для текущего проекта - походил вверх-вниз, спозиционировался на нужном классе, жмакнул энтер и получил готовую строку. ну логика-то должна быть, только у каждого автора и даже в пределах одного автора - логика может быть разная. я вот например несколько лет назад очень любил джава-стиль типа com\example\common\users\user - com\example четко указывали что речь идет о сайте example.com, коммн - что это некий общий код, который без особых юридических трудностей я могу использовать в другом проекте, юзерс - на то что это инструментарий работы с пользователями, юзер - собственно класс реализующий сущность пользователя. а потом я плавно перестал такой херней страдать и начал страдать другой
Да я уже заметил. В laravel к примеру всё просто (Почти), пространства имён делаются по названиям файлов use app\UserModel; само говорит что у меня есть файл app\UserModel.php ну или папка use app\Http\Requests; Только есть одно но laravel использует сторонние пакеты и use Validator; use Illuminate\Http\Request; Хрен разберёшься, надо как то вникать (Учить долго и литературы нет) У меня PHPStorm, тыкать долго по меню я из других файлов вырезаю, может потом запомню.
какая-то надуманная проблема тоже надуманная. пока ты набиваешь "юз короткое-имя-класса-или-пакета" - иде уже должна предлагать тебе полное квалифицированное имя. в меню не надо лазить. можно просто пару раз пробежаться по списку файлов и примерно знать какие пакеты и классы есть в текущей инсталляции. а дальше по контексту их пробовать применять. в общем я сложностей особых не вижу.
Я об этих пакетах почти не чего не знаю. Я неделю назад установил composer и laravel дня 3 назад, даже поговорка на эту тему есть "Смотришь в книгу, видешь фигу." Хотя со временем разберусь.
До появления PHP 5.3 разработчики были вынуждены подбирать для файлов и классов своего проекта уникальные имена, поскольку с точки зрения интерпретатора все они находились в одном глобальном контексте. Другими словами, если вы, например, определяли класс ShoppingBasket, он тот час же становился доступным всему вашему приложению. Это порождало две большие проблемы. Первая и самая неприятная проблема была связана с потенциальным конфликтом имен в проекте. Посмотрим, что произойдет, если использовать в своем проекте такую конструкцию. Код (PHP): //my.php require_once "useful/Outputter1.php" class Outputter{ //output data } а во включаемом файле было такое? Код (PHP): //useful/Outputter1.php require_once "useful/Outputter1.php" class Outputter{ // } Это приведет к фатальной ошибке. Существовал, традиционный обходный маневр. Нужно было указать имя пакета перед именем класса, чтобы в итоге получились уникальные имена классов. Код (PHP): //my.php require_once "useful/Outputter1.php" class my_Outputter{ //output data } //useful/Outputter1.php require_once "useful/Outputter1.php" class useful_Outputter{ // } Но, с выходом PHP 5.3 появились спасительные пространства имен. Пространство имен -это корзина, в которую вы можете поместить классы, функции и переменные. В пределах одного простантсва имен вы можете обращаться к ним без всякого уточнения. Чтобы обратиться к этим элементам за пределами пространства имен, вам прдется либо импортировать(см. "USE ") в код целое пространство имен, либо использовать ссылку на него. Пример: Код (PHP): namespace my; require_once "useful/Outputter1.php" class Outputter{ //output data } namespace useful; require_once "useful/Outputter1.php" class Outputter{ // } Так же можно использовать файловую систему для имитации пакетов (Пакеты — это механизм, который служит как для работы с пространством имен, так и для ограничения видимости.). http://php.net/manual/ru/language.namespaces.importing "PHP объекты, шаблоны и методики программирования" (последнее издание лучше найти). В этой книге подробно все расписано что касается пакетов и пространства имен. стр. 102
Так есть же стандарт наименования пространств имён, которому следует и Laravel. PSR-0, PSR-1, PSR-2, PSR-3, PSR-4
ну ты же понимаешь что это не стандарт а "стандарт"? это кто-то предложил. как политика рфц - рфц тоже не являются стандартами на самом деле. был бы в пхп стандарт - его бы описали на родительском сайте. а это лишь одна из вариаций стандартизации кода. хошь бери, не хошь - не бери
Ganzal, понимаю. Но точно знаю, что в Laravel и Symfony ему следуют. Хоть и знаком с Laravel поверхностно, да и с Symfony только по компонентам, которые в других фреймворках используются
ну я-то не о том кто его придерживается а о том что это очень громко называть именно стандартом. кстати у оригинального пхп несколько лет назад были требования к стандартизации (ну для попадания в пир и пецл) и у зенда - и они были отличны друг от друга. и пср тоже от них отличаются. будто бы назло.
О_о Стандарт? Был бы стандарт, было бы всё просто а я уже 3 час не могу понять откуда берётся "стандартный" trait ResetsPasswords, что бы узнать методы для сброса пароля ("Стандартные"). Код (PHP): // app/Http/Controllers/Auth/PasswordController.php use Illuminate\Foundation\Auth\ResetsPasswords; class PasswordController extends Controller { use ResetsPasswords; Я уже всю папку Illuminate\Auth перелазил, а трейта не вижу. Добавлено спустя 2 минуты 57 секунд: Так в чем заключается стандарт? Я логики пока не вижу что то называется по директории или файлу, а что то так от фонаря.
все пиэсары регулируют только то как код должен быть оформлен в рамках этих пиэсаров. мне вот например игоряша голову проел моей привычкой ставить фигурную скобку на следующей строке. а пиэсар - это ТРЕБУЕТ. и вертеть теперь игроряшу на болте можно
Меня как то тоже раздражала скобка на следующей строке, меня PHPStorm отучил (Сам переносы ставит, и 2пробела вместо табуляции). Какой то сомнительный стандарт. А тема вообще изначально была про пространства имён, так вот они где нибудь стандартизированы? Возьми да и напиши вот такую фигню: Код (PHP): namespace Xernia\Bl\Blabla\Trah; Я подозреваю что строка выше соответствует стандарту, а вот потом сиди и думай что этой строкой хотел сказать автор.
нет никакого стандарта. автор пакета мог придумать разложить нсы так чтоб можно было пакет юзать в других приложениях без особых трудностей - перенес кусок и радуйся. а мог и не предусмотреть - тащи всю сиэмэску. про скобку на следующей строке - ты пользуешься фолдингом?
Я в бил "фолдинг php". А это оказываться +\- кнопки слева)) Да я иногда этим пользуюсь, когда методов много или длинные, что бы листать потом быстрее можно было, это удобно когда у тебя класс в 500-1000 строк.
Нашёл за 5 минут. Он там, где и должен быть. Просто почитайте про стандарты. https://github.com/laravel/framework/blob/5.2/src/Illuminat ... swords.php Это гитхаб фреймворка, при установке скорее всего развернётся в папку vendor по традиции. А дальше, Illuminate/Foundation/Auth - каждому уровню в неймспейсе соответствует папка, как описано в стандарте. Добавлено спустя 6 минут 44 секунды: Laravel следуют PSR-ам, это видно по исходнику. Иначе я бы так быстро не нашёл. Плюс ещё прочитайте про composer, в папке composer указано, откуда какие классы грузятся. Под рукой проекта на Laravel нету, но могу привести аналогичный файл из проекта на yii2, который тоже ставится composer-ом (находится в vendor/composer/autoload_psr4.php) Код (PHP): // autoload_psr4.php @generated by Composer $vendorDir = dirname(dirname(__FILE__)); $baseDir = dirname($vendorDir); return array( 'yii\\swiftmailer\\' => array($vendorDir . '/yiisoft/yii2-swiftmailer'), 'yii\\jui\\' => array($vendorDir . '/yiisoft/yii2-jui'), 'yii\\imagine\\' => array($vendorDir . '/yiisoft/yii2-imagine'), 'yii\\gii\\' => array($vendorDir . '/yiisoft/yii2-gii'), 'yii\\faker\\' => array($vendorDir . '/yiisoft/yii2-faker'), 'yii\\debug\\' => array($vendorDir . '/yiisoft/yii2-debug'), 'yii\\composer\\' => array($vendorDir . '/yiisoft/yii2-composer'), 'yii\\codeception\\' => array($vendorDir . '/yiisoft/yii2-codeception'), 'yii\\bootstrap\\' => array($vendorDir . '/yiisoft/yii2-bootstrap'), 'yii\\' => array($vendorDir . '/yiisoft/yii2'), // И так далее ) И вот composer.json самого laravel, который показывает, на основе каких данных composer должен генерировать код, подобный приведённому выше https://github.com/laravel/framework/blob/5.2/composer.json#L82 Добавлено спустя 2 минуты 40 секунд: PSR-ам можно и не следовать, да. Это не стандарт от авторов php, это скорее соглашение разработчиков, как написал Ganzal. Но самые крупные фреймворки их придерживаются. И в том числе благодаря им можно совмещать разные компоненты из разных фреймворков. Добавлено спустя 4 минуты 10 секунд: http://www.php-fig.org/psr/psr-0/ru/#Обязательно http://www.php-fig.org/psr/psr-4/ru/ Это раз вы сами не гуглите.
Это понятно. Я вам привёл composer.json фреймворка, на основе которого потом при загрузке composer формирует пути для автозагрузчика. Но я вам и не предлагаю ваш composer.json смотреть. Я предлагаю посмотреть ваш vendor/composer/autoload_psr4.php, Добавлено спустя 59 секунд: Вы же видите, я за 3 минуты нашёл нужный вам трейт, просто зная, что фреймворк написан по PSR-4, но не зная самого фреймворка
Мой vendor/composer/autoload_psr4.php: Код (PHP): <?php // autoload_psr4.php @generated by Composer $vendorDir = dirname(dirname(__FILE__)); $baseDir = dirname($vendorDir); return array( 'XdgBaseDir\\' => array($vendorDir . '/dnoegel/php-xdg-base-dir/src'), // Что это? 'Symfony\\Polyfill\\Util\\' => array($vendorDir . '/symfony/polyfill-util'), 'Symfony\\Polyfill\\Php56\\' => array($vendorDir . '/symfony/polyfill-php56'), 'Symfony\\Polyfill\\Mbstring\\' => array($vendorDir . '/symfony/polyfill-mbstring'), 'Symfony\\Component\\Yaml\\' => array($vendorDir . '/symfony/yaml'), 'Symfony\\Component\\VarDumper\\' => array($vendorDir . '/symfony/var-dumper'), 'Symfony\\Component\\Translation\\' => array($vendorDir . '/symfony/translation'), 'Symfony\\Component\\Routing\\' => array($vendorDir . '/symfony/routing'), 'Symfony\\Component\\Process\\' => array($vendorDir . '/symfony/process'), 'Symfony\\Component\\HttpKernel\\' => array($vendorDir . '/symfony/http-kernel'), 'Symfony\\Component\\HttpFoundation\\' => array($vendorDir . '/symfony/http-foundation'), 'Symfony\\Component\\Finder\\' => array($vendorDir . '/symfony/finder'), 'Symfony\\Component\\EventDispatcher\\' => array($vendorDir . '/symfony/event-dispatcher'), 'Symfony\\Component\\DomCrawler\\' => array($vendorDir . '/symfony/dom-crawler'), 'Symfony\\Component\\Debug\\' => array($vendorDir . '/symfony/debug'), 'Symfony\\Component\\CssSelector\\' => array($vendorDir . '/symfony/css-selector'), 'Symfony\\Component\\Console\\' => array($vendorDir . '/symfony/console'), 'SuperClosure\\' => array($vendorDir . '/jeremeamia/SuperClosure/src'), 'Psy\\' => array($vendorDir . '/psy/psysh/src/Psy'), 'Psr\\Http\\Message\\' => array($vendorDir . '/psr/http-message/src'), 'PhpParser\\' => array($vendorDir . '/nikic/php-parser/lib/PhpParser'), 'Monolog\\' => array($vendorDir . '/monolog/monolog/src/Monolog'), 'Mews\\Captcha\\' => array($vendorDir . '/mews/captcha/src'), 'League\\Flysystem\\' => array($vendorDir . '/league/flysystem/src'), 'Kaishiyoku\\' => array($vendorDir . '/kaishiyoku/laravel-menu/src/Kaishiyoku'), 'Intervention\\Image\\' => array($vendorDir . '/intervention/image/src/Intervention/Image'), 'Illuminate\\' => array($vendorDir . '/laravel/framework/src/Illuminate'), // ????????? 'GuzzleHttp\\Psr7\\' => array($vendorDir . '/guzzlehttp/psr7/src'), 'Faker\\' => array($vendorDir . '/fzaninotto/faker/src/Faker'), 'Dotenv\\' => array($vendorDir . '/vlucas/phpdotenv/src'), 'Doctrine\\Instantiator\\' => array($vendorDir . '/doctrine/instantiator/src/Doctrine/Instantiator'), // ????????? 'Collective\\Html\\' => array($vendorDir . '/laravelcollective/html/src'), 'ClassPreloader\\' => array($vendorDir . '/classpreloader/classpreloader/src'), 'Carbon\\' => array($vendorDir . '/nesbot/carbon/src/Carbon'), // ????????? 'App\\' => array($baseDir . '/app'), // Тут понятно всё. ); Нет по сути не какого стандарта \<Имя производителя>\(<Пространство имён>\)*<Имя класса> composer требует такой записи и по другому autoload не заработает, так как имя строется из 3 файлов. Ну а в остальном я могу писать любую херню и composer вместе с laravel это захавают. А может я как то не так думаю? Там выше в коде комменты, дайте пояснения (Что то там не чисто).
Ну всё же и так понятно. Стандарт - он в наименовании пространства имён. А здесь, как видите, задаётся соответствие "корневого", скажем так, пространства имён и папки на диске где это всё расположено. К примеру, Код (Text): 'Illuminate\\' => array($vendorDir . '/laravel/framework/src/Illuminate') все классы пространства имён Illuminate и его подпространств лежат в vendor/laravel/framework/src/Illuminate. Посему, если полное имя класса Illuminate\Ochen\Vajnaya\Fignya, то, в соответствии со стандартом, этот класс нужно искать в фале vendor/laravel/framework/src/Illuminat/Ochen/Vajnaya/Fignya.php. То же самое касается трейтов и интерфейсов. Соответственно, класс Carbon\Ochen\Vajnaya\Fignya будет в vendor/nesbot/carbon/src/Carbon/Ochen/Vajnaya/Fignya.php, а если вы свой класс захотите создать, App\Ochen\Vajnaya\Fignya, вы его должны положить в папочку app/Ochen/Vajnaya/Fignya.php. Самостоятельно менять этот файл не следует, если вам недостаточно пространства App для ваших классов, новое вы должны задать через свой composer.json. Иначе все ваши добавления/изменения в этом файле будут перезаписываться при каждом composer update. Добавлено спустя 42 секунды: Вообще, в папке vendor ничего менять нельзя. Да, и что в названии папок я опустил пути до папки с сайтом, это, я надеюсь, и так понятно. Так же почитайте доки по composer, в частности https://getcomposer.org/doc/04-schema.md#autoload Добавлено спустя 5 минут 21 секунду: Т.е. ещё раз. Для корневого пространства имён задаётся папка через autoload_psr4.php, а дальше - по стандарту, каждое новое "подпространство" - это новая папка, а имя класса - имя файла. Остальные файлы autoload* - это файлы, необходимые для поиска классов в библиотеках, не следующих PSR
https://github.com/laravel/framework/blob/5.2/src/Illuminat ... swords.php Код (PHP): public function getReset(Request $request, $token = null) { return $this->showResetForm($request, $token); } /** * Display the password reset view for the given token. * * If no token is present, display the link request form. * * @param \Illuminate\Http\Request $request * @param string|null $token * @return \Illuminate\Http\Response */ public function showResetForm(Request $request, $token = null) { if (is_null($token)) { return $this->getEmail(); } А у меня было в этом файле: Код (PHP): public function getReset($token = null) { return $this->showResetForm($token); } /** * Display the password reset view for the given token. * * If no token is present, display the link request form. * * @param \Illuminate\Http\Request $request * @param string|null $token * @return \Illuminate\Http\Response */ public function showResetForm(Request $request, $token = null) { if (is_null($token)) { return $this->getEmail(); } И как после этого что то не поменять?