Refactor the Add/Edit/Delete Entry Views
|Assignee:||Pavan Rikhi||% Done:|
|Category:||Journal Entries||Spent time:||-|
|Target version:||Code Cleanup and Standardization|
These are way too long and handle things that are out of the scope of a view(many things can be done in forms instead).Things like:
- Setting an Entrys updated_at on form init instead of in the view
- Translating Transaction balance_deltas to credit/debit/amounts
- Setting initial values such as date, amounts, accounts, etc.
Long procedures that cannot go into Forms should be split into abstraction-specific functions.
Try to move as much manipulation into forms, managers, and models as possible. The scope of views is the request/response cycle, not specific calculations or processes.
core.views for the abstracted
ApprovableEntryView used with trips and credit cards. Best method is probably to abstract the approvable bit out and create a parent class for that and bank entries, then a common class between that a general entries. So something like:
BaseEntryView -> (GeneralEntryView, SingleAmountEntryView) SingleAmountEntryViw -> (BankEntryView, ApprovableEntryView) BankEntryView -> (BankReceivingView, BankSpendingView) ApprovableEntryView -> (CreditCardView, TripView)