给每个user都准备一辆购物车的设定要怎么实现...
每人一辆的感觉是... 代码要跟user相关... 不对... 需求提到"不登录"也要配一辆... 这登录了才有user标记吧? 这要如何解决...
看教程, 嗯, 果然先从view代码入手. 尝试先乱写一版navbar代码
自然错啦, 至少要有个count显示总数的啦 教程版
<%= link_to "#" do %>
购物车 (<%= current_cart.products.count %>)
<% end %>
哦, 所以是又能"图片链接"到别处的代码写法耶. "link_to XXXX_path do "的格式呢! 而且那一脸理直气壮出现的"current_cart" 还要去controller里定义去, 不是内建的哈哈哈哈哈
还以为要去某个特定的model或controller定义去呢, 原来它是常用的词组, 所以去全局application controller定义. 而且全部是充满了陌生的代码呢...但能猜一些大概. 比如, 检测到没有cart就给当场create一个cart~ 也对, 这样就不用跟user有关啦! 有意思~
而且貌似这些代码中, 还将session编码塞给"购物车"当编码的. 也算是一种数据思维啦!
让购物车动起来的代码
我知道有难度, 但是我还是无法理解为什么凭空出现了这样一段像route的代码?
current_cart.add_product_to_cart(@product)
看着像自定义的routes, 但是rake routes又看不到它... (当然看不到它了, 你认真点, 它不是以path结尾的啊喂!) 它是哪里来的, 为啥能让购物车动起来啊...凭空出来的很类似的route代码是怎么回事?!
啊! 原来教程在前一步的cart model里面定义过了... 就是我很好奇"ci"是哪位大哥那里... Orz
令人困惑的navbar前端代码 path部分的代码...
写cart controller前, 教程先去写了routes, 我尝试写了routes没错. 然后去写navber的代码, 居然错了?! 不是
<%= link_to cart_path(cart) do %>
居然要是index代码的path?!
<%= link_to carts_path do %>
为什么不是单个cart啊?!!! 抓取全部carts是啥情况? 一个用户不是一个cart吗?! 想不明白...Orz
我现在超级好奇cart的controller会怎么写, 它里面应该定义哪些action呢?
然后看到教程的5-6都没有去cart controller里面定义任何action的步骤...不可能建了cart controller却不用吧? 很迷了...到底怎样?! 教程后面补上吗?!
新的困惑, 关于carts的index
我这样写居然是错的?!
<%= cart_item.quantity %>
这样写才对, why啊?! 单独在quantity的时候抛弃product是闹哪样?!
需求要求搞定购物车"总计"的显示
我想了想, 需要抓两个数据来计算, 一个是quantity一个是price. 让两个相乘就是总计的数据. 放到navbar index代码就好, 而且cart_item目前只有quantity, 所以我就跳过controller直接在navbar index里写
总计 <%= cart_item.product.quantity * product.price %> RMB
嗯, 然后还觉得感觉不错, 一跑...果然报错哈哈哈哈哈
所以我推测, 估计要去controller定义好了抓什么数据, 再定义好"相乘"为何, 然后才能直接写到前端去哈哈哈哈 既然是端午节凌晨 我决定放弃继续乱改 看了教程好早去睡 教程来了这样一段
<% sum = 0 %>
<% current_cart.cart_items.each do |cart_item| %>
<% if cart_item.product.price.present? %>
<% sum = sum + cart_item.quantity * cart_item.product.price %>
<% end %>
<% end %>
总计 <%= sum %> RMB
这段可以说是很精彩了, 对比我坑爹的试写代码, 真的看出很多值得注意的点~爽!
而且, 哦吼! 居然不是去controller写, 真的直接写前端里! 就是后来嫌难看, 被移动到helper或model去了, 但放前端是可以动的!!! 妈呀! 希望能从这个例子大概看出, 优化代码最后是被优化到helper还是model去, 决定的因素为何
应该是了解了helper跟model的职能后, 自己判断分配到哪里去吧. 比如这里, 写三个地方都能动, 但是其实应该算model的职能范畴内. 估计跟数据相关. 所以最佳办法是优化到model去.
sum += cart_item.quantity * cart_item.product.price
model的这个写法很酷炫, 展示一下哈哈哈
而且发现一个细节, 优化代码搬去model, 不是全部从helper删掉定义整段移过去model, 而是不动在helper定义的词汇! 不改名称只改名称定义的内容!! 不明觉厉!!! 我估计是『实践出真知』系列
因为实践中肯定是项目一开始丢去helper, 后续写了一段时间代码才决定把它继续优化到model去. 但实践项目中, 前端的很多代码都是用的之前helper定义的词汇了, 要一个个替换前端的相关代码, 累, 而且不能有遗漏, 更累!
一点遗漏都会报错的, 所以为了不去动前端的代码, 就只能不改动helper里面已用的词汇, 跑去改词汇的"定义内容", 让这定义的内容能指到model定义的内容 调用起来就好!
实践才是真实的力量展示啊!