In this weekly series, Martin describes a question that was raised by a Fonto developer, how it was resolved and why Fonto behaved like that in the first place. This week, a partner is wondering how to use XPath in markup labels!

A support ticket came in with the following question:

Hey,

We’d like to show the outputclass of a specific element in a markupLabel, which is shown in the breadcrumbs. That appears to not be possible at this point because you’d need access to a node.

We’re trying the following, but it does not seem to work.

Do you have a solution to our problem?

Kind regards, a Fonto partner

They attached the following code:

configureProperties(
  sxModule,
  'self::p[contains(@outputclass, "level-")]',
  {
    markupLabel: t('level ') + getMarginNumberFromQuery('./@outputclass', 'level-')
  }
);

This is possible by using XQExpressions! If we change the code to the following, all is well:

configureProperties(
  sxModule,
  xq`self::p[contains(@outputclass, "level-")]`,
  {
    markupLabel: xq`${t('level')} {getMarginNumberFromQuery('./@outputclass', 'level-')}`
  }
);

This feature landed in the 8.0.0 release of the editor: a markupLabel can (besides being a string) also be an XQExpression: the result of a call to xq. The customer unfortunately still used the 7.13.0, so they could not use this API. Even though we still offer support for this older version, we are not releasing new features to it.

But why?

But why did start to work? Are all strings in Fonto going to be overloadable with XQExpressions? Markuplabels were just a string before!

Markup labels were actually one of the driving APIs for the XQExpression effort. One of the editors that we maintain ourselves is using a highly configurable schema: a meta-schema so to say. Instead of having all the elements in an XSD schema, the document defines which elements to use in a special XML document. Instead of using different elements names, a class attribute defines the semantic value of the elements. That’s why the markup label of those elements is dynamic as well. An author is not interested they are marking something as a generic inline, they want to work with a contract names!

From there, the team that maintained the editor internally introduced a way to mark a markup label as something that is actually an XPath. They would execute the XPath whenever the markup label of that element would be rendered: in a markupLabelWidget, in the breadcrumbs and more. They originally just prefixed the markupLabel with a special token that was unlikely to be used in other editors for an actual markup label.

With XQuery Template Tags, we have another way to see whether a JavaScript value is actually just a string or an XQExpression. Because we can recognize them, we can start marking overloads for APIs that currently only accept a string literal. For example outputClass and outputClassQuery. Or the backgroundColor property for SX configuration. We will start moving from these APIs to a single overload for outputClass that also accepts an XQExpression. Some of these changes are already planned to be shipped in the 8.1 version of Fonto!

I hope this explained how Fonto works and why it works like that. During the years we built quite the product, and we are aware some parts work in unexpected ways for those who have not been with it from the start. If you have any points of Fonto you would like some focus on, we are always ready and willing to share! Reach out on Twitter to Martin Middel or file a support issue!