See #892 for a detailed proposal of these changes. I will be opening several PRs to achieve the final state so there is a semi-readable history of the changes.
Part 2 renames Transaction::Category to Category and moves all of the routes, controllers, etc. to the top-level namespace.
This thins out the hierarchy and will make it much easier to deal with categories in the final stage of this namespace update when we start implementing various types of transactions (some of which may not be valid with a category).
Future considerations for Category
While a Category generally applies to a Transaction (hence why it was originally namespaced), we have had several feature requests asking to be able to apply categories to the Account.
By moving to the top-level namespace, we'll be able to use STI (instead of namespacing—lots of duplication) to model out different types of categories:
class Category < ActiveRecord::Base; end
class TransactionCategory < Category; end
class AccountCategory < Category; end
From a field-level perspective, a TransactionCategory and AccountCategory has nearly the same exact attributes (i.e. name, color), making it a good candidate for this type of inheritance. We can then use the type to help delineate the management of these family-defined categories in the UI.
See #892 for a detailed proposal of these changes. I will be opening several PRs to achieve the final state so there is a semi-readable history of the changes.
Part 2 renames
Transaction::CategorytoCategoryand moves all of the routes, controllers, etc. to the top-level namespace.This thins out the hierarchy and will make it much easier to deal with categories in the final stage of this namespace update when we start implementing various types of transactions (some of which may not be valid with a category).
Future considerations for
CategoryWhile a
Categorygenerally applies to aTransaction(hence why it was originally namespaced), we have had several feature requests asking to be able to apply categories to theAccount.By moving to the top-level namespace, we'll be able to use STI (instead of namespacing—lots of duplication) to model out different types of categories:
From a field-level perspective, a
TransactionCategoryandAccountCategoryhas nearly the same exact attributes (i.e.name,color), making it a good candidate for this type of inheritance. We can then use thetypeto help delineate the management of these family-defined categories in the UI.