购物网 11.1 & 11.2

遇到不同的『业务逻辑』会需要设定相应的"合法操作", 我把这理解成一种为"流程"写代码的状况. 这情况肯定能用model设定出来, 但我很好奇model用的语法能多简练, ruby到底智能成什么样子...

11.1 有限状态机出场

之前在10.1及10.2仅解决『是否已支付』一种状态, 但后台的"订单状态"多达六种, 有时甚至更多. 如果一个个状态单独写, 估计光他们间的关联就能麻烦死. 所以出现『状态机』来救世吧.

而且还是个『有限』状态机, 说明还有无限的咯~有点意思, 有限是指哪方面有限吖?

居然是加一个gem来实现, 而且"加栏位"这件事情出现新的写法 add_index :orders, :aasm_state 很新鲜, 这是个啥? aasm_state的代码吗?

代码要更新成 event :make_payment, after_commit: :pay! do 也很有意思. 将"之前定义过的action"替换成更新的action, 但不能影响已经在前端代码里用着的"之前定义的action", 这种替换, 很贴心.

建议多跟做几次, 教程的这个部分很有意思. 一路不跳步骤扎实的学习到这里并不慌耶!!! 只会体验到学新东西长见识的喜悦!!! 恭喜!!!

11.2 难点开始咯!

建立 admin/orders 可以看到系统内所有订单

上来居然要完成这个... 对哦! 不搞个页面平台, 前端如何操作这些状态哦

我自信满满的开写, 然后在controller的定义上栽跟头了... 来自教程的打脸

哦, 我误解了代码的意思, 这里的单数形式的order 不是 "名词" 而是 动词. 我推测Order.order("id DESC")的意思是"将所有的订单们按照括号里的顺序排序"的意思.

然后前端的代码有出现了 order.created_at.to_s(:long) 尝试了一下 order.created_at 看到不同之处果然只是"时间的呈现格式"不同而已.

建立后台订单页面

我就自己又去先写了一版, 嗯...错了 教程打脸

嗯...我觉得我误会了第二行的意图...但真正的意图又是啥呀?

后台的订单可以依照“按照状态图”改变状态

啊, 原来要开始实作11.1初步定义了的action们. 而且...居然这些action进一步的具体定义已经在order model定义好了, 在定义aasm的时候就写好了!!!

再一次体会到, controller就要用"直白的语言"把action定义了好方便给前端用. 这一步做的就是这事, 把"代码语言变成人类语言"好给前端用. 这其实很方便协作啊~

新增异动订单状态的按钮

我猜这部分重点应该是前端设计. 并不是自己单开一个页面 (当然了, 一个页面上只有按键们像什么话!) 而是开一个partial页面, 把按钮都写partial页面里面 (哦! 机智! 这样可以随时插上拔掉)

在show页面代码里面写一大堆按钮的代码估计也比较丑. 用partial好啊, 学了一招.

但我发现要开partial写"按钮"的瞬间, 困惑着这页面开出来后, 直接硬核的开写按钮代码吗? 比如直接开始写六七个

    <div>
        <%= link_to(XXX, XXX_path, class:"btn btn-danger") %>
    </div>

这样吗?

教程果然打脸了...而且还挺狠的...妈呀都是没见过的新办法...Orz 嗯, 不对, 是之前用过的"分情况显示"代码, 不过这次是"前端代码"的格式而已!

最后用partial的 <%= render "admin/orders/state_option", order: @order %> 里面的 order: @order 还是让我困惑了...介是嘛?!

用户取消订单

我看到这个需求, 第一个想到的就是前端设计个按钮就够咧? 但也要像后台一样建个partial吗? 嗯, 看需求吧?

嗯, 教程打脸, 不只是我推测的前端view加个简单的btn就好. 而是要从controller开始定义起来...

从代码中看出这绝对是个业务需求, 用户要取消订单仅需通知商家"申请取消订单", 然后商家再决定是否从后台给予退款or退货处理. 所以业务逻辑上来讲, 这所谓的"取消按钮"根本不需要任何实在的"改变订单状态"的功能, 唯一需要通知商家的功能就够.

这波以为挺简单的定义, 还是很值得反复实作, 前端的代码以及mailer里的定义有趣.

在出货/取消订单后，系统应该寄出通知信

这部分应该只是mailer的设定吧?

看教程发现并不是...controller里还要补上相关的action定义...唉...