Au contenu principal

Documentation du Code
Outils de Développement
Structure du Code
Techniques et Standards
Comment Faire
Infos Fonctionnelles
Contexte Infos

Système d'Aide JMRI

Table des Matières Index
Glossaire FAQ *)
Des pages marqué *) sont en Anglais.

Donner à JMRI Faites un don à JMRI.org

JMRI: Mise à jour de Multi-connexions

Cette page est une liste de conseils pour adapter les systèmes (sous-répertoires jmri.jmrix) vers le nouveau format multi-système. C'est clairement un travail en cours!

Fondamentalement, vous devez obtenir toutes les variables statiques et les ()méthodes en instance hors du code. A leur place, vous mettrez des références à des procédures spécifiques d'un objet SystemConnectionMemo qui porte les références qui ont l'habitude d'être statiques.

Dans le même temps, nous faisons la mise à jour du modèle Swing, et un couple d'autres nettoyages mineurs sur le code.

Dans le répertoire du système principal

Créer une sous-classe spécifique de SystemConnectionMemo. Ce qui finira par faire tout l'initialisation gestionnaire, et transporter des références d'objet qui servent à faire par exemple des variables.

Ajouter toute ces choses

Pour chaque méthode de connexion (par exemple chaque sous-répertoire)

.

Modifier la classe ConnectionConfig pour prendre et enregistrer une référence à un objet SerialPortAdapter, et le retourner depuis la méthode getAdapter(). Aussi enlevez la métode() en instance et sa mise en Å"uvre.

    protected void setIntrucsstance() { 
        if (adapter == null) {
            adapter = new PR3Adapter();
        }
    }

Modifier la classe d'adaptateur (exemple: PR3Adapter) pour éliminer l'exemple () et sa mise en Å"uvre.

La classe configurexml/ConnectionConfigXml doit avoir une procédure ajoutée:

    protected void getInstance(Object object) {
        adapter = ((ConnectionConfig)object).getAdapter();
    }
Nous devrions sans doute le remanier plus tard, mais ceci est la forme actuelle pour veiller à ce que la bonne classe ConnectionConfig soit utilisée. Nous le laissons inchangé pour le moment pour éviter la concurrence avec les serial/network refactoring

Aussi, changez ceci

    protected void getInstance() {
         adapter= new PR3Adapter();
        }
pour ceci: 
    protected void getInstance() {
        adapter = new LnHexFilePort();
    }

Modifier la classe d'adaptateur (par exemple PR3Adapter) pour enlever l'exemple() de procédure et son application.

La classe configurexml / ConnectionConfigXml a besoin d'avoir une procédure ajoutée:


    protected void getInstance(Object object) {
        adapter = ((ConnectionConfig)object).getAdapter();
    }

Gestionnaire et Composants JavaBeans

Pour chaque gestionnaire et combinaison de Composants JavaBeans, vous devez les mettre à jour pour ne plus utiliser une instance () de méthode pour accéder au TrafficController. Passer le SystemConnectionMemo au gestionnaire pour la durée de construction est une approche recommandée, puis, si besoin est en passant par les Composants JavaBeans nouvellement créés. Qui passe la chaîne de préfixe, nom d'utilisateur pour la connexion, etc.

Le gestionnaire doit également utiliser le préfixe du système au lieu d'une seule lettre système fixée. En utilisant par exemple ". startsWith (getSystemPrefix () +"T")" est une bonne approche. Ne pas juste vérifier que le nom commence par le préfixe parce par exemple "L" et "L2" ne sont pas univoques.

Menu

Créer un sous-répertoire swing, s'il n'existe pas déjà.

Placez là le code pour faire le menu , en cas de besoin quitter une sous-classe derrière la migration. (voir jmri.jmrix.loconet.LocoNetMenu et jmri.jmrix.loconet.swing.LocoNetMenu pour un modèle)

Créer une classe de fabrique ComponentFactory dans le souspaquet swing qui peut par exemple créer le menu, et, éventuellement, les arbres, etc

Modifier jmri.jmrix.ActiveSystemsMenu pour éliminer la classe, la création de menu est automatique à partir de maintenant. ((Chaque fois que vous créer et enregistrer un * SystemConnectionMemo, vous enregistrez aussi le ComponentFactory)

Pour garder les actions de démarrage actives

(Nous allons bientôt refaire ce code bientôt)

Pour garder les choses en actions, il est préférable de convertir les sous-classes JmriPane. Temporairement, la connexion du système est alors crééz via l'utilisation de classes internes, comme jmri.jmrix.loconet.locomon.LocoMonPane$Default Cela demande aux gens de réinitialiser leurs préférences pour les actions de démarrage , boutons, etc Nous n'allons pas les faire migrer pour pour eux.