Documentaion changes to give dev guidance on system-specific hw config
The recent pull-request associated with the new "ipocs" system possibly
makes this question timely.
My read of html/doc/Technical/Patterns.shtml gives two relevant sections
that relate to system-specific Bean properties.
First, from the "Bean properties" section:
"The available Bean properties are defined in the abstract base class
usually, for example AbstractTurnout defines "CommandedState", "KnownState",
"feedbackchange", "locked" and some more at the time of this writing. These
properties are not system-dependent."
I _infer_ from this quote that "Bean properties are not system-dependent".
Is that inference correct? If so, the text could be made more obvious (and
The second, from "System-specific properties" section:
Later in that same web page is a section called , which states:
"Adding a system-specific property requires using a generic API, because the
code in the jmrit.beantable package cannot depend on the
This quote seems to bolster my inference about the first quote. Perhaps any
effort to clarify/strengthen the info in the "Bean Properties" section
could provide a link to this section for "addition of system-specific
Hi Bob M,
The core bean properties in their abstract classes are not system dependant.
You can have system-specific bean properties, see uses of the generic API, jmri.NamedBeanPropertyDescriptor for how this works.
Currently developing CBUS Reporters to select various RFiD formats :-)
Perhaps you should propose some text? “These properties are not system-dependent” seems to be me to be the clearest possible statement that they’re not system-dependent. But there might be a clearer way, or you might see something confusing that I don’t.
On Sep 10, 2020, at 12:40 PM, Bob M. <jawhugrps@...> wrote:—