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

设计一个小框架考虑的东西真不少，每一样都不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中是否存在文本命令对象是否支持后继非文本消息处理，然后调用此对象继续处理。

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