Don't Fight with WEF
A common mistake I see all the time is a web developer trying to untangle or intercept the code generated by WEF. Don't do it, you're going to lose your mind or create an unmaintainable mess (or both). Here are a few tips that should help:
1 - Turn off the theme
2 - Don't let the data page builder create the UI
3 - Learn how to exploit page automation
Turn off the Theme
There are two ways to accomplish this, adding a theme builder to your model and selecting the individual components, or blanking out the theme file name in the project's override.properties.
The theme is great when using WEF's default user interface, but it just gets in the way of custom HTML.
Dumb Down the Data Page Builder
The data page builder is the heart of page automation in WEF, but sometimes it wants to do too much, and again, gets in the way of custom HTML. We want dumb it down a little by turning off the option to make the UI from data.
Exploit Page Automation
Now that we've turned off some of the noise that we don't need, how do we tell the page automation to place data on our custom HTML? This is easily done by adding our own name attributes to the HTML elements. Whenever page automation finds a value for the name attribute that matches the data specified in the data page variable, it inserts a data value. Take for example the following XML data
<contacts>
<contact>
<name>n1</name>
<phone>p1</phone>
</contact>
<contact>
<name>n2</name>
<phone>p2</phone>
</contact>
</contacts>
We can ask page automation to take this custom HTML
<html>
<head>
<title>Default Test Page</title>
</head>
<body>
<table name="contacts" width="50%">
<tr align="center">
<th><span name="nameHeader">Name</span></th>
<th>Click to update</th>
<th><span name="phoneHeader">Phone</span></th>
</tr>
<tr name="contact" align="center">
<td><span name="name"></span></td>
<td><span name="btn"></span></td>
<td><span name="phone"></span></td>
</tr>
</table>
</body>
</html>
to produce a user interface, and this is what we see in the browser when we launch the application
This is how page automation sees the HTML name attributes that we added
You may have noticed that we added sorting capability to the first column, this is standard practice using a data column modifier (DCM) builder. The DCM builder needs to be able to identify the location of the table headers, and since we have custom HTML, we have to do this ourselves by adding a suffix Header to the name attribute in the table header rows.
Also note that the table row identified with the name attribute contact refers to the repeating XML data element contact. Page automation will create a new HTML row for each contact element in our data.
The edit button is there to demonstrate that we can easily add builders that refer to named locations in our HTML, just as if the data page builder had done all the work for us.
More information about manually marking up HTML for page automation can be found here.
Google+
0 comments:
Post a Comment
Are you about to post a generic comment that has nothing to do with this post? Something like "Hey thanks for this very valuable information, BTW here's my website". If so, it will be marked as spam and deleted within 24 hours.
Note: Only a member of this blog may post a comment.