Рекомендации для пользовательских помощников на Laravel 5

Я хотел бы создать некоторые помощники (функции), чтобы избежать повторения кода между некоторыми представлениями, в стиле L5:

вид.лезвие.php

<p>Foo Formated text: {{ fooFormatText($text) }}</p>

они в основном функции форматирования текста. Где и как я могу поместить файл с этими функциями?

20 323

php laravel laravel-5

20 ответов:

моя первоначальная мысль была автозагрузкой композитора, но она не казалась мне очень Laravel 5ish. L5 интенсивно использует поставщиков услуг,они-то, что загружает ваше приложение.

для начала я создал папку в моих файл Helpers каталог загружен и готов к использованию.

обновление 2016-02-22

есть много хороших вариантов, но если мой ответ работает для вас, я пошел вперед и сделал пакет для включения помощников таким образом. Вы можете либо использовать пакет для вдохновения или не стесняйтесь, чтобы загрузить его с композитором, а также. Он имеет некоторые встроенные помощники, которые я часто использую (но которые все неактивны по умолчанию) и позволяет вам создавать свои собственные помощники с помощью простого генератора ремесленников. Он также обращается к предложению одного ответчика использовать mapper и позволяет явно определить пользовательские помощники для загрузки или по умолчанию автоматически загружать все PHP-файлы в вашем вспомогательный каталог. Обратная связь и PRs очень ценятся!
composer require browner12/helpers
Github:browner12 / helpers

267

пользовательские классы в Laravel 5, простой способ

этот ответ применим к общие пользовательские классы в Laravel. Более точный ответ на этот вопрос см. В разделе пользовательские директивы лезвия в Laravel 5.

Шаг 1: создайте файл Helpers (или другой пользовательский класс) и дайте ему соответствующее пространство имен. Напишите свой класс и метод:
<?php // Code within app\Helpers\Helper.php

namespace App\Helpers;

