Support utility method to return a map of macro's for a widget

[shroffk]

In BOY there was a utility method to get a map of macro names and values associated with a widget.

MAP = OPIBuilderMacroUtil.getWidgetMacroMap(display.getWidget("motor%d" % i).getModel())

The return Map<String, String> could easily map to a python dict, this is used in quite a few scripts in NSLS2 opi screens

While adding a similar functionality in org.csstudio.display.builder.model.macros.MacroXMLUtil is trivial (not sure if below is the most efficient implementation). I am wondering if this is a good idea overall.

    /** @param macros Macros to represent as Map
     *  @return Map representation for macros
     */
    public static Map<String, String> toMap(final Macros macros)
    {
        Map<String, String> readMacroMap = new HashMap<>();
        macros.forEachSpec((s, s2) -> {
            readMacroMap.put(s,s2);
        });
        return readMacroMap;
    }

or should we update all our script to use the interfaces already exposed.

labelMacros= display.runtimeChildren().getChildByName("Label").getEffectiveMacros()
labelMacros.getValue("W")

the only draw back here is that the Macros do not map nicely to any python structures

[shroffk]

@tanviash did you come across this issue?
@kasemir I know auto conversion of scripts is your favourite topic but do you see any additional issues to adding this utility method?

[kasemir]

The effective macros are somewhat open ended.
They certainly include a basic name/value map.
But if a name is not found in there, it can fall back to widget properties, java system properties, environment variables.

Your forEachSpec loop would get the macro specifications of the widget at hand.
To also get the values inherited from parent widgets, you need to use forEach.
Not sure about adding a toMap just for scripts.
People who love scripts should use PyDM, where each display is a script.
Does a typical script need a map of "all" macros, with a TBD definition of "all"?
Don't you typically just need to resolve a specific name, so you call macros.getValue("name") for the one name in question?
Or you want to resolve all macros within some string, so you call MacroHandler.replace(macros, "Some $(TEXT)")
So for new scripts I'm unclear why we need to copy "all" macros into a map.

For existing scripts that call some 'toMap', fine, grumble, OK, maybe.
But likely needs to use forEach, not forEachSpec

[shroffk]

Does a typical script need a map of "all" macros, with a TBD definition of "all"?

No, they should not... but then again what is a typical script.
I am adding this utility method and marking it deprecated. This way I can expediate the migration to Phoebus but also make it obvious that the maintainers of the script should update it.