esimone_clearblade 270000E5WV Tags:  clearblade web2.0 egl widget tree rui eglcafe grid richui 2 Comments 7,460 Views
Remember the old Reese’s Peanut Butter Cup commercial from the 1980’s? (http://www.youtube.com/watch?v=U5_gTdqeUOI) Well this is kind of like that. Instead of mixing peanut butter and chocolate, we are mixing Grid and Tree widget functionality to create a bill of materials (BOM) view.
Recently a customer asked for this type of functionality for a BOM business application. They had built a prototype in Java/JSF and wanted to see what could be done in EGL. Using an example BOM for a lamp assembly, we created an EGL RichUI handler with the expand/collapse functionality within a Grid. Following is the data we used:
We played with using a Dojo tree widget first but quickly realized it didn’t give us the same functionality as the EGL Grid with respect to behaviors. When we switched to the EGL Grid we quickly realized that we could create tree widget behavior within a grid widget.
Following are a couple of screenshots of the solution. The BOM Example is hosted on the ClearBlade website at:
Through use of the following behaviors in the Grid widget, we were able to accomplish our desired end result:
The first order of business was to create the indentation of child rows. This was easily accomplished by creating the cellIndent function (we also removed the grid borders):
Next we aligned the numeric columns on the right with the cellAlign function.
Then we needed to add the tree expand/collapse controls with the treeButtons function. By adding an Image widget to all rows with children and interrogating their state (collapse = true/false), we create controls to expand and collapse the rows.
Finally, the filterGrid function hides or shows the rows based on state. This was a bit tricky since we wanted to maintain the expand/collapse state of each row. To solve this, each row has a counter, showRow, that tracks the depth of the collapse tree. Once the counter is at 0 the row should be displayed.
To implement the expand/collapse logic, we needed check the level of each row and recursively expand/collapse the rows.
This was done with the treeControl and expandCollapse functions.
EGL Grids are amazing. I was very impressed as how a relative RichUI novice like myself was able to implement fairly complex behavior. Download the code here to review and reuse:
Please feel free to contact me with any questions or improvements.
Eric Simone – CEO ClearBlade
One nice design feature of EGL Rich UI is that UI components can be organized into self-contained, independent units. This makes it easy to reuse components in different applications and within different parts of the same application. Infobus, which was described earlier, provides a way for components to talk to each other, without necessarily knowing about each other. This enables new components to be snapped into an application without disturbing the other components. This approach also saves you from creating enormous RUI handlers that eventually become a spaghetti code nightmare.
The following example illustrates a good pattern for constructing Rich UI applications. You will notice a main "driver" RUI handler (PartDetailsApplication) that defines the basic layout of the application. It references other RUI handlers that contain the client-side logic of the application. Each RUI handler can operate independently from the other handlers and there does not need to be any hard dependencies between the handlers. This makes applications more modular, and allows for greater flexibility later as business requirements change and new requirements are introduced.
Below are descriptions for the different components that make up a sample (and very simple) application that provides sporting good part information to a user.
PartListHandler is a RUI handler that displays a grid (data table) of parts to the user.
Here is the code:
The grid is populated from a static array of PartRecord objects (typically data would be retrieved via a service call, but, for the sake of simplicity, the data is hard-coded). When a row in the table is selected, the selectionChanged function of the RUI handler is called (this happens because GridSelector provides a mechanism whereby a listener can be notified when a row is selected). The selectionChanged function gets the selected part from the grid and publishes it via the InfoBus. The name of the message (com.ibm.samples.rui.part) is defined in a constant variable, PART, defined in a basic library (*PartDetailsLibrary*). It is recommended to define InfoBus message names as constants in a library (this avoids typing mistakes and makes maintenance easier if the name needs to change for some reason).
When the "com.ibm.samples.rui.part" message is published, the partCallback function is called (this part picture RUI handler knows nothing about the part list handler). A quick check is made to ensure the incoming message name and data object are what we expect (because we subscribed to an explicit event name, we really don't need to perform this check, but it's always safe to double-check since applications grow in size and complexity over time). Because the data object is a PartRecord, we can grab the selected part's picture file name, construct a URL to the image, and set it on our Image widget (effectively showing a picture to the user).
Here is how the completed application appears: