Package jmri.managers

Class AbstractLightManager

    • Method Detail

      • getXMLOrder

        public int getXMLOrder()
        Determine the order that types should be written when storing panel files. Uses one of the constants defined in this class.

        Yes, that's an overly-centralized methodology, but it works for now.

        Specified by:
        getXMLOrder in interface Manager<Light>
        Returns:
        write order for this Manager; larger is later.

      • getLight

        @CheckForNull
public Light getLight​(@Nonnull
                      java.lang.String name)
        Get an existing Light or return null if it doesn't exist.

        Locates via user name, then system name if needed.

        Specified by:
        getLight in interface LightManager
        Parameters:
        name - User name, system name, or address which can be promoted to system name
        Returns:
        Light, or null if no existing Light.

      • newLight

        @Nonnull
public Light newLight​(@Nonnull
                      java.lang.String systemName,
                      @CheckForNull
                      java.lang.String userName)
               throws java.lang.IllegalArgumentException
        Lookup Light by UserName, then provide by SystemName. Return a Light with the specified user or system name. Lookup Light by UserName, then Provide New Light by SystemName. Note that two calls with the same arguments will get the same instance; there is only one Light object representing a given physical Light and therefore only one with a specific system or user name.

        This will always return a valid object reference; a new object will be created if necessary. In that case:

        • If a null reference is given for user name, no user name will be associated with the Light object created; a valid system name must be provided
        • If both names are provided, the system name defines the hardware access of the desired sensor, and the user address is associated with it. The system name must be valid.
        Note that it is possible to make an inconsistent request if both addresses are provided, but the given values are associated with different objects. This is a problem, and we don't have a good solution except to issue warnings. This will mostly happen if you're creating Lights when you should be looking them up.
        Specified by:
        newLight in interface LightManager
        Parameters:
        systemName - the desired system name
        userName - the desired user name
        Returns:
        requested Light object (never null)
        Throws:
        java.lang.IllegalArgumentException - if cannot create the Light due to e.g. an illegal name or name that can't be parsed.

      • createNewLight

        @Nonnull
protected abstract Light createNewLight​(@Nonnull
                                        java.lang.String systemName,
                                        java.lang.String userName)
                                 throws java.lang.IllegalArgumentException
        Internal method to invoke the factory, after all the logic for returning an existing Light has been invoked.
        Parameters:
        systemName - the system name to use for this light
        userName - the user name to use for this light
        Returns:
        the new light or null if unsuccessful
        Throws:
        java.lang.IllegalArgumentException - something failed in the names

      • activateAllLights

        public void activateAllLights()
        Activate the control mechanism for each Light controlled by this LightManager. Note that some Lights don't require any activation. The activateLight method in AbstractLight.java determines what needs to be done for each Light.
        Specified by:
        activateAllLights in interface LightManager

      • convertSystemNameToAlternate

        @Nonnull
public java.lang.String convertSystemNameToAlternate​(@Nonnull
                                                     java.lang.String systemName)
        Convert the system name to a normalized alternate name.

        This routine is to allow testing to ensure that two Lights with alternate names that refer to the same output bit are not created.

        This routine is implemented in AbstractLightManager to return "". If a system implementation has alternate names, the system specific Light Manager should override this routine and supply the alternate name.

        Specified by:
        convertSystemNameToAlternate in interface LightManager
        Parameters:
        systemName - the system name to convert
        Returns:
        an alternate name

      • supportsVariableLights

        public boolean supportsVariableLights​(@Nonnull
                                      java.lang.String systemName)
        Test if system in the given name can support a variable light.
        Specified by:
        supportsVariableLights in interface LightManager
        Parameters:
        systemName - the system name
        Returns:
        true if variable lights are supported; false otherwise

      • getBeanTypeHandled

        @Nonnull
public java.lang.String getBeanTypeHandled​(boolean plural)
        Get bean type handled.
        Specified by:
        getBeanTypeHandled in interface Manager<Light>
        Parameters:
        plural - true to return plural form of the type; false to return singular form
        Returns:
        a string for the type of object handled by this manager

      • getNamedBeanClass

        public java.lang.Class<Light> getNamedBeanClass()
        Get the class of NamedBean supported by this Manager. This should be the generic class used in the Manager's class declaration.
        Specified by:
        getNamedBeanClass in interface Manager<Light>
        Returns:
        the class supported by this Manager.