I love it when things just work.
I was just designing the WSDL interface for a web service that another team is going to implement and that I'm later going to consume in a Web Experience Factory (WEF) app, and I couldn't remember off the top of my head how WEF Designer, it's Schema Generation and Page Automation deals with attributes. So I did a quick prototype.
If you've developed with Web Experience Factory or read about its features, you're certainly aware of its Page Automation feature, WEF's ability to generate dynamic pages and forms based upon schema-typed data. Give it a RowSet/Row/Row/Row structure, WEF's Schema generation and Page Automation understands the Row repeats and will generate tabular data with columns at the top. Supply it with a single record, Page Automation says, "Yep, I know you're data doesn't repeat ,so I'll generate an initial page with field labels on the side and data on the right."
Page automation inspects the schema and figures this out. Specifically, it sees the defined element names when generating the initial UI. But it also sees and surfaces attribute names, which can be a big help at design time when you want to vary your application based on a particular attribute.
For example, you've got this structure where one of the phone numbers is "primary."
WEF generates a schema of this example data like this:
<xsd:schema xmlnssd="http://www.w3.org/2001/XMLSchema" xmlns:tns="http://wpf.ibm.com/2002/10/generatedschema" targetNamespace="http://wpf.ibm.com/2002/10/generatedschema">
<xsd:element ref="tns:phone" minOccurs="1" maxOccurs="unbounded" />
<xsd:attribute name="type" type="xsd:string" />
Page Automation turns it into a field:
If you're saying, "So what?" Keep reading...
Suppose you want to hide all phone numbers that aren't primary. Since WEF's schema generation features surface the attributes and makes them available at design time, I can vary the app based on the attribute value. To hide the non-primary phone numbers, I can use the Visibility Setter, select "Hide when value does not equal Comparison Value", enter a comparison value of "primary", and simply use the picker to select the loopvar's @type field. That's it! (If you're not familiar with the "loop var," you should be. In addition to being one of my favorite features, it saves a ton of time. For repeating data WEF automatically creates a loop var containing the current row's field values, which is tremendously helpful for passing the current row's data to a custom Action or Java Method for a particular row. But that is the topic for another blog)
So now when I re-run my application, I the non-primary phone numbers are hidden.
By the way, if the boring tabular UI that page automation produces by default isn't exciting you, WEF has many features for complete control over the produce UI while still taking advantage of Page Automation's ability to bind data to the page. The sky's the limit. But that is the topic of another article.