rt/docs/design_docs/TransactionTypes.txt

   1 This is some loose scrabbling made by TobiX, they might eventually be relevant
   2 for 2.1.
   3
   4 INTERFACES, in general
   5
   6 should:
   7
   8 - provide the user (client?) with a list of possible actions (methods).
   9 - let the user execute those actions (methods).
  10 - Return information to the user/client.
  11
  12 There are two kind of actions/methods:
  13
  14 - Information retrieval
  15 - Transactions
  16
  17 For the first, I think the best thing is to just provide a lot of
  18 methods for it in the libraries, and let it be an Interface Design
  19 Issue what to show and how to show it.
  20
  21 For the second, I think we can win in the long run on having a
  22 generalized methods for
  23
  24 - listing transaction types.
  25 - creating & committing transactions.
  26
  27 ..with the possibility of just deploying new custom-developed modules
  28 when new transaction types are needed.
  29
  30
  31 $RT::TransactionTypes  ...and...
  32 %RT::TransactionTypes
  33    - global object which contains all TransactionTypes
  34    - used by all UIs to create menues of possible (user) actions (one TransactionType is a user action)
  35
  36 The UIs should call sth like
  37 $Ticket->AddTransaction($TransactionName), which should be equivalent
  38 with i.e.  $Ticket->Correspond when $TransactionName is 'Correspond'
  39 (AUTOLOAD should call the do-sub if exists
  40 $RT::TransactionTypes{$TransactionName})
  41
  42 The RT::Ticket::AddTransaction will create a new transaction of the
  43 right TransactionClass (maybe via a sub
  44 RT::TransactionTypes::NewTransaction).  Then $Transaction->do is
  45 called.
  46
  47 TransactionType->do initializes a new object of the right TransactionClass, and
  48