Week 15 - June 11
会议内容
1、前端与服务器的一些交互细节：
① 登录的时候post当前桌号以及当前用户的id（微信号），返回一个key标识用户，用于后面的post个人订单到cache；
② post个人订单时，除了post用户点的菜品信息，还要post用户key，后台根据key来检索/存放用户的点餐情况；
③ 某桌用户提交订单时，根据该桌的用户id（key）数和每个用户的个人订单，merge成该桌的一张全部顾客的订单；
④ 支付订单时才清空cache；
2、关于更新cache里的个人订单
- plan A：每点击一次菜单的添加/减少按钮，就上传一次个人订单，
点击跳转到订单页面时，由于需要实现多人点餐，实时看到同一桌的所有用户的点餐情况，需要get存放在cache里的每个用户的个人订单，
并启动计时器，每隔一段极短的时间就get一次全部cache里的订单
-
plan B：每隔一段极短的时间所有用户get一次cache里的订单（不论在哪个页面）
-
plan C：考虑微信小程序有无像flux一样的共享一个状态的组件
暂定为plan A
3、考虑添加历史订单和评论功能
-
历史订单功能：后端只需根据微信号在每一个order表里查询有无该id，并返回order信息；前端需要考虑UI问题，功能入口放在哪里
-
评论功能：不需记录用户信息，只显示评论文字和图片
4、下单与支付
- 先下单，再支付；
- 若已下单但未支付，订单页面的已有菜品只能添加，不能减少，可以添加新的菜品；
- 支付后购物车和cache都清空
5、订单页面多人点餐的UI
订单页面分用户显示，当前用户只能修改自己的订单，不能修改其他用户的订单
6、之前的api端口更换为8080端口
7、前后端成员分别展示自己目前为止的工作
8、考虑商家管理系统如何接入
【补充】：
在6.13晚上进行了线上会议：
- 商家系统的前端需要调用的接口可由后台负责api的成员实现，不需要改动太多；
- 数据库方面商家与用户组后台实现工具不一致，商家系统的数据库需要改为与用户组的一致。 由于商家参考的是前期的ER模型，可能改动有点多，但是修改难度应该不大。
- 先将商家系统的代码上传，小组成员了解详细问题后一同解决。
Week 13 - May 28
会议内容
1、文档需要修改
- 根据老师的要求修改文档
2、重构代码
- 前端可以开始重构代码
- 可以把一些重复的内容写成组件
- 代码规范
- 可以参考一些网上的demo
- 后台
- 文件有些冗余
- 接口访问数据库时，若数据库为空则有bug
- 接口api修改情况
- 是否需要根据桌号生成二维码来测试，数据库是否需要为桌号建表
讨论结果：由于此小程序最终非企业号发布，只可以模拟二维码传参，但是无法生成实际二维码，暂定场景为只有一桌
Week 11 - May 19
会议内容
- api 需要根据实际修改，有些部分可以先保留，有些部分可以删除
- 数据库尽量只添加不修改
- 讨论
- 数据库中是否所有菜存储在一个表中，是否只有一个菜单【是】
- 不同时间显示不同的菜品【√】 vs 显示菜品已下架
- 管理界面用html编写，有服务员和老板界面【√】 vs 是否可以通过只提供一个excel来完成
- 多人点餐设想一：第一个人扫码时获取桌号，发现桌号状态为未点餐，创建新orderNumber，状态修改为正在点餐， 其他人再扫码时状态不是未点餐，沿用同一orderNumber
- 多人点餐设想二：同一桌的订单只需一个顾客点击确认即可提交订单，不需要该桌所有点餐的顾客都确认一遍， 一次提交把当前所有用户的已点菜品都提交
- 多人点餐设想三：同一桌的顾客可以在订单页面看到其他用户的点餐信息，未提交订单时点餐信息储存在session里， 提交订单时再交给服务器
- 可以添加一些用例和用例图等
- 尽量跟上进度