ShowTable of Contents
For complex applications with potentially large numbers screens with complex functionality, breaking apart your application UIs into different models provides many benefits. To name a few, it can help you avoid mammoth models with an unmanageable number of builder calls, developers can work on individual models independently and avoid merge conflicts, and individual models can be reused in other applications.
One way this can be done is with the Model Container builder and Web Experience Factory's Eventing builders.
The attached sample application demonstrates this.
Initially, the application displays a list of orders in tabular format. When an order is clicked, the order details display beneath the table. Shortly, you'll see how the tabular view of the orders and the order details are in two separate models and can be worked on and customized independently.
Create a new WEF project. When prompted during the new project wizard, enable the Tutorials and Samples feature set. (The UI relies on a sample provider model in this feature set)
Right click the project, select Import > Web Experience Factory archive. Select the attached file in this article.
How It Works
The application is broken into several models: Main.model, OrdersView.model, OrderDetail.model, and events.model. These models are located in web-inf\samples\model_container.
This model contains a Page builder called mainPage with named spans which will be replaced at runtime with with the UI's defined in the other two models, OrdersView.model and OrderDetail.model.
Two Model Container builders target the named spans and point to these two models.
An Action List called main, the entry point of the application, simply loads the mainPage.
Events.model is simple: using the Event Declaration builder, it defines an event called OrderSelected which is configured to pass an orderId to any event handlers listening for this event.
To take advantage of Web Experience Factory's Smart Refresh functionality (updating sections on the page rather than a full refresh), the builder is also configured to fire client side events.
The Event builder will create a fireOrderSelected method that can be used to fire the event. As you'll soon see, this model will be shared and imported by other models who wish to fire or handle this event.
This model displays a tabular view of all orders using the View and Form builder.
Notice that the Imported Model builder imports the events.model described above. This makes the event available to this model.
A Link builder makes the order id clickable. It is configured so that when the order id is clicked, the fireOrderSelected event (defined in event.model) is fired. The Link builder also recognizes that fireOrderSelected takes an order id, so the clicked OrderID from the current row -- the LoopVar -- is passed to the event. ( Loop Vars are an important Web Experience Factory concept. If you're unfamiliar with them, see the Wiki or the WEF help)
Now you'll see that when this event is fired, the OrderDetail.model will handle the event to display the details for the selected order.
So that is can handle the OrderSelected event, this model also imports event.model.
Main initially calls a blank page. This is so that when the application first loads and no order id has been clicked, nothing will show.
An Event Handler builder is configured to handle OrderSelected by using the passed orderID to set the getOrder input variable and invoke getOrder. A Client Event Handler is used along with WEF's Smart Refresh functionality to reload just the details part of the page when an order is clicked.