import rt 2.0.14

[freeside.git] / rt / docs / design_docs / TransactionTypes.txt

diff --git a/rt/docs/design_docs/TransactionTypes.txt b/rt/docs/design_docs/TransactionTypes.txt
new file mode 100755 (executable)
index 0000000..942b723
--- /dev/null
+++ b/rt/docs/design_docs/TransactionTypes.txt
@@ -0,0 +1,48 @@
+This is some loose scrabbling made by TobiX, they might eventually be relevant
+for 2.1.
+
+INTERFACES, in general
+
+should:
+
+- provide the user (client?) with a list of possible actions (methods).
+- let the user execute those actions (methods).
+- Return information to the user/client.
+
+There are two kind of actions/methods:
+
+- Information retrieval
+- Transactions
+
+For the first, I think the best thing is to just provide a lot of
+methods for it in the libraries, and let it be an Interface Design
+Issue what to show and how to show it.
+
+For the second, I think we can win in the long run on having a
+generalized methods for 
+
+- listing transaction types.
+- creating & committing transactions.
+
+..with the possibility of just deploying new custom-developed modules
+when new transaction types are needed.
+
+
+$RT::TransactionTypes  ...and...
+%RT::TransactionTypes
+   - global object which contains all TransactionTypes
+   - used by all UIs to create menues of possible (user) actions (one TransactionType is a user action)
+
+The UIs should call sth like
+$Ticket->AddTransaction($TransactionName), which should be equivalent
+with i.e.  $Ticket->Correspond when $TransactionName is 'Correspond'
+(AUTOLOAD should call the do-sub if exists
+$RT::TransactionTypes{$TransactionName})
+
+The RT::Ticket::AddTransaction will create a new transaction of the
+right TransactionClass (maybe via a sub
+RT::TransactionTypes::NewTransaction).  Then $Transaction->do is
+called.
+
+TransactionType->do initializes a new object of the right TransactionClass, and 
+