Rails3 管理 UI 框架

Question

我们很快将重写一个使用了 5 年的 Rails 应用程序，它的代码基础非常不完善，从头开始在一个全新的 Rails 3 应用程序中使用所有新的热点。当前的应用程序有一个大量的自定义管理 UI 后端，它完全依赖于现在的管理框架。只是一些基本的控制器类和一些有用的 CSS 约定。但是维护这个 UI 需要做很多工作，特别是如果我们希望它看起来不错。

所以我在市场上寻找一个 Admin UI 框架，它可以让简单的东西变得微不足道，但不会在形式和功能上获得更复杂的自定义方式。

顶级竞争者ActiveAdmin 似乎很受欢迎，玩了一会儿之后我有些担心。它似乎声明了一个存在于单个 ruby​​ 文件中的完整唯一的 DSL。这有点简洁，但它也与大多数其他 Rails 应用程序的架构方式完全不同。它抽象了视图、控制器的助手，并为您提供了一个纯 ruby​​ DSL。在我看来，这会妨碍我们在管理视图中做一些棘手的事情，更高级的自定义事情。 DSL 很棒，除非您想做一些他们不明确支持的事情。

我的实验中的“资源”示例，没有控制器也没有视图。

ActiveAdmin.register Region do
  menu parent: "Wines"

  show title: :name

  index do
    column(:zone) { |o| link_to o.zone, admin_region_path(o) }
    column(:name) { |o| link_to o.name, admin_region_path(o) }
    default_actions
  end  
end

所以，问题：

1. 是不是基于标准Rails MVC架构在单独的文件中，以及管理区域的典型控制器继承实现，实际上我应该关心什么？从长远来看，它会妨碍可扩展性吗？
2. ActiveAdmin 中的 DSL 是否比我认为的更好、更灵活？
3. 我是否应该考虑其他一些更适合我的高度定制目标的框架？
4. 我应该停止懒惰并自己动手吗？
5. 选择Mongoid 而不是MySQL 作为数据库是否会影响上述任何问题？

Answer 1

值得一提的是，在 ActiveAdmin 中，您还可以使用 partials 创建自己的复杂表单

    form partial: 'my_form'

并使用控制器块扩展控制器功能。

   controller do
      def edit
      end

      def index
      end
   end

Answer 2

+1 用于活动管理员，我在许多项目中使用它，包括我正在构建的 cms。它确实比许多新使用它的人认为它更灵活，在一天结束时你总是可以做到：

controller do
  def custom_action
    Puts "hi"
  end
end

（认为这是从手机上写的正确语法，所以这一切都在脑海中）

另外，我发誓继承资源，活动管理控制器扩展了这些资源，因为它们确实（以一种很好的方式）迫使你编写宁静的、可重用的代码。底线是我相信活跃的管理员在我尝试过的其他人（railsadmin 和至少其他人）之前取得了飞跃式发展

更新： 当然，这里是inherited_resources 文档

https://github.com/josevalim/inherited_resources

这是一个直接修改控制器的示例，来自我的小 CMS 项目。

ActiveAdmin.register Channel do

  index do
    column :title
    column :slug
    column "Fields" do |channel|
      "#{link_to('View Fields', admin_channel_entry_fields_path(channel))}    #{link_to 'Add Field', new_admin_channel_entry_field_path(channel)}".html_safe      
    end  
    column "Actions" do |channel|
      "#{link_to('View Entries', admin_channel_entries_path(channel))}    #{link_to 'Create Entry', new_admin_channel_entry_path(channel)}".html_safe
    end
    default_actions
  end

  form :html => { :enctype => "multipart/form-data" } do |f|
    f.inputs "Channel" do
      f.input :title
      f.input :display_name
      f.input :image
    end
    f.buttons
  end

  controller do

    def begin_of_association_chain
      current_site
    end

    def tags

      query = params[:q]
       if query[-1,1] == " "
         query = query.gsub(" ", "")
         ActsAsTaggableOn::Tag.find_or_create_by_name(query)
       end

       @tags = ActsAsTaggableOn::Tag.all
       @tags = @tags.select { |v| v.name =~ /#{query}/i }
       respond_to do |format|
         format.json { render :json => @tags.collect{|t| {:id => t.name, :name => t.name }}}
       end

    end

  end

end

基本上，我使用继承的资源 begin_of_association_chain 方法（我最喜欢的关于 IR 的方法之一）将频道内的所有数据或从我的频道资源继承的任何管理资源限制到当前站点，没有像 /admin/sites/1/channels 这样的 url——因为我已经根据访问者输入的 url 设置 current_site。 -- 无论如何，基本上一旦你在里面：

controller do
  puts self.inspect
end

返回实际的控制器本身，例如Admin::ChannelsController（其中