search JMRI:

LogixNG

• LogixNG overview
• Package structure
• The Categories enum
• Create Expressions, Actions, and so on
• Sockets
• Plugins for LogixNG
• Unit testing of LogixNG

Development tools

• Getting the code via Git
• Developing with JMRI Code
• Git FAQs
• Building with:
  • Ant
  • NetBeans
  • Eclipse
  • IntelliJ IDEA

Code Structure

• Introduction
• Names and Naming
• Application Structure
• Code Structure Patterns
• Swing Structure
• External Connection Structure
• Application Preferences
• Threading
• Use of XML
  • XML Schema
  • XSLT Formatting
• Web Site
• Javadocs
  • Name Index
  • Packages
  • Classes

Techniques and Standards

• Recommended Practices
• Continuous Integration
• Internationalization
• Logging & Error Handling
• Unit testing with JUnit
• Documentation with Javadoc and UML
• Run the SpotBugs static analysis tool
• Providing help with JavaHelp
• Portable Filename Method
• XML Persistance

How To

• Extend JMRI
• Add a New System
• Add a New Type

Functional Info

• Turnout Feedback
• Network Connections
• How the startup scripts work
• LogixNG

Background Info

• Technology Roadmap
• Survey of JVM Capabilities
• Usage Poll, Spring 2007

LogixNG - Plugins for LogixNG

LogixNG has gone thru big changes and the code for plugins is not up to date.

Plugins for LogixNG

JMRI supports extending JMRI in several ways by adding a jar file with classes to the JMRI class path. But LogixNG is stored in the panel xml files and these are validated when they are loaded, so when adding native expressions and actions, the logixng xml schema must be updated.

JMRI_LogixNG_Plugins is an example project with some expression plugins and action plugins. The project has Javadoc. The file JMRI_LogixNG_Plugins.jar is the current version of the plugin. The classes in JMRI_LogixNG_Plugins are not considered useful but intended to demonstrate the possibilities with LogixNG. For example, ExpressionBlink and ActionHideAndShowPanel can be used to repeatedly hide and show a selected panel. It has no prototypical usage but can be used to play a joke with a fellow model railroader...

Implementing an expression or action plugin

In order to be able to save the configuration of the plugin in the panel XML files, the plugin saves and restores the configuration in a Map<String, String>. The developer of the plugin decides on how to store its configuration in this map.

An expression or action that is a plugin must implement the ExpressionPlugin or the ActionPlugin. These interfaces has three additional methods.

init()

Initializes the plugin. This method is called after an instance of the plugin is created if there exists a configuration. Note that this method is not called the first time an instance has been created, before it has been configured by the configurator.

getConfig()

Returns the configuration for this plugin to be stored in for example a panel file.

getConfiguratorClassName()

Returns the class name of the configurator class. In order to be able to use the plugin in a headless environment, the plugin itself is recommended to not use any swing code. This method is called then this plugin needs to be configurated and a class is needed that can configure this plugin. That class needs to be in the same jar file as this plugin and it needs to implement the PluginConfiguratorInterface. One configurator class may be the configurator for many plugins.

The PluginConfiguratorInterface interface

A class that is able to configure one or many plugins is called a configurator. It generates a JPanel with the controls that are needed to configure the plugin.

The PluginConfiguratorInterface interface has these methods.

getConfigPanel()

Returns a JPanel that can configure this plugin.

getConfigFromPanel()

Returns the configuration for this plugin to be stored in for example a panel file.

Plugin in the JMRI classpath

JMRI can automaticly load plugins in the JMRI classpath. That is done by implementing a LogixNGPluginFactory that can tell JMRI about the expressions or actions and then mark it with the @ServiceProvider annotation. A single factory can register many classes. The JMRI_LogixNG_Plugins has an example.

---