class Helper
{
 public static function shout(string $string)
 {
 return strtoupper($string);
 }
}
Шаг 2: создать псевдоним:
<?php // Code within config/app.php

 'aliases' => [
 ...
 'Helper' => App\Helpers\Helper::class,
 ...
Шаг 3: используйте его в шаблоне лезвия:


{!! Helper::shout('this is how to use autoloading correctly!!') !!}
Дополнительно: используйте этот класс в любом месте вашего приложения Laravel:
<?php // Code within app/Http/Controllers/SomeController.php

namespace App\Http\Controllers;

use Helper;

class SomeController extends Controller
{

 public function __construct()
 {
 Helper::shout('now i\'m using my helper class in a controller!!');
 }
 ...
источник:http://www.php-fig.org/psr/psr-4/

почему это работает: https://github.com/laravel/framework/blob/master/src/Illuminate/Support/ClassLoader.php

где происходит автоматическая загрузка от: http://php.net/manual/en/language.oop5.autoload.php

259

это то, что предлагается JeffreyWay в этой Обсуждение Laracasts.

в своем

67

просеяв множество ответов на SO и Google, я все еще не мог найти оптимальный подход. Большинство ответов предлагают нам оставить приложение и полагаться на 3rd party tool Composer для выполнения этой работы, но я не уверен, что соединение с инструментом просто для включения файла разумно.

ответ Эндрю Брауна подошел ближе всего к тому, как я думаю, что к нему нужно подходить, но (по крайней мере, в 5.1), шаг поставщика услуг не нужен. Heisian это подчеркивает использование PSR-4 что приближает нас на один шаг. Вот моя окончательная реализация для помощников в представлениях:

во-первых, создайте вспомогательный файл в любом месте каталога приложений с пространством имен:
namespace App\Helpers;

class BobFinder
{
 static function bob()
 {
 return 'Bob?! Is that you?!';
 }
}
далее, псевдоним вашего класса в config\app.php, в aliases время:
'aliases' => [
 // Other aliases
 'BobFinder' => App\Helpers\BobFinder::class
]
и это должно быть все, что вам нужно сделать. PSR-4 и псевдоним должен предоставить помощнику ваши представления, так что в вашем представлении, если вы наберете:
{!! BobFinder::bob() !!}
он должен вывод:
Bob?! Is that you?!

43

пользовательские директивы лезвия в Laravel 5

Да, есть другое способ сделать это!

Шаг 1: Регистрация пользовательской директивы Blade:
<?php // code in app/Providers/AppServiceProvider.php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;

use Blade; // <-- This is important! Without it you'll get an exception.

class AppServiceProvider extends ServiceProvider
{
 /**
 * Bootstrap any application services.
 *
 * @return void
 */
 public function boot()
 {
 // Make a custom blade directive:
 Blade::directive('shout', function ($string) {
 return trim(strtoupper($string), '(\'\')');
 });

 // And another one for good measure:
 Blade::directive('customLink', function () {
 return '<a href="#">Custom Link</a>';
 });
 }
 ...
Шаг 2: используйте свою пользовательскую директиву Blade:


@shout('this is my custom blade directive!!')
 
@customLink
выходы:

ЭТО МОЯ ПОЛЬЗОВАТЕЛЬСКАЯ ДИРЕКТИВА BLADE!!
Пользовательские Ссылке

источник: https://laravel.com/docs/5.1/blade#extending-blade

дополнительное чтение: https://mattstauffer.co/blog/custom-conditionals-with-laravels-blade-directives

если вы хотите узнать, как лучше сделать пользовательские классы, которые вы можете использовать в любом месте см. пользовательские классы в Laravel 5, простой способ

24

это мой HelpersProvider.файл php:
<?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;

class HelperServiceProvider extends ServiceProvider
{
 protected $helpers = [
 // Add your helpers in here
 ];

 /**
 * Bootstrap the application services.
 */
 public function boot()
 {
 //
 }

 /**
 * Register the application services.
 */
 public function register()
 {
 foreach ($this->helpers as $helper) {
 $helper_path = app_path().'/Helpers/'.$helper.'.php';

 if (\File::isFile($helper_path)) {
 require_once $helper_path;
 }
 }
 }
}
вы должны создать папку с именем Helpers под app папка, затем создайте файл с именем whatever.php внутри и добавить строку whatever внутри массива $helpers.

готово!

Edit

Я больше не использую эту опцию, в настоящее время я использую composer для загрузки статических файлов, таких как helpers.

вы можете добавить помощников непосредственно в:
...
"autoload": {
 "files": [
 "app/helpers/my_helper.php",
 ...
 ]
},
...

17

для пользовательских вспомогательных библиотек в моем проекте Laravel я создал папку с именем Libraries в своем Laravel/App каталог и в каталоге библиотек, я создал различные файлы для различных вспомогательных библиотек.

после создания моих вспомогательных файлов я просто включаю все эти файлы в мой композитор.json такой
...
"autoload": {
        "classmap": [
            "database"
        ],
        "files": [
            "app/Libraries/commonFunctions.php"
        ],
        "psr-4": {
            "App\": "app/"
        }
    },
...
и выполнить
composer dumpautoload

6

вместо того, чтобы включать свой пользовательский класс помощника, вы можете добавить в свой

6

так как ОП просил лучшие практики, Я думаю, что мы все еще не хватает некоторых хороших советов здесь.

один помощников.php файл далек от хорошей практики. Во-первых, потому что вы смешиваете много разных функций, поэтому вы против хороших принципов кодирования. Более того, это может повредить не только документацию по коду, но и метрики кода, такие как Цикломатическая Сложность,Ремонтопригодность Индекс и Объем Холстед. Чем больше функций, тем больше он становится хуже.

документация по коду будет в порядке, используя такие инструменты, как phpDocumentor, но через сами это не будет отображать процедурные файлы. Документация Laravel API-это такой случай - нет документации вспомогательных функций:https://laravel.com/api/5.4

метрики кода могут быть проанализированы с помощью таких инструментов, как PhpMetrics. С помощью PhpMetrics Версия 1.x для анализа кода Laravel 5.4 framework даст вам очень плохие показатели CC/MI/HV для обоих src / Illuminate/Foundation / helpers.php и src / подсветка / поддержка / помощники.php файлы.

несколько контекстных вспомогательных файлов (например. string_helpers.php,array_helpers.php и т. д.) безусловно, улучшит эти плохие показатели, что приведет к более простому коду для поддержки. В зависимости от кода генератор документации использовал это было бы достаточно хорошо.

он может быть дополнительно улучшен с помощью вспомогательных классов со статическими методами, так что они могут быть контекстуализированы с помощью пространств имен. Так же, как Ларавель уже делает с Illuminate\Support\Str и Illuminate\Support\Arr классы. Это улучшает как метрики кода / организации и документации. Псевдонимы классов могут использоваться для упрощения их использования.

структурирование с помощью классов делает код организации и документация лучше, но с другой стороны мы в конечном итоге теряем эти большие короткие и легко запоминающиеся глобальные функции. Мы можем еще больше улучшить этот подход, создав псевдонимы функций для этих методов статических классов. Это можно сделать вручную или динамически.

Laravel внутренне использует первый подход, объявляя функции в процедурных вспомогательных файлах, которые сопоставляются с методами статических классов. Это может быть не идеальная вещь, так как вам нужно переоформить все вещи (установки/параметры).
Я лично использую динамический подход с HelperServiceProvider класс, который создает эти функции во время выполнения:
<?php

namespace App\Providers;

use Illuminate\Support\ServiceProvider;

class HelperServiceProvider extends ServiceProvider
{
 /**
 * The helper mappings for the application.
 *
 * @var array
 */
 protected $helpers = [
 'uppercase' => 'App\Support\Helpers\StringHelper::uppercase',
 'lowercase' => 'App\Support\Helpers\StringHelper::lowercase',
 ];

 /**
 * Bootstrap the application helpers.
 *
 * @return void
 */
 public function boot()
 {
 foreach ($this->helpers as $alias => $method) {
 if (!function_exists($alias)) {
 eval("function {$alias}(...$args) { return {$method}(...$args); }");
 }
 }
 }

 /**
 * Register the service provider.
 *
 * @return void
 */
 public function register()
 {
 //
 }
}
можно сказать, что это за инженер, но я так не думаю. Он работает довольно хорошо и вопреки тому, что можно было бы ожидать, он не стоит соответствующего времени выполнения, по крайней мере, при использовании PHP 7.x.

5

вот сценарий оболочки bash, который я создал, чтобы сделать Laravel 5 фасадов очень быстро.

запустите это в каталоге установки Laravel 5.

назовем это так:

make_facade.sh -f <facade_name> -n '<namespace_prefix>'

пример:

make_facade.sh -f helper -n 'App\MyApp'

если вы запустите этот пример, он создаст каталоги Facades и Providers в разделе 'your_laravel_installation_dir/app / MyApp'.

он создаст следующие 3 файла, а также выведет их на экран экран:

./app/MyApp/Facades/Helper.php
./app/MyApp/Facades/HelperFacade.php
./app/MyApp/Providers/HelperServiceProvider.php

после того как это будет сделано, появится сообщение, похожее на следующее:

===========================
    Finished
===========================

Add these lines to config/app.php:
----------------------------------
Providers: App\MyApp\Providers\HelperServiceProvider,
Alias: 'Helper' => 'App\MyApp\Facades\HelperFacade',

поэтому обновите список поставщиков и псевдонимов в ' config/app.php'

Run composer -o dumpautoload

The"./приложение/Приложение/фасадов/помощник.php " изначально будет выглядеть так:

<?php

namespace App\MyApp\Facades;


class Helper
{
    //
}

теперь просто добавьте ваши методы "./приложение/Приложение/фасадов/помощник.РНР."

вот что "./приложение/Приложение/фасадов/помощник.php " выглядит как после того, как я добавил Вспомогательная функция.

<?php

namespace App\MyApp\Facades;

use Request;

class Helper
{
    public function isActive($pattern = null, $include_class = false)
    {
        return ((Request::is($pattern)) ? (($include_class) ? 'class="active"' : 'active' ) : '');
    }
}

This is how it would be called:
===============================

{!!  Helper::isActive('help', true) !!}

эта функция ожидает массив и может принимать необязательный второй логический аргумент.

если текущий URL-адрес соответствует переданному ему шаблону, он выведет"active" (или "class= "active"", если вы добавите "true" в качестве второго аргумента к вызову функции).

я использую его, чтобы выделить меню, которое является активной.

Ниже приведен исходный код для моего скрипта. Я надеюсь, что вы найдете его полезным и, пожалуйста, дайте мне знать, если у вас есть никаких проблем с этим нет.

#!/bin/bash

display_syntax(){
    echo ""
    echo "  The Syntax is like this:"
    echo "  ========================"
    echo "      "$(basename )" -f <facade_name> -n '<namespace_prefix>'"
    echo ""
    echo "  Example:"
    echo "  ========"
    echo "      "$(basename ) -f test -n "'App\MyAppDirectory'"
    echo ""
}


if [ $# -ne 4 ]
then
    echo ""
    display_syntax
    exit
else
# Use > 0 to consume one or more arguments per pass in the loop (e.g.
# some arguments don't have a corresponding value to go with it such
# as in the --default example).
    while [[ $# > 0 ]]
    do
        key=""
            case $key in
            -n|--namespace_prefix)
            namespace_prefix_in=""
            echo ""
            shift # past argument
            ;;
            -f|--facade)
            facade_name_in=""
            shift # past argument
            ;;
            *)
                    # unknown option
            ;;
        esac
        shift # past argument or value
    done
fi
echo Facade Name = ${facade_name_in}
echo Namespace Prefix = $(echo ${namespace_prefix_in} | sed -e 's#\#\\#')
echo ""
}


function display_start_banner(){

    echo '**********************************************************'
    echo '*          STARTING LARAVEL MAKE FACADE SCRIPT'
    echo '**********************************************************'
}

#  Init the Vars that I can in the beginning
function init_and_export_vars(){
    echo
    echo "INIT and EXPORT VARS"
    echo "===================="
    #   Substitution Tokens:
    #
    #   Tokens:
    #   {namespace_prefix}
    #   {namespace_prefix_lowerfirstchar}
    #   {facade_name_upcase}
    #   {facade_name_lowercase}
    #


    namespace_prefix=$(echo ${namespace_prefix_in} | sed -e 's#\#\\#')
    namespace_prefix_lowerfirstchar=$(echo ${namespace_prefix_in} | sed -e 's#\#/#g' -e 's/^\(.\)/\l/g')
    facade_name_upcase=$(echo ${facade_name_in} | sed -e 's/\b\(.\)/\u/')
    facade_name_lowercase=$(echo ${facade_name_in} | awk '{print tolower()}')


#   Filename: {facade_name_upcase}.php  -  SOURCE TEMPLATE
source_template='<?php

namespace {namespace_prefix}\Facades;

class {facade_name_upcase}
{
    //
}
'


#  Filename: {facade_name_upcase}ServiceProvider.php    -   SERVICE PROVIDER TEMPLATE
serviceProvider_template='<?php

namespace {namespace_prefix}\Providers;

use Illuminate\Support\ServiceProvider;
use App;


class {facade_name_upcase}ServiceProvider extends ServiceProvider {

    public function boot()
    {
        //
    }

    public function register()
    {
        App::bind("{facade_name_lowercase}", function()
        {
            return new \{namespace_prefix}\Facades\{facade_name_upcase};
        });
    }

}
'

#  {facade_name_upcase}Facade.php   -   FACADE TEMPLATE
facade_template='<?php

namespace {namespace_prefix}\Facades;

use Illuminate\Support\Facades\Facade;

class {facade_name_upcase}Facade extends Facade {

    protected static function getFacadeAccessor() { return "{facade_name_lowercase}"; }
}
'
}


function checkDirectoryExists(){
    if [ ! -d ${namespace_prefix_lowerfirstchar} ]
    then
        echo ""
        echo "Can't find the namespace: "${namespace_prefix_in}
        echo ""
        echo "*** NOTE:"
        echo "           Make sure the namspace directory exists and"
        echo "           you use quotes around the namespace_prefix."
        echo ""
        display_syntax
        exit
    fi
}

function makeDirectories(){
    echo "Make Directories"
    echo "================"
    mkdir -p ${namespace_prefix_lowerfirstchar}/Facades
    mkdir -p ${namespace_prefix_lowerfirstchar}/Providers
    mkdir -p ${namespace_prefix_lowerfirstchar}/Facades
}

function createSourceTemplate(){
    source_template=$(echo "${source_template}" | sed -e 's/{namespace_prefix}/'${namespace_prefix}'/g' -e 's/{facade_name_upcase}/'${facade_name_upcase}'/g' -e 's/{facade_name_lowercase}/'${facade_name_lowercase}'/g')
    echo "Create Source Template:"
    echo "======================="
    echo "${source_template}"
    echo ""
    echo "${source_template}" > ./${namespace_prefix_lowerfirstchar}/Facades/${facade_name_upcase}.php
}

function createServiceProviderTemplate(){
    serviceProvider_template=$(echo "${serviceProvider_template}" | sed -e 's/{namespace_prefix}/'${namespace_prefix}'/g' -e 's/{facade_name_upcase}/'${facade_name_upcase}'/g' -e 's/{facade_name_lowercase}/'${facade_name_lowercase}'/g')
    echo "Create ServiceProvider Template:"
    echo "================================"
    echo "${serviceProvider_template}"
    echo ""
    echo "${serviceProvider_template}" > ./${namespace_prefix_lowerfirstchar}/Providers/${facade_name_upcase}ServiceProvider.php
}

function createFacadeTemplate(){
    facade_template=$(echo "${facade_template}" | sed -e 's/{namespace_prefix}/'${namespace_prefix}'/g' -e 's/{facade_name_upcase}/'${facade_name_upcase}'/g' -e 's/{facade_name_lowercase}/'${facade_name_lowercase}'/g')
    echo "Create Facade Template:"
    echo "======================="
    echo "${facade_template}"
    echo ""
    echo "${facade_template}" > ./${namespace_prefix_lowerfirstchar}/Facades/${facade_name_upcase}Facade.php
}


function serviceProviderPrompt(){
    echo "Providers: ${namespace_prefix_in}\Providers\${facade_name_upcase}ServiceProvider,"
}

function aliasPrompt(){
    echo "Alias: '"${facade_name_upcase}"' => '"${namespace_prefix_in}"\Facades\${facade_name_upcase}Facade'," 
}

#
#   END FUNCTION DECLARATIONS
#


###########################
## START RUNNING SCRIPT  ##
###########################

display_start_banner

init_and_export_vars
makeDirectories 
checkDirectoryExists
echo ""

createSourceTemplate
createServiceProviderTemplate
createFacadeTemplate
echo ""
echo "==========================="
echo "  Finished TEST"
echo "==========================="
echo ""
echo "Add these lines to config/app.php:"
echo "----------------------------------"
serviceProviderPrompt
aliasPrompt
echo ""

3

создать каталог пользовательских помощников: Сначала создайте каталог помощников в каталоге приложений. создать определение класса hlper: Теперь давайте создадим простую вспомогательную функцию, которая объединит две строки. Создайте новый файл MyFuncs.php в /app / Helpers / MyFuncs.php добавить следующий код
<?php

namespace App\Helpers;

class MyFuncs {

 public static function full_name($first_name,$last_name) {
 return $first_name . ', '. $last_name; 
 }
}
пространство имен App\Helpers; определяет пространство имен Helpers в разделе пространство имен приложений. класс MyFuncs { ... } определяет вспомогательный класс MyFuncs. публичная статическая функция full_name($имя,$фамилия) {...} определяет статическую функцию, которая принимает два строковых параметра и возвращает объединенную строку

обслуживание помощников обеспечивает класс

поставщики услуг используются для автоматической загрузки классов. Нам нужно будет определить поставщика услуг, который будет загружать все наши вспомогательные классы в каталог/app / Helpers.

выполните следующую команду artisan:

php artisan make: provider HelperServiceProvider

файл будет создан в /app/Providers/HelperServiceProvider.php
Open /app/Providers/HelperServiceProvider.php
добавить следующий код:
<?php 

namespace App\Providers;

use Illuminate\Support\ServiceProvider;

class HelperServiceProvider extends ServiceProvider {

 /**
 * Bootstrap the application services.
 *
 * @return void
 */
 public function boot()
 {
 //
 }

 /**
 * Register the application services.
 *
 * @return void
 */
 public function register()
 {
 foreach (glob(app_path().'/Helpers/*.php') as $filename){
 require_once($filename);
 }
 }
}
здесь
namespace App\Providers; defines the namespace provider
use Illuminate\Support\ServiceProvider; imports the ServiceProvider class namespace
class HelperServiceProvider extends ServiceProvider {…} defines a class HelperServiceProvider that extends the ServiceProvider class
public function boot(){…} bootstraps the application service
public function register(){…} is the function that loads the helpers
foreach (glob(app_path().'/Helpers/*.php') as $filename){…} loops through all the files in /app/Helpers directory and loads them.
теперь нам нужно зарегистрировать HelperServiceProvider и создать псевдоним для наших помощников.

открыть /config/app.php file

найдите переменную массива провайдеров

добавить следующую строку
App\Providers\HelperServiceProvider::class,
подобрать массив алиасов переменная

добавить следующую строку
'MyFuncs' => App\Helpers\MyFuncs::class,
Сохранить изменения Используя наш пользовательский помощник

мы создадим маршрут, который вызовет нашу пользовательскую вспомогательную функцию Open/app / routes.php

добавить следующее определение маршрута
Route::get('/func', function () {
 return MyFuncs::full_name("John","Doe");
});
здесь
return MyFuncs::full_name("John","Doe"); calls the static function full_name in MyFuncs class

3

еще один способ, который я использовал, был: 1) создал файл в app\FolderName\fileName.php и имел этот код внутри него, т. е.
<?php
namespace App\library
{
 class hrapplication{
 public static function libData(){
 return "Data";
 }
 }
}
?>
2) После этого в нашем лезвием
 $FmyFunctions = new \App\FolderName\classsName;
 echo $is_ok = ($FmyFunctions->libData());
