A Ruby gem that provides a declarative interface for exposing model objects in Rails controllers and mailers.
Decent Exposure is a Ruby gem designed for Ruby on Rails applications that provides a declarative interface for exposing model objects in controllers and mailers. It eliminates repetitive finder and builder logic by allowing developers to define model exposures with a simple macro, automatically handling ID lookup, parameter building, and object decoration. The gem aims to make Rails controllers cleaner, more readable, and easier to maintain by abstracting common patterns into a configurable DSL.
Rails developers building conventional web applications who want to reduce controller boilerplate and improve code clarity. It's particularly useful for teams following RESTful design patterns and looking to standardize model exposure logic across controllers.
Developers choose Decent Exposure because it dramatically simplifies controller code by replacing imperative find/build logic with a declarative API. Its customizable workflow, support for lazy evaluation, and compatibility with Rails mailers offer a flexible yet convention-over-configuration approach that integrates seamlessly into existing Rails projects.
A helper for creating declarative interfaces in controllers
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Replaces verbose finder and builder patterns with a simple `expose` macro, as shown in the example controller, drastically cutting down on repetitive boilerplate code.
Offers extensive options like `find_by` for slug-based lookups and `scope` for custom queries, allowing adaptation to various use cases beyond standard Rails conventions.
Supports lazy evaluation with `expose` to avoid unnecessary database queries, and eager loading with `expose!` via a before filter, enabling performance tuning based on action needs.
The `exposure_config` method allows saving and reusing exposure settings across multiple controllers or mailers, promoting DRY code and consistency in larger projects.
Extends the same DSL to Rails mailers, as demonstrated in the example mailer, simplifying object exposure in email templates without requiring separate setup or patterns.
The abstraction layer can obscure the flow of data retrieval and object creation, making it harder to trace issues or errors compared to explicit ActiveRecord calls in controllers.
Customizing exposures for non-standard workflows requires understanding multiple options and lambdas, which can lead to verbose and error-prone code if not carefully managed.
Heavily relies on Rails conventions like params naming and strong parameters; projects with unconventional patterns may need extensive configuration, reducing the simplicity benefits.