ruby-on-rails - Rails3 管理 UI フレームワーク

Question

私たちはまもなく、非常に不健全なコード基盤を持つ 5 年前の Rails アプリを、まったく新しい機能を備えた真新しい Rails 3 アプリでゼロから書き直す予定です。現在のアプリには、現在の管理フレームワークにまったく依存する実質的なカスタム管理 UI バックエンドがあります。いくつかの基本コントローラークラスと、いくつかの便利な CSS 規則だけです。しかし、その UI を維持するのは大変な作業です。

だから私は、シンプルなものを些細なものにするが、フォームと機能の両方でより複雑なカスタマイズの方法を取得しない管理 UI フレームワークを求めています。

最有力候補のActiveAdminは非常に人気があるようで、少し使ってみたところ、いくつか懸念があります。単一の ruby ファイルに存在する一意の DSL 全体を宣言しているようです。これはちょっといい感じですが、他のほとんどの Rails アプリの設計方法とはまったく異なります。ビュー、ヘルパー、コントローラーを抽象化し、純粋な Ruby DSL を提供します。これは、私たちの管理者ビューでトリッキーなこと、より高度なカスタムを行う際の邪魔になるように私には思えます。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

だから、質問：

標準的な Rails MVC アーキテクチャに基づいていないのは別のファイルにあり、典型的なコントローラの継承ベースの管理領域の実装は、実際に私が心配する必要があることですか? 長期的には拡張性が損なわれますか?
ActiveAdmin の DSL は、私が信用しているよりも優れていて柔軟性がありますか?
高度なカスタマイズの目標により適した他のフレームワークを検討する必要がありますか?
怠け者になるのをやめて、自分でロールする必要がありますか?
Mongoidデータベースとしてではなく、という選択はMySQL、上記の質問のいずれかに影響しますか?

score 2 · Accepted Answer

ActiveAdmin では、パーシャルを使用して独自の複雑なフォームを作成することもできます。

    form partial: 'my_form'

コントローラブロックでコントローラ機能を拡張します。

   controller do
      def edit
      end

      def index
      end
   end

score 1 · Accepted Answer

アクティブな管理者の +1 です。構築中の cms を含む多くのプロジェクトで使用しています。それは確かに、それを使ったばかりの多くの人が信用するよりも柔軟性があり、一日の終わりにはいつでも行うことができます:

controller do
  def custom_action
    Puts "hi"
  end
end

（これは電話から書いた正しい構文だと思うので、これはすべて頭から離れています）

また、アクティブな管理コントローラーが拡張する継承されたリソースに誓います。これは、(良い意味で) 安らかで再利用可能なコードを書くことを強制するからです。要するに、アクティブな管理者は、私が試した他の管理者 (railsadmin と少なくとも 1 つの他の管理者) よりも飛躍的に優れていると思います。

更新: 確かに、ここに 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 に関する私のお気に入りの 1 つ) を使用して、チャネル内のすべてのデータ、またはチャネルリソースから継承した管理リソースのいずれかを現在のサイトにスコープします。 /admin/sites/1/channels のような URL -- 訪問者が入力した URL に基づいて current_site を既に設定しているためです。-- とにかく、基本的に中に入ったら:

controller do
  puts self.inspect
end

実際のコントローラー自体を返します。たとえば、Admin::ChannelsController (< InheritedResources::Base、直接ではないかもしれませんが、この時点ですべての IH コントローラーメソッドが利用できるはずです)。

ruby-on-rails - Rails3 管理 UI フレームワーク

2 に答える 2

Related

Reference