If you want to implement additional model validations that cannot be easily expressed in the underlying XSD schema either for your custom elements after
extending the Xomega model via additional configurations, or as new validations to existing elements, then Xomega allows you to easily add such validations that result in either hard errors or warnings. The validations will be performed both live as the users edit the model, thus providing them with the instant feedback on any problems with the model, and before running any generator to ensure that all warnings are visible and all errors are addressed in the model.
The custom validation behavior is driven by a dedicated XSL style sheet
validation.xsl, which comes with the Xomega.Net and is located with other style sheets in the XSL folder of the Xomega installation. Remember, that this style sheet is using the XSLT 1.0, since it is run by the internal XSLT engine built in .Net, and therefore is fairly limited as compared to the XSL scripts used by the generators, which use XSLT 2.0.
The following steps outline the process for adding custom validations to your model. Note, that this process requires that you install the Full Edition of Xomega.Net and obtain the source code for the Xomega validation style sheet.
- Request the source code for validation.xsl from Xomega, and place it to the XSL sub-folder of the Xomega.Net installation folder.
- Open the validation.xsl file and add a template that matches the node that needs to be validated.
- Check the conditions for any errors or warnings related to the current XML element using the values of other elements in the model as needed.
- For each warning/error condition call the sink:AddWarning/sink:AddError method using the xsl:value-of element.
- As a first argument, pass the XML node that has the warning/error, which will be underlined in the Xomega Editor. This could be an attribute, an element or a text node.
- As a second argument, provide a string that describes the actual warning or error. Make the message clear enough and include enough details for the users to be able to understand what the problem is and how to solve it from the message alone without the context node, since these messages can be displayed for the entire model before the generators are run. The details can include the values that identify this and other elements, as well as possibly file locations of the other elements. For the latter you can use the cust:GetFile function, which you can pass the element to.
- Test the validations in your model to make sure that it works as expected.
The following example demonstrates the above steps.
Code:
<xsl:template match="xfk:data-object[@class]">
<xsl:variable name="sameXdo" select="preceding::xfk:data-object[@class=current()/@class]"/>
<xsl:if test="$sameXdo">
<xsl:value-of select="sink:AddError(@class, concat('Data object class "', @class,
'" is already defined in the file ', cust:GetFile($sameXdo[1]),
'. Please pick a different class name or use the "add-to-object" element to add properties to the existing object.'))"/>
</xsl:if>
</xsl:template>