微信公众平台应用开发框架sophia设计不足(1)

时间:2022-07-26 12:47:32

设计一个小框架考虑的东西真不少,每一样都不easy:

1、既要解决当前技术的不足;

2、又要方便他人使用(基本的目的)。

3、同一时候又要设计得优雅。easy扩展。

sophia一開始设计用来支持智能回复(文本能够带參数的回复)。后来又支持菜单。并统一了菜单和文本命令的处理逻辑。

再后来看到微信client的交互元素太少,又支持html页面操作和微信client的会话(即页面操作能够知道是哪个微信号操作的)

对于怎样维系两个不同类型消息(命令)之间的关系?对sophia来说有点吃力。

即,前面是一个文本(命令)。后面是一个其它类型的消息。

比方,某街道办让我们开发一个居民登记公众平台,主要流程例如以下:

1、订阅者输入:登记

2、公众平台提示:请输入姓名:

3、订阅者输入:张三

4、公众平台提示:输入身份证号码:

5、订阅者输入:xxxxxxxxxxxxxxxxxx

6、公众平台提示:请上传免冠相片:

7、订阅者上传相片。

8、公众平台提示:登记成功。

订阅者经过多次文本输入和图片上传后,公众号怎样保证前面的文本信息和最后的图片是同一个人的?

假设看了sophia的源码和设计后(參阅我前面的文章)会发现sophia无法做到?由于我一開始就把sophia设计为处理文本消息的框架。

如今,假设要解决问题,那么:

1、首先把全部的消息(文本、视频、语音、图片、地理位置等,或者说每种交互)都觉得是一种命令。让框架都有机会处理;

2、其次要改动会话管理逻辑。

插播:

消息的多样性:指同一种类型的消息。能够依据内容来解析出不同的命令,比方文本消息具有这个特性。

像图片无法解析出不同的内容,所以没有多样性(用图像识别、语音识别技术除外)。

这个概念会影响我们的设计。

1、因为文本消息具有多样性,其相应的命令类就能够有不同的子类型。而非文本消息,仅仅能有一个命令类,合适吗?

2、假设把非文本消息作为文本消息的特殊类型,又怎样?

初步考虑扩展将文本命令类添加一个标记(支持后继是非文本消息继续处理),假设公众平台收到非文本命令时候要检查一下session中是否存在文本命令对象是否支持后继非文本消息处理,然后调用此对象继续处理。

你有更好的方案吗?欢迎讨论。