v2.0.0设计方案

[sunxiyuan]

组件声明方式

PHP作为一个弱类型语言，于是人们使用时不习惯于先构建数据结构而是Array一把梭。这样在编写程序时毫无疑问是很爽的，但是维护时谁晓得这个Array里面的数据应该如何组织？

这个时候只能靠文档和代码注释去标识，但总觉得不爽，因为IDE没办法给任何提示，只能全手工操作，难免遗漏、难免出错。更何况文档和注释根据代码进行实时更新也很繁琐且容易遗忘。

这些问题也是文派开发框架目前遇到的问题。当前的组件声明方案是参考了CodeStarFramework，使用Array描述，于是这些问题也从CodeStarFramework一并继承了下来。

在2.0.0版本中我希望能改善这种状况，希望可以让组件的构建强制数据类型，也可以让代码拥有自解释的能力，而无需太多文档 or 注释。

初步设想的方案如下：

Setting::create('一个标题', '一个slug', '是否支持网络', function (Fields $fields) {
    return $fields
        ->tag('选项卡一', function (Fields $fields) {
            return $fields
                ->text('这是组件ID', function (Text $attr) {
                    return $attr
                        ->placeholder('这里是预输入信息')
                        ->description('这里是详情');
                })->text('这是组件ID', function (Text $attr) {
                    return $attr
                        ->placeholder('这里是预输入信息')
                        ->description('这里是详情');
                })->text('这是组件ID', function (Text $attr) {
                    return $attr
                        ->placeholder('这里是预输入信息')
                        ->description('这里是详情');
                })->text('这是组件ID', function (Text $attr) {
                    return $attr
                        ->placeholder('这里是预输入信息')
                        ->description('这里是详情');
                });
        })->tag('选项卡二', function (Fields $fields) {
            return $fields
                ->text('这是组件ID', function (Text $attr) {
                    return $attr
                        ->placeholder('这里是预输入信息')
                        ->description('这里是详情');
                })->text('这是组件ID', function (Text $attr) {
                    return $attr
                        ->placeholder('这里是预输入信息')
                        ->description('这里是详情');
                })->text('这是组件ID', function (Text $attr) {
                    return $attr
                        ->placeholder('这里是预输入信息')
                        ->description('这里是详情');
                })->text('这是组件ID', function (Text $attr) {
                    return $attr
                        ->placeholder('这里是预输入信息')
                        ->description('这里是详情');
                });
        });
});

核心思想就是为抛弃数组的组织形式，使用对象的链式调用，并为每个组件增加一个回调，回调中的$attr参数将是保存这个组件属性的数据结构，该数据结构拥有一组方法用于设置组件属性。

于是IDE就可以在你编码时给你弹出提示告诉你这个组件一共有哪些属性，你也可以通过候选词的名称判断出设置这个属性你将获得什么效果。

当然，缺点就是代码量瞬间膨胀了……

---

交流了下，有人说这种组件声明方式耦合太严重。理由是代码一坨套一坨、一层套一层。

不过这个我觉得是完全可以在调用时拆分开的：

/** 
  * 先生成一个文本框组件 
  */
/** 首先构造文本框的属性 */
$text_attr = new Text();
$text_attr->placeholder('这里是预输入信息')
          ->description('这里是详情');
/** 生成一个文本框表单组件 */
$text = new Fields::text('这是组件ID', $text_attr);

/** 
  *生成一个设置页，将这个文本框表单组件放进去 
  */
Setting::create('一个标题', '一个slug', '是否支持网络', $text); 

于是这样就构建了一个只包含一个文本框表单的设置页。

我认可降低代码耦合度是没错的，但是有时候耦合是不可避免的，就好像写java程序不可能跟jdk不耦合吧？也就好像组件本来就应该放到设置页里，这俩必然是要耦合的。如果耦合仅仅指代码结构上一层套一层很难看的话，像我刚刚这样把他们拆开分别生成似乎也可？

---

又交流了下，原来他指的耦合是应该如同vue一样，只提供一个组件接口而不应该预置组件，组件应该是用到什么再安装什么或者自己编写。考虑到vue有一套前端编译器可以帮助做这些工作。对于php的话可以借助composer，把每个组件封装成一个依赖包，然后在composer.json里面声明当前应用依赖的组件，然后使用composer统一安装、更新，这样其他人也可以分享自己编写的组件，似乎不错。

引入这一层思考后，前面的方案得有些调整，目前还在想……

目录结构

wenpai-framework
├── fields             
│   └── text           
│       ├── class-text.php     
│       ├── css（可选）    
│       └── js（可选）                    

这套方案还在持续构思完善中，如果谁有好的想法欢迎交流。

[sunxiyuan]

发现WordPress的插件、主题开发似乎没有类似thinkphp和springboot这样直接帮开发者生成好项目结构，而开发者只需要像做填空题一样填上功能代码即可的开发框架。于是类似thinkphp的开发者切到wordpress开发时会无所适从，因为这里的一切都要自己从头去构建，代码也要自己从0组织，就好像一个平常只需要填填考卷上的空格的考生突然被要求从白纸开始连出题带答题写满一张考卷。 类似CodeStarFramework这些开发框架感觉叫“组件库”更合适一点，并不能帮开发者组织代码。 于是2.0.0版中考虑是不是也能设计出一个类似thinkphp那样的机制，帮开发者组织好整个项目的结构，这样应该可以保证开发出来的项目下限会比较高。 还是初步设想，权当记录。

---

思考了下，发现这个想法实现起来很困难，因为thinkphp、laravel这些都是mvc框架，本身是面向一个很窄的领域的，于是就可以尽量把这个领域中用到的东西抽象、复用。但WordPress插件可以是数据采集的爬虫、也可以是地图、还可以是对wordpress本身的某些功能进行更改，于是他们之间的共通点就很少，很难抽象出类似mvn框架这种东西。如果是像springboot这样只提供一个基础的容器，然后其他具体领域依托具体的上层框架，比如springmvc这些来实现的话工作量就大到无边了。

[sunxiyuan]

类似laravel那样提供一个命令行工具似乎也不错。路由模块、配置模块、设置页模块等等的模块都可以通过这个命令行启用，启用后就为开发者通过compose安装对应的包并在项目中创建需要的目录or文件，比如说启用了路由模块就创建一个route.php文件用来写路由表。

[sunxiyuan]

原来WordPress已经有不少的MVC框架了，比如：https://www.wordpress-mvc.com/，看起来还不错，有待研究