вот именно. и это работает

2

Лучшая практика для написания пользовательских помощников является

1) внутри app каталог корня проекта, создайте папку с именем Helpers (просто чтобы отделить и структурировать код).

2) внутри папки пишите psr-4 файлы или обычные php файлы

если PHP файлы находятся в формате psr-4, то он будет автоматически загружен, иначе добавить следующую строку в композиторе.json, который находится внутри корневого каталога проекта

внутри autoload ключ, создать новый ключ с именем files для загрузки файлов во время автоматической загрузки,внутри files объект добавить путь, начиная с каталога приложений. вот вам пример.
"autoload": {
    "classmap": [
        "database"
    ],
    "psr-4": {
        "App\": "app/"
    },
    "files": [
        "app/Helpers/customHelpers.php"
    ]
},
"autoload-dev": {
    "classmap": [
        "tests/TestCase.php"
    ]
},
PS: попробуйте запустить composer dump-autoload если файл не загружается.

2

в dir bootstrap\autoload.php
require __DIR__.'/../vendor/autoload.php';
require __DIR__.'/../app/Helpers/function.php'; //add
добавить этот файл
app\Helpers\function.php

1

создать помощников.php внутри каталога App\Http. Затем добавьте следующий код внутри композитора.json
"autoload": {
        "classmap": [
            "database"
        ],
        "files": [
            "app/Http/helpers.php"
        ],
        "psr-4": {
            "App\": "app/"
        }
    },
