Using XML Schemas when working with UI5 XML Views

[alisdair73]

There has been much Twitter discussion in recent time about using XML Views when building UI5 apps. Having experienced }})}]]})))])); hell using JS Views myself I was keen to try this approach - it appeared to be more concise than its JS counterpart, and arguably easier to read (I do vaguely remember that XML was designed with human readability in mind even though it never really achieved this). As an integration guy, working with XML appealed, and assuming that the XML can be validated by an associated schema (XSD), most XML editors should provide intellisense and on the fly validation. This all seemed like good stuff!

Personally I use the Oxygen XML suite for XML work, but in this case Eclipse will be the tool of choice. Its XML validation is not too bad - it's not as good as Oxygen, but it will do for our purposes.

Before we get into the details, I just want to say that this approach is not perfect, and there are still some subtle issues (which I will discuss later). Hopefully someone can take what I've done so far and work out how to fix these :smile:

So, how do we get started?

First, you'll need the XSD's for the UI5 libraries. You can find these by looking inside the libraries folder inside the JAR file for each UI5 library. For my example I'm only using the core and commons libraries, so i'll need these 2 XSD's to begin. Copy the 2 files and store them in a location of your choice on your computer.

Figure 1. sap.ui.commons.xsd is found in the commons jar file.

If you open the XSD's in an XML aware editor and validate the schemas you'll see immediately that these XSD's are not syntactically correct (version 1.14.6).

The errors I found were:

1. Core has an invalid Regex defined for _URIType. You can either correct this or just comment out the pattern definition.
2. Core has a type reference to _anyType which doesn't exist in the schema. This type is used to define a value attribute in the _CustomDataType definition. To correct this, either remove the attribute definition or define _anyType in this schema.
3. Commons has the type _OrientationType defined twice in the schema. You'll need to remove one of these to make the schema valid. I kept the one with the lowercase horizontal and vertical enumerations as these seemed to correlate with some of the JS examples I have seen.

Now that the XML schemas are valid we can use these in Eclipse to help us build and validate our XML Views.

The easiest way to do this is to add the schemas to the Eclipse XML catalog. This can be done by opening the Eclipse preferences window (Eclipse->Preferences...) and then selecting XML->XML Catalog. Use the add button to load the 2 schemas into the XML catalog. You should notice that the key will automatically be set to the value of the schema namespace. When you have loaded the 2 schemas, click OK and return to the editor.

Figure 2. Adding the UI5 XSD files to the XML Catalog in Eclipse.

You're now ready to try it out. Start by creating a new UI5 application with an initial view of type XML.

Go into the View and between the View tags type "<Panel " (notice the space after the l) and then press control-space. You should something like the image below.

Figure 3. With the XSD files available, attributes and element information is provided by the IDE.

So what happens if you just press control-space without typing "<Panel "? Based on the schema definition and your location in the View definition, the editor will propose what the possible elements are that can be used. When you do this you'll start to see the limitations of the Eclipse XML editor. For example, when I click control-space immediately after the View element, I only see options from the Core namespace, but really I should also see all of the controls from the Commons namespace as these are also valid here. Try the same thing in Oxygen XML and you will get the result you expect.

Figure 4a. Possible child elements suggested by Eclipse.

Figure 4b. Possible child elements suggested by Oxygen XML.

Why does this happen? We'll I can't say exactly, but my guess would be that the Eclipse XSD processor doesn't understand the schemas correctly. The schemas used to define the UI5 libraries are using a concept called "Substitution Groups" to implement Polymorphism - The View XML expects the next element to be a Control (you can see this in the possible options), but doesn't understand that Button, Accordion, TextField etc. are also controls. Unfortunately this appears to be a limitation in Eclipse (does anyone know a fix??), but overall it's not a huge issue. As seen earlier, if you type the control name, the schema does identify it and provides additional help. What it does mean is that your view will most likely never be 100% valid (based on the schema definition), due to the validation looking for a Control and not understanding that Button is a valid substitute. Of course once you're inside a concrete Control element (say DropdownBox), the intellisense will automagically provide the valid child elements and attributes (such as items, ListItem etc), as well as any documentation provided for the control.

I initially started using this approach to build a form. The form controls are in the Commons namespace. Typing <Form into the editor will start the intellisense, and from then on the correct child elements are offered by the editor - FormContainer, FormElement etc. But there is a problem. Try running a form built this way and you get an error saying that sap.ui.commons.Form.js doesn't exist. If you look in the Commons Jar file, you can see that the form elements are in a sub-folder called 'form' (obviously) :wink: . What I did to correct this issue was to extract the object definitions that reside in the /form folder from the commons schema into a new schema with the namespace sap.ui.commons.form. By using this new schema the form library is correctly identified as sap.ui.commons.form.Form.js.

Figure 5. The IDE provides only valid child elements for <formElements>.

Figure 6. Once inside a <formElement> all Controls are available.

Anyway, that's it. Its not perfect, but it's easier than guessing from the API guide what should go where and in what order. You can achieve a fully validated schema by using a better XML editor, and then copy/pasting to Eclipse, but unlike Java, the XML validation errors will not stop the View being rendered, so as long as you understand why the error is there I believe this approach is absolutely usable.

Enjoy.