Projecting your data onto the glass
Scott_Greer 270001WB8W Comments (2) Visits (5836)
Today I'd like to tell you a little story about RBD involving some of my favorite features. This story illustrates just how quickly you can derive a user interface from data.
If you're one of those just
So let's get started on our user interface for presenting weather forecasts for a zipcode using a public weather service.
The Premise: Here's your data
Even with the modern emphasis on design aesthetics, user interfaces exist to present and interact with content. Regardless of your design methodology, you usually know what you want to display before you to start to think about layout and widgets and so forth.
Working in EGL, the data for your UI will usually take the form of records, the definitions of which can come from a number of places. You can, of course, define records by hand, but it's more common -- and more interesting for this story -- to let RBD derive the record definitions for you, straight from their source. RBD can derive records from WSDL (Web Services Description Language), and it can also do the same with XML or JSON, using either schemas or samples.
Consider this weather service; although it only provides weather data for the United States, we're not going to be dwelling on the service itself -- the details of how it works and the data it provides aren't really critical to our story. This is just a representative service that allows us to talk about RBD's ability to work with your data. In this case, the service provides a WSDL file that defines the data it returns and the details necessary to access the service.
So we begin by creating an EGL Rich UI project and saving the weather service's WSDL in that project; we then right-click on that and choose EGL Services > Create EGL Client Interface. After examining the file, RBD will show us a brief wizard to allow us to adjust what it's found in terms of how to access the service and the data it provides, but often the results are acceptable as-is and that's certainly the case in our weather example. As long as the package and EGL source filename are to your liking, you can often just click Finish.
This results in an EGL source file containing the extracted record definitions and an interface for accessing the service; in other words, we now have our data modeled in EGL..... If you've never worked with WSDLs before, you might open the WSDL file to see a nice visualization of the service's interface and the functions it provides.
Now it's on to the glass -- and it's a surprisingly simple step to get there!
Projecting our data on the glass
Now that we've got our data defined as records, you might think the next chapter in our story involves a tedious description of creating and arranging widgets and then mechanically binding those widgets to the fields in the record.
Happily, RBD makes this mundane and error-prone process much easier to do. After creating a RUIHandler, we can now go to the EGL Data View -- it's in the lower-left view just below the Project Explorer. There will be an entry for our RUIHandler; right click on that and choose New > EGL Variable. This wizard will allow us to pick the type of our variable, and for this exercise we're trying to display weather forecasts, so we'll choose WeatherForecasts and name our variable; remember, WeatherForecasts is a record definition RBD found in the WSDL for the weather service.
Now our variable will show up in the EGL data view -- and this is where the dramatic stuff happens.
Drag the forecasts variable onto the gridLayout of your RUIHandler and drop it on one of the cells. RBD will now present the Insert Data wizard to allow us to configure the UI that will be derived from the data.
Let's briefly consider this wizard's capabilities. First, as you can see at the top, the wizard can create a UI that's either read-only, editable, or some combination of the two. Below that is the heart of the wizard, the "Data to display" section, which contains a tree-table derived from our data. For each field, the checkbox allows you to control whether the field should be part of the produced UI. You can also edit the Label -- you'll often want to add spaces or adjust the capitalization. Finally, you can choose the widget to be used to present the field; clicking on the Widget Type for a field accesses a dropdown box populated with widgets appropriate for the field's type. ("Add support for error messages" isn't enabled for read-only UIs, so we're not using it here but it allows you to configure the layout of the resulting UI to have places to show error messages next to each field.)
If I was a storyteller of any merit, at this point I'd have some foreshadowing of the dramatic conclusion. Instead, I'll direct your attention to the "Details" Field in the screenshot above; note that RBD correctly identified this as an array of WeatherData, and automatically assigned its widget type to "DataGrid". Sounds really powerful....but can RBD really deliver on this?
To find out, let's deselect a few of the uninteresting fields like "AllocationFactor" and click "Finish" .....
At this point, with just a few simple steps that take longer to describe here in writing than to actually perform, RBD has produced our UI for us. Take a look at the UI and think about the work RBD just saved us since we don't have to manually drag and drop these widgets ourselves. (Click on image to see a larger view.)
Now, to make this functional, we'll add a simple text field for entering a zipcode and a button for retrieving for the current forecast for that location; I also spent a few minutes rearranging things, and I decided to take advantage of the "placeholder" property on the DojoTextFields to simply the presentation of the Location and the Coordinates. Check it out below...(Click on image to see a larger view.)
The Get Forecast button has an onClick event handler who's source looks like this:
and the callback function is implemented as follows; as you can see, it simply updates the UI with the returned data.
While working with the data, I noticed that this service returns a URL for an image representing each day's weather forecast. This is exactly the kind of thing for which DataGrid behaviors are intended; I created a behavior that instantiated a RUI Image widget for the URL in a given row, and then associated that behavior with my datagrid. The relevant source snippets are pictured below:
With this, we're done. Let's see what it looks like in action -- all we have to do is go to the Preview tab to try out our new application....
The Dramatic Conclusion
As you can see, we can exercise our new application while still in the Visual Editor using the Preview mode; I've entered a zipcode for Raleigh, North Carolina and clicked "Get Forecast" to produce the results shown below.
Keep in mind that the application is essentially "live" now, even though we're executing it within the IDE; the remote weather service is being invoked and the data being obtained from it is the same as what we would get from the weather service's website.
So to conclude, we talked about different ways to obtain EGL records for your data, and demonstrated one of them (WSDL). From those records, we created a variable and then dropped that onto the Visual Editor canvas to access the Insert Data Wizard. We made some simple selections, and RBD produced nearly all of the UI shown; all that was left was to add our entry field and button and we also spent a few minutes rearranging the layout a bit just for aesthetics. Again, all of this went far faster than I could explain here.
Hope you enjoyed this article as much as I did writing it, and next time you have to build a UI, keep in mind these important, time-saving features. You might want to experiment with the EGL source for this project (available in the Files section).
Scott, with special thanks to Joe and Will for their assistance.