关于重用partial的一个问题

这个问题很有意思，你不妨把你现在的代码贴出来，大家来看看可以怎么改进。

代码应该在它"应该在的位置",用helper/filter变通不太爽.
rails2已经去掉component了吗?

component的问题:
compponent要使用宿主controller的用户输入等环境,并要将输出提供给宿主controller使用.如果事先考虑这些,框架对于一次正常的请求响应的分发逻辑就要复杂的多了.
rails似乎这样实现的(为了省事?):每次render_component新建一个controller实例,将宿主环境复制一遍用做模拟运行环境,并截获其输出.
这样做的问题:
1. 每次render_component都要走一遍整个过程,CPU和内存的使用接近一次额外的WEB请求,且是顺序执行的,性能有问题. 如果里面有redirect_to,处理过程更恶心.
2. component的每个filter都会执行,这可能不是我们期望的,比如,用来准备数据的before_filter我们希望它执行,检查权限的before_filter我们期望它在宿主controller里执行一次就够了. 没办法告诉它这些信息.
3. layout

我觉得这个功能跟portlet概念是一致的,我理解Cells是来解决这个问题的,只粗看过一点,要遵循它的一套约定和类.
这玩意本来该框架内置支持,这样干还是不太自然.

merb的action是可以有参数的方法,框架能把用户输入变成方法参数值来调用action;指定输出时跟struts类似,返回标记值(该标记值对应的页面在router中定义),不像rails直接调render/redirect_to. 所以,在action中剥离了跟WEB请求相关的概念,理论上比rails更容易实现这个模块化的功能. -- 这样理解对不?具体怎么干的呢?

又抱怨了，呵呵~

这样的需求我们目前也是用helper封装partial的方法，至于功能掺杂在一起的问题，没办法，rails没有帮我们分只能自己分，这样的city的展示可以看作jsp的tag或者freemarker的macro，统一抽到一个tag_helper，里面的方法格式都是 tag_xxxx，例如

  def tag_token(form_id, display=false)
    render(:partial => "#{PARTIAL_PATH}token" , :locals => { :form_id => form_id, :display => display})
  end

把查询封装成为model的一个方法不就行了吗，在partial里面直接调用model的该方法。搞不明白怎么讨论了那么多页。

没有那么简单
比如说要根据5个不同的model的信息来装配一个calendar，里面有些日期是高亮可选的，其他的日期是不可选的

会初始化就会更新,如果Cities使用频繁可能考虑放入Cache里,不管多少个进程,用类似QueryCache方式去处理,我想不会因为多少个进程就加载多少次吧?

不好看，以为着把C的职责强行加给V，而且一旦业务逻辑复杂，一个model根本不能满足，很有可能需要一个service层，这样的话，在view里面直接调service？

放在helper里只是一种变通的方法。

我还真写过calendar，部分写在helper里，部分写在model……

张元一的一篇blog, Engines，Generator以及Rails插件机制:
http://www.letrails.cn/archives/engines-generator-and-rails-plugin-system
跟这个话题类似

我不知道理解是不是有错，之前遇到过需要在partial里面传递大量的参数的时候，采用了下面的做法：

render :partial_with_locals => '/partials/xxx' do |locals|
   locals.param1 = 'xx'
   locals.param2 = 'yy'
end

:partial_with_locals是对 ActionController::render做的hack，其实就是处理一下block,重新调用partial而已。封装成plugin，扔到plugins下面。
当时的目的只是为了避免出现 locals => { :param1 =>  xx,   :param2 => yy ....}很长的参数而已。现在想来这个block里可以封装一点点逻辑，减轻partial的负担。

不知道跟lz说的是不是一个东西。