ActiveAdmin with non-model POROs, form objects and service objects
By Nic Boie, September 12, 2017
A few months ago, WebVolta committed to helping maintain ActiveAdmin-Mongoid. We have been working closely with Active Admin in a large production application, and we wanted to share a pattern that we use fairly often.
Often, you want to use a form object or a service object instead of directly manipulating the model objects. This is especially true for actions that touch several models, for instance, updating an order to refund a credit card. You may already have a service object to handle that. We suggest going a step further and giving that process its ownAdmin setup without trying to hook it up to the underlying model.
Create a base class for the objects to inherit from which essentially stubs persistence methods
Inherit that class in the POROs and add relevant action methods.
Create the active admin class that handles the interface between your form object and ActiveAdmin.
Usually, you want to link the index to a model instance in admin within the application. One example of this usage is to have a page that does a form action on an incoming customer order. You need to load all of the recent orders with a specific status into this admin page, but the page must be completely separate from the normal area for viewing/modifying orders (perhaps a dashboard link).
In this scenario, you generally don’t want to use the normal new/edit/destroy methods, only a show page and perhaps an arbitrary member action. See the example below. Note that the methods that return self in the base class/concern are chained behind the scenes. You may need to store state with your including class.
Working with ActiveAdmin-Mongoid has been a wonderful experience, and we are looking forward to the upcoming release. We'd love to hear more about how you're using ActiveAdmin in your own project. If you are looking for assistance with a tough problem, reach out to us using the Contact Us form of through the comments below.