Make Macros Generic for Custom Blocks
You can design macros for custom blocks to work with the results of a wider range of mashables and mashups - to be generic. Defining the logic of a generic macro is the same as any macro. There are, however, two issues that generic macros typically must take into account:
Do you need to accommodate block results that have XML namespaces as inputs?
Since users may connect many different types of results as inputs, the XPath expressions within the macro should be prepared to handle results that use namespaces. You can use wildcards as a namespace in the XPath expressions, such as $someVar/*:root/*:child.
How does the macro identify the nodes it must work with for the different block results that are used in different mashups?
Since you do not know the structure of the input when you design the macro, users must identify the nodes that the macro will work with from the block(s) that they connect as input to the custom block for the macro. So, in addition to having one or more input parameters to receive block results, the macro must have input parameters that identify the nodes of interest to the macro.
These 'nodes of interest' are identified by XPath expressions for the specific input block results in a given mashup where the macro is used. This results in requirements for the macro and for its custom block in Wires:
Users must be able to easily supply these XPath expressions when they use the custom block in
Wires.
The solution to this issue is to force users to select the appropriate nodes in the Path Selection list in Wires and then assign the XPath expressions for the selected nodes to the block properties for the appropriate macro input parameters.
You use metadata configuration in the macro to define this behavior for the custom block. See
Get the Chosen Path as Text for information on the appropriate metadata.
Note: In previous releases, you could define which input parameters should contain XPath expressions using a <presto:presto-meta> statement. Effective with MashZone NextGen 3.2, this syntax is deprecated.
The macro must use these XPath expressions within its logic statements to work on the specific results for that mashup.