• @sylan401 或许可以考虑做一个 FormObject, 譬如 UserCoursesBatch, 由他负责表单的生成,验证和保存(甚至做事务处理),这样 Controller 会非常干净,至于 form_tag 的写法,可以看作 nested form 处理。

  • 枚举

  • 显卡驱动?我遇到过类似的问题。

  • 实时插入排名的设计 at 2013年05月22日

    ranked model 提供了不错的算法

  • @xds2000 这个嵌套的理由是由于 devise 系统除了公司员工还有其他的用户类别 在原系统中,我把每一个用户类别都做一个独立的 devise 对象。 在新的重构中,我尝试将所有有登录权限的用户都用 STI 继承出来。把不同用户独有的属性剥离到了 account 对象中。 也就是说 advisor 有 advisor_accout,member 有 member_account

  • @xds2000 是一对多的关系。 系统有很多公司 公司 has_many 分公司 分公司 has_many 员工 考虑到新进员工可能存在尚未分配分公司的问题 所以员工和公司之间需要有一个关联

    当然这个问题如果在 controller 里面直接对 accout 进行操作会很容易。 我通过 overide“def advisors<<(advisor)”也能实现。 但是,我还是想知道一下。有没有更直接的方式。

  • @xds2000 :-),原谅我的小纠结,这个问题发生在最近的一次重构中,把一些平时没有时间验证的想法拿出来琢磨琢磨。我很好奇,有没有这种设计可能。 你的意思是把 Company 做成枚举?不行啊,这是一个多公司的系统。

  • AngularJS 大幅度简化开发 at 2013年03月29日

    @darkbaby123 在我的理解中,angualar 短期内应该不会推出关联了。因为他和 ember 基于两个不同的设计理念,一个是面向资源,另一个是面向对象。 我现在的做法是,如果纯单页应用就用 ember 做了,如果是在原项目中做部分扩展就用 Angular。

  • AngularJS 大幅度简化开发 at 2013年03月29日

    如果有关联就更好了。

  • 数据库保存为 paid_at, done_at. 以 nil?判断状态,因为初始状态为 null. 状态改变=Time.now,顺便还能得到个时间戳。

  • @Ddl1st 能解释一下这个做法吗?谢谢

  • @wuwx 你可以看一下 acts_as_taggable 的模型结构 他是 tag -> tagging <- tagger 的结构,我在上一个项目中就用借用了他的代码,再打了几个 patch,把 string basis 改成了 id basis, 其代码主要是在 core 模块中。你用 ActsAsTaggableOn::Tag.all 就能获得全部的 categories,然后就是 scope... 你也能自己通过搭多对多来做。道理和结构都是一样的。

  • 想偷懒就用 acts as taggable. category 可以看做单 tag

  • @hlxwell 两者使用场景不同,我把 rspec 当写复杂逻辑时的辅助工具。编写效率能明显提高。之前写一个支付订阅的功能想了一周还没理清思路,用 rspec 后 一个下午就都出来了。集成测试是面向 QA 和做重构保护的,在一些需求经常改动(进化)的项目中尤其重要。

  • @mjf429 slim 没有 handlebars 这个 tag, 需要在 config 里面再声明一下。 https://gist.github.com/wojtekmach/1557585

    尽管如此还是最好不要搭配 slim 和 handlebars, 要不然就用 angularjs,他和 slim 可以完美配合。

  • 做一个功能建立相应的表和类。测试通过后,再做下一个。要不然项目大了,容易乱的。

  • Rspec 跟着 Model 写。capybara 或者 cucumber 做集成测试,一般他们能把大多数的页面都覆盖掉。单独的 Views 层测试,在我的流程中意义不大。如果能倒把业务都写在 Model 层,那 Controller 测试也是没有必要的。管理工具如果小团队用 basecamp,podio,github 或者 bitbucket,如果有团队分工比较细,就架个 jira 吧。

  • mochup,把每页的效果,工作流都先确定下来。

  • 这两天被这个坑也纠缠了很久。 更干净的写法我觉得是是:

    class User attr_accessible :account, :account_attributes

    has_one :account

    accepts_nested_attributes_for :account

    after_initialize do self.account ||= self.build_account() end end

    这样就不需要在 controller 里面惦记 build 了。

  • 我最近的项目中有类似的需求 我的做法是通过角色控制用户和经理因为要考虑到用户某天升级成为经理的可能性,而特殊字段则通过 profile 实现