lwt 发表于 2019-12-8 19:39:54

好大的一个话题,来蹭个热度。

Simon.hu 发表于 2019-12-9 18:29:36

我非常理解大家的需求,但是目前我们没有找到解决方案;
在此,我把我们想到的第一个问题可困难跟大家分享一下
目前我们能想到的是,将活字格的命令能搬到服务器上去执行;
最大的问题就是如获取命令中需要的参数和值?



这些参数,我们如果在页面上,很简单,直接引用这个页面的格子就行了;
但是在服务端执行的话,这些值从哪里来?怎么来?使用活字格的人,怎么去设置才能将这些值传递到活字格的服务器上呢?

求广大格友集思广益,我完全理解大家的问题,但是我目前真的是“臣妾做不到啊~”,求大神帮忙一起~

qtcxc 发表于 2019-12-9 18:48:46

本帖最后由 qtcxc 于 2019-12-9 18:55 编辑

上面的问题,你看看是否可以,参考我另外一个帖子里面提供的一些其他系统里面实现的思路,他们将 参数或者变量另外做了一套机制保存。然后给引用使用,而不是直接放在页面里面调用页面里的格子来使用。

https://gcdn.grapecity.com.cn/fo ... 68053&extra=&page=1
下图位置开始



而活字格里面现在已经有一个地方可以做到类似的效果,像条件命令里面 下图这个地方,有活字格的 关键字 可以使用。是否扩展出一套,可以给用户自己定义 关键字并且提供关键字的值会写的机制,来实现参数/变量,然后定义的时候 可以考虑 全局变量,局部变量的控制。


像上图这类的 内容,具体实现机制 需要你们看看。他是否是在页面上的? 是否脱离了 单元格的限制。

如果是,则看看怎么可以做到 能自定义,并且 更新数据 。





Simon.hu 发表于 2019-12-10 11:21:04

qtcxc 发表于 2019-12-9 18:48
上面的问题,你看看是否可以,参考我另外一个帖子里面提供的一些其他系统里面实现的思路,他们将 参数或者 ...

你这个解决不了目前的问题的,这些只有用户的信息,自然很容易;但那些可能提交的数据呢?

我知道您可能会说类比就行了,但这个事真的是说的容易做起来难,所以希望我们一起讨论一些细节:
比如我要添加一条数据,或者更新一个数据,
但是这个数据在某些情况下,要更新另一个表中的数据,或者从另一个表中取数等等的流程,
我不知道这个怎么设置或者给提供页面给用户配置比较好
(如果我们没有很好的或者确定的设计,这个功能开发也不知道怎么做才好,所以希望咱能一起沟通一下)

qtcxc 发表于 2019-12-11 11:31:20

其实真的是类比,能实现一个,就可以实现很多个。


而你所说的更细的建议,我可能没办法提的出来,只能给出一些参考性的东西给贵公司研究。
原因是,到目前为止贵公司的数据处理机制我仍然还不是非常的清晰,甚至有很多你们已经封装的数据操作方法我也是无法了解到的,所以更无法给出这种底层的建议,如果可以非常详细的了解整个处理机制,我这里可以动员一些人员来针对性的分析看是否有突破口。

但是在没有深入了解的情况下我目前只能提供以上的参考建议。


是否应该更换思路,不是在客户端来解决这些问题,而是从降低服务器端api开发的效率上着手,或代码生成的思路 用设计器设计后,生成后端的代码的方式,实现api快速开发?

这样前端的 做法可以完全不动,而是做一套将命令转换后团api的实现方法,然后参数通过api传递给后端进行交互?

如果是用前端的方法做不到是否可以换一个思路?

这两天我们已经通过用Nginx代理的测试,确认可以让活字格的服务器兼容任何后端的语言框架的环境了。

通过Nginx代理将不同框架整合到一个域名下,可以解决跨域问题将不同的开发框架跟活字格整合在一起(可以跟php,asp ,nodejs 等一起用了)。

但是接下来开发会设计到多种技术框架而且不在一个技术体系里面的,难度成几何倍数增加。


所以最好活字格能考虑提供提高整体的解决方案。

这个问题解决了,活字格就不再局限在中小型企业的开发的场景,可以做更多的事情,成为一个平台系统。


建议可以研究 filemaker 的 server 端的dataapi
https://fmhelp.filemaker.com/docs/18/en/dataapi/

qtcxc 发表于 2019-12-11 11:33:28

这已经是涉及到架构方面的东西了,如果不是你可以定的情况下,我的建议是将问题上交给活字格的架构师,由架构师分析需求后看有什么解决方案。

Simon.hu 发表于 2019-12-11 11:52:22

是这样的,这个问题我们已经开会沟通了好多次了
目前,我们这边是了解了问题,但是没有解决方案,如果我们一直没有解决方案,那么这个问题就会被无限的延期,我想这个肯定是你我都不想
所以我在想,跟您也沟通一下,看看会不会有新想法思路~

qtcxc 发表于 2019-12-11 15:17:23

或者 你们讨论的结果可以分享一些给我参考吗?

Simon.hu 发表于 2019-12-11 17:32:29

本帖最后由 Simon.hu 于 2019-12-11 17:34 编辑

没有结果,因为大家都觉得没有没有很好的实现方法,
目前的问题是这几个帖子:
1.https://gcdn.grapecity.com.cn/fo ... peid%26typeid%3D234
2.https://gcdn.grapecity.com.cn/fo ... peid%26typeid%3D234
3.https://gcdn.grapecity.com.cn/fo ... 9439&extra=page%3D1

目前我们的方案可能都不一定能搞定呢~可能最好的做法,就是借鉴回写公式等等的做法;
但是,这些回写公式等等,很多跟活字格已有功能重复,怎么解决客户使用的时候会疑惑的问题?
或者怎么把这些机智的功能,和活字格完美的结合起来,
这个挺麻烦的~

qtcxc 发表于 2019-12-11 21:25:54

本帖最后由 qtcxc 于 2019-12-11 21:31 编辑

目前我仍然觉得 可能还是向用活字格设计器设计,然后编译成后端api的方向想。
不要用客户端做服务器该做的事情,但是需要用图形化的设计器设计后端api。

解决用活字格设计器来设计业务流程规则,然后开发一套将这些设计的流程规则转换为api的方法,生成dll文件。

原来设计器的前端的开发功能原版保留,额外再设计器扩展一套设计后端api的能力,最终输出为dll给服务器加载使用。

然后再加强客户端调取服务器api接口的能力(你们已经有了,可以继续加强配合上面生成的api使用)

其实我真想不出,怎么让前端实现后端的能力。是不是应该放弃前端实现后端能力,而是按简化后端开发的路子走?

是不是有些东西可以找其他公司合作来解决?
下面这个你看看有没有参考意义?:
http://restcloud.cn
http://apijson.org/
http://servicecomb.apache.org/cn/
http://yesapi.cn/

通过上面的这些技术中的某个,生成一套类似


这样的通用数据接口来给前端调用。

甚至,是否也可以考虑把这些接口也集成进来一起搞定:










页: 1 [2] 3 4
查看完整版本: 移动端前后端分离想法咨询可行性