我想创建帮助函数,以避免在Laravel视图之间重复代码。例如:
view.blade.php
<p>Foo Formated text: {{ fooFormatText($text) }}</p>
它们基本上是文本格式化函数。我应该如何定义全局可用的帮助函数,如fooFormatText()?
我想创建帮助函数,以避免在Laravel视图之间重复代码。例如:
view.blade.php
<p>Foo Formated text: {{ fooFormatText($text) }}</p>
它们基本上是文本格式化函数。我应该如何定义全局可用的帮助函数,如fooFormatText()?
当前回答
我知道现在回答这个问题已经很晚了,但是,这个问题每天都发生在所有初级开发人员身上,所以对于直接步骤,请执行以下步骤:
**将你的helper函数分组到类中(使用刀片中的函数只是使它们静态),并将所有类放在配置Laravel文件夹app.php别名
'aliases' => [
"YourClassName" => App\Support\YourClassName,
]
现在你可以在刀片和控制器上使用所有的静态函数了。
其他回答
在你的app文件夹中创建一个helpers.php文件,并用composer加载它:
"autoload": {
"classmap": [
...
],
"psr-4": {
"App\\": "app/"
},
"files": [
"app/helpers.php" // <---- ADD THIS
]
},
然后把它添加到你的作曲家。Json文件,执行如下命令:
composer dump-autoload
如果您不喜欢将helpers.php文件保存在app目录中(因为它不是一个PSR-4命名空间类文件),您可以做laravel.com网站所做的事情:将helpers.php存储在bootstrap目录中。记得在你的作曲器中设置它。json文件:
"files": [
"bootstrap/helpers.php"
]
在Laravel 5.3及以上版本中,Laravel团队将所有过程文件(routes.php)移出了app/目录,整个app/文件夹是psr-4自动加载的。接受的答案在这种情况下是可行的,但我感觉不对。
所以我所做的就是在我的项目的根目录下创建了一个helpers/目录,并把helper文件放在里面,放在我的composer中。我这样做:
...
"autoload": {
"classmap": [
"database"
],
"psr-4": {
"App\\": "app/"
},
"files": [
"helpers/ui_helpers.php"
]
},
...
这样我的app/目录仍然是psr-4自动加载的,并且帮助程序组织得更好一些。
我知道现在回答这个问题已经很晚了,但是,这个问题每天都发生在所有初级开发人员身上,所以对于直接步骤,请执行以下步骤:
**将你的helper函数分组到类中(使用刀片中的函数只是使它们静态),并将所有类放在配置Laravel文件夹app.php别名
'aliases' => [
"YourClassName" => App\Support\YourClassName,
]
现在你可以在刀片和控制器上使用所有的静态函数了。
对于我的Laravel项目中的自定义助手库,我在我的Laravel/App目录中创建了一个名为Libraries的文件夹,在Libraries目录中,我为不同的助手库创建了各种文件。
在创建我的助手文件后,我简单地将所有这些文件包含在我的composer中。这样的Json文件
...
"autoload": {
"classmap": [
"database"
],
"files": [
"app/Libraries/commonFunctions.php"
],
"psr-4": {
"App\\": "app/"
}
},
...
和执行
composer dump-autoload
由于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时不会花费相关的执行时间。