活字格能不能多个模版可编辑代码模式的？

meteor · meteor

的确，这个要是加进去的话是个大改动大思路，需要对整体结构的思考需要更谨慎些。
为了表述更加清晰，换个角度把上述的假象再多啰嗦一遍哈。
从现有活字格的设计结构来区分：
A.常规的活字格系统使用者：业务设计，主要应用活字格提供的UI控件进行拖拽操作设计页面，用命令等不涉及代码的方式实现业务逻辑
B. 插件开发者：利用活字格提供的接口进行通用插件的开发，这样的插件一般不包含专属的业务逻辑，是抽象出某些具体的业务功能的实现。 A类用户使用B开发的插件时，和活字格其它UI控件一样去使用，和其它命令一样去使用即可。这样对A用户来说，只要了解了插件的适用范畴，就可以无差别的使用。
好了，以上是活字格现有的体系。因为B类对js和C#要求较高，A类使用者进入的门槛较高。所以一般是提出具体业务需求，等着活字格官方或者群里的高手大神来开发插件使用。对官方而言，如果这个业务需求太具体化，那就需要将他抽象出来，最好能抽象成一个较为通用的功能场景，因为这样的插件开发才有意义。但是一个是受限于A类用户对具体业务需求的抽象化能力不足（他们非常了解自身的业务规则，但是想要从软件高度去抽象是有点困难的），而官方去抽象，就存在资源的分配问题，以及对业务规则的理解问题（因为官方对软件抽象业务非常熟悉，但是对每个公司的具体业务逻辑不一定能一下子理解）。所以大家会看到这样的现象：论坛也好，群也好，当大家提出某个功能需求时，官方往往会追问具体的业务场景。这可不是废话，而是为了去真正理解具体的业务规则，看是否有办法通过活字格的现有逻辑进行组合，如果没办法，是否能抽象出通用的插件，排到开发进程中。
这样做理论上是成立的，对活字格的系统进化而言也无疑是一条正确的道路。但是官方的技术资源不是无限的，A类用户的等待时间也是有一定限制的，所以提出能否有第三类C类：业务组件。即A类用户通过活字格现有的UI控件以及命令等基础资料，自行拼凑出能适应极为具体的业务需求的业务组件。（如果有能力，也可以加入js代码和c#代码，构建更强大的业务组件。）这个组件能在自己的当前项目中进行复用。举个最简单的例子，比如说做个现场控制系统，其中有个UI组件是需要显示出机台组的状态，并且具有一定的操作功能，比如启动机台，关闭机台。但是这个UI组件不是独立成页面的，而是嵌入在不同的页面中。比如在机台任务管理页面的左上方，比如又在机台维护清单的页面中出现.......等等。当然，正如胡总所说，可以是做成iframe的形式，在页面进行调用。但是如果是业务组件，组件本身对页面的其它组件（元素）也存在通讯的可能，比如机台组状态组件还需要和本页面内的其它组件进行一些逻辑交互，单靠iframe实现起来就比较困难了。但是如果是活字格支持业务组件的定制，就完全可以和定义页面模板一样定义出一个业务组件（可以不需要任何代码，仅靠活字格的命令和UI控件）。比如就叫机台状态组件。然后定义组件对外的通讯，比如对外的接受的参数传入，比如对外抛出的事件通知（这个参考Vue组件的通讯机制，通过Props和emit来完成）。然后在具体的业务页面，可以使用这个业务组件，把传入的参数接入，并且可侦听组件外发的事件，以便用命令控制页面的其它UI元素或者做相应的操作。
打个比方，就像是A类用户可以组装一个汽车模型，一些通用的模型组件可以预先装配并定义好，比如两个轮子构成的轮组。在装整车的时候，可以把轮组复制两份，一组做前轮，一组做后轮，装配接口分别对上前后轮就可以了。以后轮子要改了，就改下轮组组件的定义，四个轮子就自然都换好了
当然，这个构造是很复杂的，但是一旦实现了，是不是很激动人心哈：）