далее выполните следующую команду
composer dump-autoload
теперь вы можете определить пользовательскую функцию внутри помощники.PHP-файл. Здесь вы можете получить полное руководство

1

я не согласен с любым другим ответом на этот вопрос!

во-первых, нет ничего плохого в наличии нескольких глобальных вспомогательных функций. Например, приложение, над которым я сейчас работаю, - это пять лет (оно началось на Laravel 3!) и имеет в общей сложности всего шесть глобальных функций, которые часто используются для форматирования даты и отладки. В глобальном пространстве имен нет конфликтов с другими функциями, и по своей сути они не объектно-ориентированные, так зачем же делать их статическими методами в контейнерном классе? Одна вещь, которую я считаю хуже, чем слишком сильно полагаться на старый добрый функций упаковывать их в классы и обманывать себя, думая, что вы сейчас делаете вещи Правильно. Кроме того, необходимость префикса этих вспомогательных функций с именем класса или псевдонимом класса просто ужасно болезненна, поэтому я предпочитаю держать их как простые глобальные функции.

во-вторых, если мы хотим говорить о чистоте кода, мы не должны рассматривать решение, которое падает в любом месте app/ как app/ папка предназначена только для классов PSR-4.

кроме того, я думаю, что многие ответы просто слишком сложны. Создание новых классов провайдеров только для автоматической загрузки кучи другого кода, когда уже есть совершенно хорошее место для автоматической загрузки кода, просто глупо.

