We'll start with defining the structure of the HTML elements we want to use. The reasoning behind this that I want to keep the structure dynamic rather than compiling it into the plugin. The model must be able to derive whatever it needs to identify the element in the DOM tree from the meta layer.
It is easier to start at the bottom of the XText file, and work our way up.
HTML has a couple of different input fields, for the sake of shortness I'll only model textfield , option and checkbox (enum FieldType). I could have added buttons but they are not data entry fields so they get their own rule. In HTML, you have a couple of ways to get to an element. Again, I only model what I am gonna use (enum ElementType).
So, in order to describe how an element will be identified the rule 'ElementDefintion' will take any string, followed by a colon and an ElementType (e.g. "loginElement" : ID).
Then we have two rules, one for data entry fields (Field) and buttons (Button).
As we might have different environments where we need to execute our tests we define a LoginUrl (name will be the placeholder for the actual url), which is used in the rule Login.
A Form is a container that groups of set of fields and button. Kindly note that buttons have to be modelled first if so, followed by the data entry fields.
Last but not least we then model the Menu, which may contain nested menues. That leaves three top elements, menues, forms and logins (to be precise menues OR forms) OR logins).
In the next part we'll model the actual test DSL, referencing this meta model. But you can already test this DSL. Just hover over the project, right-click and select "Run as" -> Eclipse application. In the new Eclipse instance, create a new project and when you are finished, create a new file with the relevant extension (in my case .define). This will activate the DSL editor with code completion.
<< PART II
