-
Notifications
You must be signed in to change notification settings - Fork 331
/
MultiConnectionUpdate.shtml
141 lines (118 loc) · 5.34 KB
/
MultiConnectionUpdate.shtml
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
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
"http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
<meta name="generator" content=
"HTML Tidy for Mac OS X (vers 31 October 2006 - Apple Inc. build 15.17), see www.w3.org">
<title>JMRI: Multi-connection Update</title>
<meta name="keywords" content="JMRI jmrix connections hardware">
<!-- Style -->
<meta http-equiv="Content-Type" content=
"text/html; charset=us-ascii">
<link rel="stylesheet" type="text/css" href="/css/default.css"
media="screen">
<link rel="stylesheet" type="text/css" href="/css/print.css"
media="print">
<link rel="icon" href="/images/jmri.ico" type="image/png">
<link rel="home" title="Home" href="/">
<!-- /Style -->
</head>
<body>
<!--#include virtual="/Header.shtml" -->
<div id="mBody">
<!--#include virtual="Sidebar.shtml" -->
<div id="mainContent">
<h1>JMRI Code: Multi-connection Update</h1>
This page is a list of hints for adapting systems (jmri.jmrix
subdirectories) to the new multi-system format.<br>
It's clearly a work in progress!
<p>Basically, you have to get all the static variables and
instance() methods out of the code. In their place, you put
references to methods of a specific SystemConnectionMemo
object that carries the references that used to be
static.</p>
<p>At the same time, we're doing the Swing pattern update,
and a couple other minor cleanups on the code.</p>
<h2>In primary system directory</h2>Create a specific
subclass of SystemConnectionMemo. This will eventually do all
the manager initialization, and carry any object references
that used to be through instance variables.
<p>Add all that stuff.</p>
<h3>For each connection method (e.g. each subdirectory)</h3>
<p>Edit the ConnectionConfig class to take and record a
reference to a SerialPortAdapter object, and to return it
from the getAdapter() method. Also, remove the instance()
method and its implementation.</p>
<pre style="font-family: monospace">
protected void setInstance() {
if (adapter == null) {
adapter = new PR3Adapter();
}
}
</pre>
<p>Edit the adapter class (e.g. PR3Adapter) to remove the
instance() method and its implementation.</p>
<p>The configurexml/ConnectionConfigXml class needs to have a
method added:</p>
<pre style="font-family: monospace">
protected void getInstance(Object object) {
adapter = ((ConnectionConfig)object).getAdapter();
}
</pre>We should probably refactor this later, but this is the
current form to make sure the correct ConnectionConfig class is
used. We're leaving it unchanged for now to avoid competition with
the serial/network refactoring.
<p>Also, change this</p>
<pre style="font-family: monospace">
protected void getInstance() {
adapter = LnHexFilePort.instance();
}
</pre>to this
<pre>
protected void getInstance() {
adapter = new LnHexFilePort();
}
</pre>
<h3>Managers and Beans</h3>For each manager and bean
combination, you have to update them to no longer use an
instance() method to access the TrafficController. Passing
the SystemConectionMemo in to the Manager at construction
time is the recommended approach, then if need be passing it
through to the newly created Beans. That passes the prefix
string, user name for tbe connection, etc.
<p>The manager must also use the system prefix instead of a
fixed, single system letter. Using e.g.
'.startsWith(getSystemPrefix()+"T")' is a good approach.
Don't just check that the name starts with the prefix because
e.g. "L" and "L2" are not unambiguous then.</p>
<h3>Menu</h3>Create a swing subdirectory, if it doesn't exist
already.
<p>Put the code for making the menu there, if need be leaving
a migration subclass behind. (c.f.
jmri.jmrix.loconet.LocoNetMenu and
jmri.jmrix.loconet.swing.LocoNetMenu for a template)</p>
<p>Create a ComponentFactory factory class in the swing
subpackage that can e.g. create the menu, and eventually the
trees, etc.</p>
<p>Edit jmri.jmrix.ActiveSystemsMenu to remove the class;
menu creation is automatic from now on. (Every time you
create and register a *SystemConnectionMemo, you also
register the ComponentFactory)</p>
<h3>Keep startup actions working</h3>
<p>To keep things working, it's best to convert to JmriPane
subclasses. Temporarily, the system connection is then
created via the use of internal classes, like
jmri.jmrix.loconet.locomon.LocoMonPane$Default</p>
<p>This does require people to reset their preferences for
startup actions, buttons, etc. We're not going to migrate
those for them.</p>
<p>To make startup actions work with more than one connection of their type,
they should implement the
<a href="http://jmri.org/JavaDoc/doc/jmri/jmrix/swing/SystemConnectionAction.html">jmri.jmrix.SystemConnectionAction</a>
interface. This will connected them to their specific
<a href="http://jmri.org/JavaDoc/doc/jmri/jmrix/SystemConnectionMemo.html">SystemConnectionMemo</a>.
<!--#include virtual="/Footer.shtml" -->
</div>
</div>
</body>
</html>