我想创建帮助函数,以避免在Laravel视图之间重复代码。例如:
view.blade.php
<p>Foo Formated text: {{ fooFormatText($text) }}</p>
它们基本上是文本格式化函数。我应该如何定义全局可用的帮助函数,如fooFormatText()?
我想创建帮助函数,以避免在Laravel视图之间重复代码。例如:
view.blade.php
<p>Foo Formated text: {{ fooFormatText($text) }}</p>
它们基本上是文本格式化函数。我应该如何定义全局可用的帮助函数,如fooFormatText()?
当前回答
由于OP要求最佳实践,我认为我们仍然缺少一些好的建议。
单一的helpers.php文件远非一个好的实践。首先,因为你混合了很多不同类型的函数,所以你违背了良好的编码原则。此外,这不仅会损害代码文档,还会损害诸如圈复杂度、可维护性指数和Halstead Volume等代码指标。函数越多,情况就越糟。
使用phpDocumentor这样的工具,代码文档是可以的,但使用Sami,它不会呈现过程性文件。Laravel API文档就是这样一种情况——没有辅助函数文档:https://laravel.com/api/5.4
代码度量可以使用PhpMetrics等工具进行分析。使用PhpMetrics版本1。src/Illuminate/Foundation/helpers.php和src/Illuminate/Support/helpers.php文件的CC/MI/HV指标都非常糟糕。
多个上下文帮助文件(例如。String_helpers.php, array_helpers.php等)肯定会改善这些糟糕的指标,从而使代码更容易维护。根据所使用的代码文档生成器,这就足够了。
可以通过使用带有静态方法的helper类来进一步改进,这样它们就可以使用名称空间进行上下文化。就像Laravel已经对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时不会花费相关的执行时间。
其他回答
Laravel 5中的自定义类,简单的方法
这个答案适用于Laravel中的一般自定义类。有关更多Blade的具体答案,请参阅Laravel 5中的自定义Blade指令。
步骤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:在项目根目录下运行composer dump-autoload
第四步:在你的Blade模板中使用它:
<!-- Code within resources/views/template.blade.php -->
{!! 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
由于OP要求最佳实践,我认为我们仍然缺少一些好的建议。
单一的helpers.php文件远非一个好的实践。首先,因为你混合了很多不同类型的函数,所以你违背了良好的编码原则。此外,这不仅会损害代码文档,还会损害诸如圈复杂度、可维护性指数和Halstead Volume等代码指标。函数越多,情况就越糟。
使用phpDocumentor这样的工具,代码文档是可以的,但使用Sami,它不会呈现过程性文件。Laravel API文档就是这样一种情况——没有辅助函数文档:https://laravel.com/api/5.4
代码度量可以使用PhpMetrics等工具进行分析。使用PhpMetrics版本1。src/Illuminate/Foundation/helpers.php和src/Illuminate/Support/helpers.php文件的CC/MI/HV指标都非常糟糕。
多个上下文帮助文件(例如。String_helpers.php, array_helpers.php等)肯定会改善这些糟糕的指标,从而使代码更容易维护。根据所使用的代码文档生成器,这就足够了。
可以通过使用带有静态方法的helper类来进一步改进,这样它们就可以使用名称空间进行上下文化。就像Laravel已经对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时不会花费相关的执行时间。
在SO和谷歌上筛选了各种各样的答案后,我仍然没有找到一个最佳的方法。大多数答案建议我们离开应用程序,依靠第三方工具Composer来完成工作,但我不相信仅仅为了包含一个文件而耦合到一个工具是明智的。
Andrew Brown的回答最接近我认为应该如何处理它,但是(至少在5.1中),服务提供者步骤是不必要的。Heisian的回答强调了PSR-4的使用,这让我们更接近了一步。下面是视图中helper的最终实现:
首先,在你的app目录中创建一个helper文件,命名空间为:
namespace App\Helpers;
class BobFinder
{
static function bob()
{
return '<strong>Bob?! Is that you?!</strong>';
}
}
接下来,在config\app.php中,在aliases数组中为你的类添加别名:
'aliases' => [
// Other aliases
'BobFinder' => App\Helpers\BobFinder::class
]
这就是你需要做的。PSR-4和别名应该向你的视图公开helper,所以在你的视图中,如果你输入:
{!! BobFinder::bob() !!}
它应该输出:
<strong>Bob?! Is that you?!</strong>
对于我的Laravel项目中的自定义助手库,我在我的Laravel/App目录中创建了一个名为Libraries的文件夹,在Libraries目录中,我为不同的助手库创建了各种文件。
在创建我的助手文件后,我简单地将所有这些文件包含在我的composer中。这样的Json文件
...
"autoload": {
"classmap": [
"database"
],
"files": [
"app/Libraries/commonFunctions.php"
],
"psr-4": {
"App\\": "app/"
}
},
...
和执行
composer dump-autoload
编写自定义helper的最佳实践是
1)在项目根目录的app目录中,创建一个名为Helpers的文件夹(只是为了分离和构造代码)。
2)在文件夹中写入psr-4文件或普通php文件
如果PHP文件的格式是psr-4,那么它将被自动加载,否则在编写器中添加以下行。Json,在项目根目录中
在autoload key中,创建一个名为files的新key来在自动加载时加载文件,在files对象中添加从app目录开始的路径。这里有一个例子。
"autoload": {
"classmap": [
"database"
],
"psr-4": {
"App\\": "app/"
},
"files": [
"app/Helpers/customHelpers.php"
]
},
"autoload-dev": {
"classmap": [
"tests/TestCase.php"
]
},
PS:如果文件没有加载,尝试运行composer dump-autoload。