я заметил только один ответ, который рассматривал изменение bootstrap/autoload.php, который, по моему мнение, это абсолютно самое подходящее место для подключения. Нет никакого правила, написанного или иного, которое говорит, что мы не должны изменять этот файл. Конечно, вам нужно проверить, изменяется ли он от одного выпуска Laravel к следующему, но то же самое касается файлов конфигурации, классов поставщиков, очереди и т. д.

поэтому я считаю, что самое простое, наиболее подходящее решение-создать файл в bootstrap папка с именем helpers.php и добавьте следующую строку в конце boostrap/autoload.php:
require __DIR__.'/helpers.php';
тот другой ответ, который предложил изменить autoload.php был почти идеальный ответ (ИМО), за исключением того, что они предложили поставить function.php на

1

Создать Помощников.php в приложении / Helper / Helpers.php
namespace App\Helper
class Helpers
{


}
добавить в композитор и композитор обновление
 "autoload": {
 "classmap": [
 "database/seeds",
 "database/factories",
 "database","app/Helper/Helpers.php"
 ],
 "psr-4": {
 "App\": "app/"
 },
 "files": ["app/Helper/Helpers.php"]
 },
использовать в контроллере
use App\Helper\Helpers
использовать в поле зрения изменение в конфигурации - >приложение.файл php
 'aliases' => [
 ...
 'Helpers' => 'App\Helper\Helpers'
 ],
