-
Notifications
You must be signed in to change notification settings - Fork 0
Feature: Multi ORM Planning
Here are some of the ideas that need to be fleshed out for Active Admin to support multiple ORMs.
When a resource is registered, it should instantiate the correct adapter for the given backend. So if an ActiveRecord
subclass is registered, it should instantiate an ActiveAdmin::ResourceAdapter::ActiveRecord
. (Note class naming is up for discussion still)
The type could also be explicitly passed in.
For example:
ActiveAdmin.register User, :type => :mongoid
Adapters will have to suppor the following:
- Retrieving a collection for the index page. Most of the features required for this are in
ActiveAdmin::ResourceController::Collection
- Sorting
- Scoping (support for the scope AA dsl method)
- Scope to (support for the scope_to AA DSL method)
- Pagination
- Search / Filtering
- Instantiate and return a new resource
- Create a new resource from params
- Find a specific resource
- This could include a scope_to or belongs_to AA relationship
- Edit a resource
Libraries can register a new AbstractAdapter subclass and should also be able to specify some logic for when it get's used.
For example:
class MyCustomAdapter < ActiveAdmin::ResourceAdpater::Abstract; end
ActiveAdmin::ResourceAdpater.register :my_custom, MyCustomAdapater do |resource_class|
# This block get's run if the user does not explicitly pass
# in the :type option. Return true from it if your adapter should be used
resource_class.ancestors.include?(ActiveRecord::Base)
end
Active Admin supports many features which may not be supported by all ORMs. Initially, the sidebar filtering comes to mind. ORMs should have a way of letting the system know if certain features are enabled on them.
For example:
class SimpleAdapter < ActiveAdmin::ResourceAdapater::Abstract
def supports_filters?
false
end
end
ActiveAdmin.register SomeObj, :type => :simple_adapter do
filter :name #=> raises an exception since this feature is not support
end