4.1. About command names

The name of a command is basically an NMTOKEN. To make it simple, this means that a command name may contain letters, digits, a few punctuation characters such as '_', '-' and '.', but no space characters.

All the commands are registered by their names in the same global registry. In practice, this means that if configuration A defines a command called doIt, then configuration B has access to this command. This also means that if configuration C also defines a command called doIt, then this command may overwrite the one defined in configuration A[7].

A simple way to prevent this kind of name conflict is to use a prefix (not related to XML namespace prefixes) for the name of your commands. Example of commands written by XMLmind: docb.promote, docb.demote, xhtml.preview. (We always use short_lower_case_prefix.camelCaseCommandName.)

However, in some cases, the commands you are writing are really private to your configuration. Example: a helper macro-command invoked by another macro-command. In such cases, you'll not want anyone to be able to access these commands. In particular, you don't want the end-user to execute these ancillary commands by using ToolsExecute Command or OptionsCustomize configurationAdd Keyboard Shortcut.

When you'll want your command to be really hidden from the end-users, you may consider giving it a name having a namespace (not related to XML namespaces). Example: in "{My Config}doit", the namespace is "My Config" and the local name is "doIt".

A command namespace may contain any character except '}'. A command local name is an NMTOKEN. The command namespace is of course optional.

In many cases, you'll want your command namespace to contain the name of your configuration. When this is the case, you may reference the "$c" pseudo-variable anywhere in your command namespace. Examples: "{$c}doIt", "{$c helper}selectItFirst"

Command namespaces also play a fundamental role in defining or extending the right-click, contextual, menu in XMLmind XML Editor - Commands.



[7] Or the opposite way around: doIt defined in configuration A overwrites doIt defined in configuration C. This depends on the order of configuration loading by XXE.