Rails3 Admin UI框架

时间:2012-11-15 23:25:48

标签: ruby-on-rails ruby architecture activeadmin

我们很快将在一个全新的Rails 3应用程序中重新编写一个5年历史的rails应用程序,它具有非常不完善的代码基础,具有全新的热点。当前的应用程序有一个实质性的自定义管理UI后端,完全取决于现在的管理框架。只是一些基本控制器类和一些有用的CSS约定。但是保持UI是很多工作,特别是如果我们希望它看起来好一半。

因此,我正处于一个Admin UI框架的市场中,这将使简单的东西变得微不足道,但是无法在形式和功能方面获得更复杂的自定义。

顶级竞争者ActiveAdmin似乎非常受欢迎,在玩了一下之后我有些担忧。它似乎声明了一个存在于单个ruby文件中的唯一DSL。这有点整洁,但它与大多数其他Rails应用程序的架构完全不同。它抽象出视图,帮助控制器,并为您提供纯粹的红宝石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作为数据库的选择会影响上述任何问题吗?

2 个答案:

答案 0 :(得分:2)

值得一提的是,在ActiveAdmin中,您还可以使用partials

创建自己的复杂表单
    form partial: 'my_form'

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

   controller do
      def edit
      end

      def index
      end
   end

答案 1 :(得分:1)

+1 for active admin,我在很多项目中使用它,包括我正在构建的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这样的网址 - 因为我已经根据访问者输入的网址设置了current_site。 - 无论如何,基本上一旦你在里面:

controller do
  puts self.inspect
end

返回实际控制器本身,例如Admin :: ChannelsController(< InheritedResources :: Base,可能不是直接的,但此时所有的IH控制器方法都应该可用)。