Refactor #273

Refactor the Add/Edit/Delete Entry Views

Added by Pavan Rikhi over 6 years ago. Updated almost 5 years ago.

Status:NewStart date:
Priority:HighDue date:
Assignee:Pavan Rikhi% Done:


Category:Journal EntriesSpent time:-
Target version:Code Cleanup and Standardization
Easy Pickings:


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.

See 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)


#1 Updated by Pavan Rikhi almost 5 years ago

  • Priority changed from Urgent to Normal

#2 Updated by Pavan Rikhi almost 5 years ago

  • Start date deleted (04/30/2014)
  • Priority changed from Normal to High
  • Status changed from In Progress to New
  • Description updated (diff)

Also available in: Atom PDF