вызов в поле зрения
<?php echo Helpers::function_name(); ?>

1

в laravel 5.3 и выше команда laravel переместила все процедурные файлы (routes.php) из и psr-4 с автоматической загрузкой. Принятый ответ будет работать в этом случае, но это не кажется мне правильным.

Итак, что я сделал, я создал helpers/ каталог в корне моего проекта и поместить вспомогательные файлы внутри этого, и в моем composer.json файл я сделал это:
...
"autoload": {
    "classmap": [
        "database"
    ],
    "psr-4": {
        "App\": "app/"
    },
    "files": [
        "helpers/ui_helpers.php"
    ]
},
...
мой app/ каталог по-прежнему psr-4 загруженный один, и помощники немного лучше организованы.

надеюсь, это кому-то поможет.

0

есть некоторые отличные ответы здесь, но я думаю, что это самый простой. В Laravel 5.4 (и более ранних версиях prob тоже) вы можете создать класс где-то удобно для вас, например App/Libraries/Helper.php
class Helper() {
 public function uppercasePara($str) {
 return '' .strtoupper($str). ';
 }
}
тогда вы можете просто вызвать его в своем шаблоне лезвия следующим образом:
@inject('helper', \App\Libraries\Helper)
{{ $helper->drawTimeSelector() }}
Если вы не хотите использовать @inject, то просто сделайте функцию "uppercasePara" статической и вставьте вызов в свой шаблон Blade следующим образом:
{{ \App\Libraries\Helper::drawTimeSelector() }}
нет необходимости для псевдонимов. Laravel разрешает конкретный класс автоматически.

0

Joseph Silber · Accepted Answer · 2018-09-05 16:05:38

создать helpers.php файл в папке приложения и загрузить его с composer:
"autoload": {
 "classmap": [
 ...
 ],
 "psr-4": {
 "App\": "app/"
 },
 "files": [
 "app/helpers.php" // <---- ADD THIS
 ]
},
после добавления этого к вашему composer.json file, выполните следующую команду:
composer dump-autoload
Если вам не нравится держать свой в своем app каталог (потому что это не файл класса PSR-4 с пространством имен), вы можете сделать то, что laravel.com сайт: магазин helpers.phpв каталоге начальной загрузки. Не забудьте установить его в свой composer.json файл:
"files": [
 "bootstrap/helpers.php"
]