本帖最后由 凋灵兔子 于 2017-5-23 15:13 编辑
问题提出：MC服务器相关的插件不计其数，功能各异，其中部分插件由于各种原因需要借用Inventroy界面来实现使用“点点点”来代替传统的命令操作。当然使用界面本身比命令高大上一些，而且对于某些操作来说也更加简便。但是这用到的界面九成九都是死的，作者写成什么样，打开就是什么样，简直low到掉渣。当然，目前有两个解决方案：
1. 改源码（改完了还不是死的？我要改个定价都费劲，再说有多少腐竹懂怎么改？）
2. 借助BossShop，把我们的全部操作都用命令实现（那这个插件还是比较厉害的，就是写起来费劲）
相信99%的腐竹都想过就像改配置文件那么简单就可以修改插件内置的GUI界面。这里必须要注意：
1. 下面的全部方式不是要实现像BossShop那样高度自定义的界面，仅仅是实现让腐竹通过修改配置文件修改插件内置的Inventroy。
2. 牢记这个核心接口，后面有用：
复制代码这代码缩进我真是醉了，改了N才改好
本文是来探讨一种可以使用配置文件来达到完全控制Inv（性能以及美观上还算能过得去）的方案，不讨论各种高深的Java知识，也别跟我说什么框架接口底层原理，不想听，卫道士赶紧右上角别给我添堵。
这里楼主抛砖引玉的拿出三个设想，分别对应了物品的自定义、界面布局的自定义、以及更加简洁的监听器。由于水平所限也就能这样了，希望各位巨头dalao能提提意见。
设想1 —— 物品的自定义
其实这个大多数插件都已经实现，不就是将name和lore存进配置文件？是的。但是关于Path的书写，有几个约束必须遵守，我先上一个示例文件:
复制代码 name和lore大家都知道是怎么回事，我就不再赘述。这里我提出第一个约束：路径域与名称的额统一性。
我建议大家在插件中写一个Map，储存着我们插件中所需要使用的全部用于界面显示的ItemStack，Map中的key，就是这个物品在配置文件中的Path（路径），比如上面这个物品的key就是“Advanced.CONFIRM_LEVELUP_BUTTOM”。
这个约束的意义待会再讲。
设想2 —— 界面布局的自定义
这个设想来自Spring中对于Bean的配置文件而来，说白了就是把我们这个Inventroy中全部的信息全都写到配置文件里，然后再插件加载的时候创建这个单例，实现对界面布局的自定义。楼主发一个实例配置文件，包含了当前Inv的大部分功能：多点点击、可以移动的物品槽以及没什么用的美化彩色玻璃板。当然你要那种抽奖的带动画效果的，我感觉你这就是钻牛角尖了，请自觉右上角（你闲着没事折腾那个CPU干啥啊，现在都简约至上，别搞的跟山寨网站似的闪闪闪行不？看见这类东西脑子里第一个念头绝不是技术多高，而是：握草，啥玩意儿啊），这类问题不属于本文讨论范围。
复制代码 这里title和size我就不说了，说说其他的
items 这一项我们可以理解为：当前界面需要使用的物品，至于这个物品是什么样的，能不能拿下来，点击了有什么效果我们不需要担心（暂时），我们只需要给他指定一个key，我这里写的是#*+，你完全可以随意，英文字母、数字都可以（但是英文冒号还有一些奇葩符号就别用了，原因你懂的），格式就是“你指定的符号:Path”。根据我们对物品名称的约束，我们可以在这里使用物品配置文件里的Path直接指代一个物品，比较直观，也比较方便。
layout意味布局，相信大家一看这个就明白了（跟自定义合成的实现方式差不多），这个例子就是4行玻璃板，每一个符号代表一个物品格子。这里需要注意别作死，size写54那就是6行，45那就5行。
submit意为我们这个界面中具备点击效果的那个按钮的位置，这个仅仅做一个标记方便插件识别
tack_1和tack_2是可以自己放上或是拿下物品的格子。
当然，大家可能发现这个方案具有几个局限性：万一我有多个物品槽怎么办？万一我有多个按钮怎么办？这里需要大家注意，我们写的是仅仅适用我们自己插件的界面，配置文件怎么读，完全看你的解析类怎么写。你想多按钮，多物品槽，只需要让你的类支持即可。Spring的约束更多，你咋还在用？
设想3 —— 更加简洁的点击监听器
这里也是我最想吐槽的一个地方。现在很多的插件，不管作者水平高低，只要是涉及到事件监听，里面必定包含巨大的if语句块或是switch语句块。当然，也不是说这么写就是错的，但是话说这样可读性基本为0，以后你想维护你自己都会头大。成因是多样的这也不太方便说，但是相信大家都有数。Java说万物皆对象，既然我们在上面把Inv已经单独封装了对象，那点击它的效果肯定也是对象中的东西。这个设想就是这么来的。
我们在Listener不对动作本身进行处理，而仅仅是从内存中找出这个需要对这个动作做出响应的Inv对象，至于哪里可以点，哪里不能点，哪里是进行下一步的按钮，哪里的东西是可以拿下来的...这些所有的所有你实现了上面那个MineInventory接口，愿意怎么写就怎么写。这样不仅简化了具体的监听器方法，还让代码的可维护性上了一个档次（主要是好看）。你们是不知道我汉化国外那个躲猫猫，几次都气得我差点放弃了，写成那样还卖那么贵......
其实这篇文章楼主并不想把这个话题锁死，这也是我为什么不上代码的原因，仅仅是给大家提供一种思路，具体的实现方式完全可以自己完成。也就是说这也就仅仅是个架子，具体的内容，包括各种约束的细节实现以及对配置文件的解析，容错等每个几乎都没说，楼主私下写了两种实现，但是首先因为本身水平有限发上来丢人，再就是怕看了我的代码反而不利于其他人表达自己的想法（而且这都是基本的操作手段，要是自己写不出来干脆先学基础算了）。当然真有想要的可以私信我或联系我的扣扣，这个插入代码炸了好几次了，要是代码又不全了就私聊我吧....简直了
什么？你插件的界面是死的？Low不Low？
问题提出：MC服务器相关的插件不计其数，功能各异，其中部分插件由于各种原因需要借用Inventroy界面来实现使用“点点点”来代替传统的命令操作。当然使用界面本身比命令高大上一些，而且对于某些操作来说也更加简便。但是这用到的界面九成九都是死的，作者写成什么样，打开就是什么样，简直low到掉渣。当然，目前有两个解决方案：
1. 改源码（改完了还不是死的？我要改个定价都费劲，再说有多少腐竹懂怎么改？）
2. 借助BossShop，把我们的全部操作都用命令实现（那这个插件还是比较厉害的，就是写起来费劲）
相信99%的腐竹都想过就像改配置文件那么简单就可以修改插件内置的GUI界面。这里必须要注意：
1. 下面的全部方式不是要实现像BossShop那样高度自定义的界面，仅仅是实现让腐竹通过修改配置文件修改插件内置的Inventroy。
2. 牢记这个核心接口，后面有用：
- interface MineInventory {
- Inventory getInv();
- void onClick(InventoryClickEvent event);
- }
本文是来探讨一种可以使用配置文件来达到完全控制Inv（性能以及美观上还算能过得去）的方案，不讨论各种高深的Java知识，也别跟我说什么框架接口底层原理，不想听，卫道士赶紧右上角别给我添堵。
这里楼主抛砖引玉的拿出三个设想，分别对应了物品的自定义、界面布局的自定义、以及更加简洁的监听器。由于水平所限也就能这样了，希望各位巨头dalao能提提意见。
设想1 —— 物品的自定义
其实这个大多数插件都已经实现，不就是将name和lore存进配置文件？是的。但是关于Path的书写，有几个约束必须遵守，我先上一个示例文件:
- Advanced:
- CONFIRM_LEVELUP_BUTTOM:
- name: ''
- lore:
- - ''
- - ''
我建议大家在插件中写一个Map，储存着我们插件中所需要使用的全部用于界面显示的ItemStack，Map中的key，就是这个物品在配置文件中的Path（路径），比如上面这个物品的key就是“Advanced.CONFIRM_LEVELUP_BUTTOM”。
这个约束的意义待会再讲。
设想2 —— 界面布局的自定义
这个设想来自Spring中对于Bean的配置文件而来，说白了就是把我们这个Inventroy中全部的信息全都写到配置文件里，然后再插件加载的时候创建这个单例，实现对界面布局的自定义。楼主发一个实例配置文件，包含了当前Inv的大部分功能：多点点击、可以移动的物品槽以及没什么用的美化彩色玻璃板。当然你要那种抽奖的带动画效果的，我感觉你这就是钻牛角尖了，请自觉右上角（你闲着没事折腾那个CPU干啥啊，现在都简约至上，别搞的跟山寨网站似的闪闪闪行不？看见这类东西脑子里第一个念头绝不是技术多高，而是：握草，啥玩意儿啊），这类问题不属于本文讨论范围。
- LEVELUPINV:
- title: '这里是标题'
- size: 54
- items:
- - '#:上面定义的物品Path，假设这里的Path代表了一个蓝色玻璃板'
- - '*:上面定义的物品Path，假设这里的Path代表了一个绿色玻璃板'
- - '+:上面定义的物品Path，假设这里是个按钮'
- layout:
- - '#########'
- - '*********'
- - ''
- - ''
- - '*********'
- - '####+####'
- submit: 49
- tack_1: 1
- tack_2: 2
items 这一项我们可以理解为：当前界面需要使用的物品，至于这个物品是什么样的，能不能拿下来，点击了有什么效果我们不需要担心（暂时），我们只需要给他指定一个key，我这里写的是#*+，你完全可以随意，英文字母、数字都可以（但是英文冒号还有一些奇葩符号就别用了，原因你懂的），格式就是“你指定的符号:Path”。根据我们对物品名称的约束，我们可以在这里使用物品配置文件里的Path直接指代一个物品，比较直观，也比较方便。
layout意味布局，相信大家一看这个就明白了（跟自定义合成的实现方式差不多），这个例子就是4行玻璃板，每一个符号代表一个物品格子。这里需要注意别作死，size写54那就是6行，45那就5行。
submit意为我们这个界面中具备点击效果的那个按钮的位置，这个仅仅做一个标记方便插件识别
tack_1和tack_2是可以自己放上或是拿下物品的格子。
当然，大家可能发现这个方案具有几个局限性：万一我有多个物品槽怎么办？万一我有多个按钮怎么办？这里需要大家注意，我们写的是仅仅适用我们自己插件的界面，配置文件怎么读，完全看你的解析类怎么写。你想多按钮，多物品槽，只需要让你的类支持即可。Spring的约束更多，你咋还在用？
设想3 —— 更加简洁的点击监听器
这里也是我最想吐槽的一个地方。现在很多的插件，不管作者水平高低，只要是涉及到事件监听，里面必定包含巨大的if语句块或是switch语句块。当然，也不是说这么写就是错的，但是话说这样可读性基本为0，以后你想维护你自己都会头大。成因是多样的这也不太方便说，但是相信大家都有数。Java说万物皆对象，既然我们在上面把Inv已经单独封装了对象，那点击它的效果肯定也是对象中的东西。这个设想就是这么来的。
我们在Listener不对动作本身进行处理，而仅仅是从内存中找出这个需要对这个动作做出响应的Inv对象，至于哪里可以点，哪里不能点，哪里是进行下一步的按钮，哪里的东西是可以拿下来的...这些所有的所有你实现了上面那个MineInventory接口，愿意怎么写就怎么写。这样不仅简化了具体的监听器方法，还让代码的可维护性上了一个档次（主要是好看）。你们是不知道我汉化国外那个躲猫猫，几次都气得我差点放弃了，写成那样还卖那么贵......
其实这篇文章楼主并不想把这个话题锁死，这也是我为什么不上代码的原因，仅仅是给大家提供一种思路，具体的实现方式完全可以自己完成。也就是说这也就仅仅是个架子，具体的内容，包括各种约束的细节实现以及对配置文件的解析，容错等每个几乎都没说，楼主私下写了两种实现，但是首先因为本身水平有限发上来丢人，再就是怕看了我的代码反而不利于其他人表达自己的想法（而且这都是基本的操作手段，要是自己写不出来干脆先学基础算了）。当然真有想要的可以私信我或联系我的扣扣，这个插入代码炸了好几次了，要是代码又不全了就私聊我吧....简直了
本帖最后由 言灵乀Poison 于 2017-5-24 07:03 编辑
中的
建议删掉
开地图炮误伤太严重
个人认为除了小部分不需要增加类来增加代码复杂度的，其它没有深刻理解面向对象的，不能算Java的高水平作者
这里也是我最想吐槽的一个地方。现在很多的插件，不管作者水平高低，只要是涉及到事件监听，里面必定包含巨大的if语句块或是switch语句块。
中的
不管作者水平高低
建议删掉
开地图炮误伤太严重
个人认为除了小部分不需要增加类来增加代码复杂度的，其它没有深刻理解面向对象的，不能算Java的高水平作者
本帖最后由 andylizi 于 2017-5-31 19:15 编辑
我的一个弃坑了的小游戏插件。
设置自定义 Inventory 部分：
监听器部分：
（当然啦，这是一年多前的作品了。现在知道使用 Java 8 的 lambda 与函数式接口后，代码还可以简洁好多）
勿开地图炮。
我的一个弃坑了的小游戏插件。
设置自定义 Inventory 部分：
监听器部分：
（当然啦，这是一年多前的作品了。现在知道使用 Java 8 的 lambda 与函数式接口后，代码还可以简洁好多）
勿开地图炮。