blob: 942b72371d8e04a02532354df34f37314d64cd6f (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
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
|
