Tutorial – Creating Data-Driven Portlets

 

+

Search Tips   |   Advanced Search

 

Overview

This tutorial focuses on building applications and portlets that display rows of data and single pages of data.

This tutorial relies on IBM WebSphere Portlet Factory Service-Oriented Architecture (SOA) in which one model provides the data services and a second application model consumes these services. The SOA architecture supports a concept called Service Provider stubs which function like real data providers but serves up static, sample data. Stubs allow developers to build applications and test them without having any real live database connections.

You will also be introduced to page automation builders. These builders are high-level builders that take in XML result sets and produce pages automatically to display the data properly even when the data or the data's schema change. By applying modifier builders and resource bundles, rich user interfaces (UIs) for these automated pages are easy to create and modify. Finally, you will make a portlet out of the application to see these high-level builders in action within the portal framework.

In this tutorial, you will:

  • Create an application using low-level and high-level builders to display rows of data and single pages of data.

    The most significant high-level builder you will use is called Data Page. A Data Page builder can be given XML result sets generated from calls to the service provider for display. Using the data's schema and by examining the result set, Data Page can guess whether the data represents many records or a single record. Data Page automatically adapts itself to display rows of data, single pages of data, or data entry pages even when the schema of the data changes.

  • Use WebSphere Portlet Factory's Service-Oriented Architecture.

    Data for the application comes from Service Provider models. The application retrieves that data from the provider via a Service Consumer builder. When multiple providers are built with the same interface, they can be used interchangeably. In turn, high-level, page automation builders adapt to the changes in the data's schema and produce a new version of the application to display the new data. For example, you will build an application to display employee data. Then you will switch service providers to one that provides data about product orders. By simply changing service providers, the employees application becomes a product orders application.

  • Apply page formatting.

    Using modifier builders and resource bundles, you will apply formatting, column sorting, custom column labels, column hiding, and input page UI controls. These formatting controls are easy to apply, modify, and profile.

  • Use Action List builders to control application function and flow.

    Action List builders contain a series of tasks that are performed when the list is invoked. This type of builder can accepts input arguments which it can use in performing its tasks. For example, an action list could accept an argument, use that argument as an input to invoke a service call, then open a page that displays the results of that service call.

  • Incorporate reusable components. A model can be designed as a reusable component. If the model can run as an independent application, it can be imported into another model with a single builder call: Imported Model. By importing a model into a host model, the features of the imported model become part of the features of the host model. For example, you will be given a model that creates new employee records. By importing this model into the application you will build in this tutorial, the create employee features will be available in your application.

  • Create a portlet.

    As in a previous tutorial, you will add and configure a Portlet Adapter builder call in the application so that it will function as a portlet.

  • Become familiar with View & Form builders. View & Form is a key, higher order builder that includes many of the common features found in CRUD applications.

 

Setup Requirements

The following setup is required to run the tutorial.

  • You need access to a local or networked installation of IBM WebSphere Portal and that WebSphere Portal server is running. The instructions in this tutorial assume that you have the WebSphere Portal server installed locally, though other configurations are possible, as described below.

  • WebSphere Portlet Factory Designer must be installed locally. WebSphere Portlet Factory Designer is the development environment for creating web applications and portlets.

  • A test application server environment must be available. Eclipse and the Embedded Test Environment for Rational Application Developer are standard test environments. You must know which server or test environment you intend to use.

  • You need to have completed the "Creating a Web Application Project" tutorial, including the deployment of MyFirstProject.

  • WebSphere Portlet Factory server must be running.

 

Create the Application Model

You need to build a new Web Application project, or you can use an existing project from a prior tutorial.

Note: In either case, the project must include the Tutorials and Samples feature set.

  1. Add a new model to the Web App project

    1. Right-click the project name and choose...

      New | WebSphere Portlet Factory Model

      This command will invoke a wizard to assist you in creating a new model.

    2. Your project name should be selected. Click Next to continue.

    3. In the Select Model panel, choose Main and Page from the Factory Starter Models category and click Next.

    4. Choose Simple Page to get a very basic HTML page. Choose Simple Page and click Next.

    5. Choose the folder called...

      models\tutorials\solutions\basics

    6. In the Model name field, enter EmployeesPortlet and click Finish. WebSphere Portlet Factory Designer will now create your new model and open it for you.

    7. Run the model by clicking from the row of icons immediately below the menu at the top of the workspace.

  2. Rename the Page Builder call and test

    1. Edit the Page Builder named page1. Change its name to allEmployeesPage and click OK.

      You should now see an error in the Problems tab at the bottom of the workspace. This error states that The Action "page1" was not found in "main". You will fix this minor problem in a moment.

    2. Open the Action List builder call. In the Actions input, click the on the row that contains page1.

    3. Choose Pages > allEmployeesPage. Click OK to continue.

    4. Click OK in the Action List builder call to save the changes. The error message about page1 not being found should have gone away.

    5. Run the model again by clicking . The web page should look the same as it did the last time you tested it.

  3. Get data from a service provider model via a Service Consumer builder.

    A Service Consumer works in conjunction with the service definition and Service Operation builders, and is used to provide access to a public service created by those builders in a Service Provider model. The basic idea is that one model, the service provider, has exposed services that can retrieve data from a data source and return that data to a Service Consumer model. The Service Consumer builder is used to make these services available in an application model. The data returned by the Provider model is in an XML format that can be used easily by sophisticated builders like Data Page to render an HTML page containing the data.

    In this tutorial, the Employees portlet needs Employee data. The Provider model has been supplied to you in the Tutorials and Samples feature set and provides the data needed by the Employees portlet. For convenience, the Provider model is a stub provider meaning that it does not connect to a real datasource. Instead, it has an interface that appears to the consumer model as if it is getting real data but is actually providing static data that was copied from a database during development of the Provider model.

    1. Click to add a new builder call to the model.

    2. Choose Service Consumer and click OK.

    3. Use the following table for the details about what values to provide for the various inputs to this builder call. Click OK when you are finished entering these values.

      Input Name Value input
      Name EmployeeData
      Provider Model Click and choose...

      tutorials/basics/data/TutorialBasics_Provider_Employees_Stub
      Add All Provider Operations Check the box

  4. Display the data on a page using a high-level builder called Data Page.

    The Data Page builder creates a structure based on the XML data in a variable and renders this structure as a form (both input and display) on a page. The structure created by the Data Page describes the data to be displayed as well as how to render the data on the form. A schema associated with the data on which the Data Page operates can determine how the data gets displayed as can the HTML page associated with the Data Page.

    Use the Data Page builder to create forms that either display data, prompt the user to enter data, or are a combination of the two. Typically, Data Page is used to display the results of a service call or SQL statement or to create input forms based on an element type defined by a schema and an associated variable.

    1. Click to add a new builder call to the model.

    2. Choose Data Page and click OK.

    3. Use the following table for the details about what values to provide for the various inputs to this builder call. Click OK when you are finished entering these values.

      Input Name Value
      Name allEmployeesDataPage
      Variable Click and choose DataServices/EmployeeData/getAllRecords/results.
      Page in Model Choose allEmployeesPage.
      Created Elements Setting

      Make UI from Data Check the box – It is checked by default but this input is important. It is the one that causes Data Page to examine the data and make decisions about how to present the data.
      Location for New Tags Choose namedTag.

    4. Edit the action list to invoke the data service that fetches the employee data.

      1. In the builder call list, locate the builder named main. Double-click this builder call to open it.

      2. In the list of actions, click the on the row below allEmployeesPage.

      3. Choose...

        DataServices/EmployeeData/getAllRecords

        ...and click OK.

      4. The action list now has the right tasks but they are in the wrong order. Use the mouse to drag the allEmployeesPage row to a position below...

        DataServices/EmployeeData/getAllRecords

      5. Click OK to close this builder call.

    5. Test the model by clicking . You should see columns of data about fictitious employees.

  5. Demonstrate Basic Page Automation.

    In this step, you will be guided through changing the Service Provider model to one that provides different data unrelated to employees. You will see that Data Page is able to accept the new schema and the new data and render a page that shows orders data instead of employees data.

    1. Switch back to WebSphere Portlet Factory Designer to make some changes to help you understand Data Page better. You will change the Data Provider model from an employees data service to a product orders data service. Soon you will see that by consuming different data, Data Page adapts.

    2. Open the Service Consumer builder call. In the Provider Model input, click and choose...

      tutorials/basics/data/TutorialBasics_Provider_Orders_Stub

    3. Test the model again. This time you should see rows of data about product orders instead of employees.

    4. Open the Service Consumer builder call. In the Provider Model input, click and choose...

      tutorials/basics/data/TutorialBasics_Provider_Employees_Stub

  6. Apply Page Formatting.

    Formatting HTML pages containing Data Page builder calls involves using resource bundles and applying modifier builder calls.

    A resource bundle is basically a text file with name-value pairs that map the actual column names from the data retrieved from the Service Provider model to more readable names. For example, LAST_NAME could be mapped to Last Name to make it easier to read.

    A modifier builder is added to a model after a high-level builder like Data Page to allow finer control over the work done by the high-level builder. For example, a Data Field modifier can be added to a model containing a Data Page builder in order to add a link on every row in a given column to perform a certain task when clicked. A Data Column modifier could be added to change the order of columns, hide certain columns, and include sorting features for other columns.

    1. Open the Data Page builder call and expand the Label Translation Settings field.

    2. Use the following table for the details about what values to provide for the various inputs to this builder call. Click OK when you are finished entering these values.

      Input Name Value
      Localized Resource Choose Add a new Localized Resource to the WebApp.
      Resource Bundle Name Click and choose...

      com.bowstreet.samples.tutorials.tutorial_basics

    3. Test the model again. This time you should see that the column headers have easy to read labels.

    4. Click to add a new builder call to the model.

    5. Choose Data Column Modifier and click OK.

      This builder call is used to change column order, sorting, hiding and other formatting options.

    6. Use the following table for the details about what values to provide for the various inputs to this builder call.

      Input Name Value
      Name reformatColumns
      Container Field Click and choose...

      [allEmployeesPage]allEmployeesDataPage/RowSet/Row

    7. Use the following table to set the column attributes for the data display table. The objective is to hide several columns and create sorting links out of several column headers. Click OK when you are finished entering these values.

      Note: The columns may not be listed in the same order as what is shown here. To be consistent and to avoid confusion, you should use the mouse to drag and drop the columns to get them in the same order as the table below.

      Column Name Status Column Sort Type
      EMPNO Do Not Change Not Sortable
      LASTNAME Do Not Change Case Insensitive String
      FIRSTNME Do Not Change Case Insensitive String
      MIDINIT Hide Not Sortable
      PHONENO Do Not Change Not Sortable
      WORKDEPT Do Not Change Case Insensitive String
      JOB Do Not Change Not Sortable
      HIREDATE Do Not Change Date
      EDLEVEL Hide Not Sortable
      SEX Hide Not Sortable
      BIRTHDATE Hide Not Sortable
      SALARY Hide Not Sortable
      BONUS Hide Not Sortable
      COMM Hide Not Sortable

    8. Run the model again to test it. You should see links in the column headings that sort the table by the values in a given column. Click on a column heading to sort in ascending order. Click the column heading again to sort in descending order.

 

Add "Get Employee" Features

  1. Add a Page builder call

    1. Click to add a new builder call to the model.

    2. Choose Page and click OK.

    3. Name the page getEmployeePage.

    4. Modify the contents of this page. You will clean up some default content and add another named element inside a <div> tag.

      1. Remove the contents of the <span> tag that reads, "Use a named tag to ...on a page" leaving the tag, that is, <span name="namedTag"></span>.

      2. Add the following <div> tag just before the closing </form> tag:

        <div><span name="cancelButton" /></div>

      3. Click OK when finished.

  2. Add an Action List builder

    An action list is much like a subroutine in concept. In the Actions field, there is a table that can contain a series of commands. Each time this action list is run, these tasks will be performed.

    Action lists can have arguments. When the action list is invoked, the calling routine must provide the input argument values. These values can then be used in the action list's actions by indirect reference, for example:

    ${Arguments/EmployeeID}

    In this tutorial, this action list has an argument that is used as the lookup key to retrieve the details of a given employee.

    1. In the Name input, enter getEmployeeActions.

    2. Expand the Arguments section of this builder call to declare an argument. The argument will be the unique identifier of a given row of data.

      1. In the Name column, declare a new argument by typing in EmployeeID.

      2. In the Data Type column on the same row, choose String from the list.

      3. Collapse this section.

    3. Add an Assignment command. An Assignment takes a value or expression and assigns it to a variable. You will take the action list's input argument and assign it to the input argument for the service that retrieves a single employee's information.

      1. On the first row, click and choose...

        Special | Assignment

        The Make Assignment dialog appears.

      2. Click in the Target field and choose...

        DataServices | EmployeeData | getRecord | inputs | OneRecordInputs | Parameter1Value

        Note: If you cannot choose anything past getRecord > inputs, click OK, and then manually append /OneRecordInputs/Parameter1Value. When using a Service Provider stub model, the details of the input schema may not be available in this chooser but are still required.

      3. Click in the Source field and choose...

        Arguments | EmployeeID | OK

    4. Add the following actions to the list.

      1. On the next row of the ActionList column, click and choose...

        DataServices | EmployeeData | getRecord | OK

        You should see this command get added to the list.

      2. On the next row, click and choose...

        Pages | getEmployeePage | OK

        You should now see two commands in the list.

      3. Click OK to close this builder call.

  3. Add a Data Page to display the details of a single employee record.

    1. Use the following table for the details about what values to provide for the various inputs to this builder call. Click OK when you are finished entering these values.

      Input Name Value
      Name getEmployeeDataPage
      Variable Click and choose...

      DataServices/EmployeeData/getRecord/results
      Page in Model getEmployeePage
      Page Type Infer from HTML
      Created Elements Section

      Make UI from Data Check the box – It is checked by default but this input is important. It is the one that causes Data Page to examine the data and make decisions about how to present the data.
      Location for New Tags namedTag
      Label Translation Settings

      Localized Resource allEmployeesDataPageTranslate – This value declares that this Data Page will use the same resource bundle for field labels used by the allEmployeesDataPage builder call.

  4. Add a Data Field Modifier to create a link out of the ID column.

    1. Click to add a new builder call to the model.

    2. Choose Data Field Modifier and click OK.

    3. Use the following table for the details about what values to provide for the various inputs to this builder call. Click OK when you are finished entering these values.

      Input Name Value
      Name getEmployeeLink
      Field Selector Tool Select by Name
      Fields Click and choose...

      [allEmployeesPage]allEmployeesDataPage/RowSet/Row/EMPNO
      Field Settings

      Field Behavior Action Field
      Control Type Link from the list
      Action Type Link to an Action
      Action Click and choose getEmployeeActions from the Methods folder.
      Argument Name for Data EmployeeID

    4. Run the model to test your work by clicking . You should see a link in every row in the ID column.

    5. Click a link to see what happens.

      Note: If you are using a Service Provider stub for the data, every link will open with the same sample data. If you are using a live Service Provider, each link will open the corresponding data record. In either case, notice that the EmployeeID number is passed on the URL. That is...

      http://.../Action!_gen_call_getEmployeeActions?EmployeeID=0002000

    6. Switch back to WebSphere Portlet Factory Designer when you are finished testing your application.

  5. Add a Cancel button to allow the user to go back to the allEmployeesPage.

    1. Click to add a new builder call to the model.

    2. Choose Button and click OK.

    3. Use the following table for the details about what values to provide for the various inputs to this builder call. Click OK when you are finished entering these values.

      Input Name Value
      Name getEmployeeCancel
      Page getEmployeePage
      Tag cancelButton
      Label Cancel. If the label for this button were stored in a variable or came from the results of a service call, you could choose the appropriate source. In this case, a simple text string will suffice.
      Action Type Link to an Action
      Action Click and choose allEmployeesPage from the Pages folder.

    4. Test the model by clicking . Open any employee's detail record by clicking on a link in the ID column. Use the Cancel button to see if it takes you back to the page with all of the employee data.

 

Using Imported Models

Building reusable components is an important goal in many application development environments. WebSphere Portlet Factory is no different. Most of the reusable components in WebSphere Portlet Factory are builders. However, models can be reused as well. One model with all of its features and capabilities can be included in many other application models by simply importing that model via an Imported Model builder.

The models being imported may already have some of its builder inputs profiled. If so, these inputs are exposed in the Imported Model builder. These exposed inputs allow the imported model to be configured at import time to work with the host model into which it is imported.

In this section, you will examine a model that creates new employee records, and then you will import that model into the EmployeesPortlet model. After importing this model, the employees portlet will have the ability to create new employees records.

  1. Examine the Employees_Create model in models/tutorals/basics.

    1. Open this model in WebSphere Portlet Factory Designer. Open the builders in the builder call list to see if you can understand what this model does.

    2. Test the model. It should open a page containing a Create button.

    3. Click the Create button. You should see a data input page for inputting an employee record.

  2. Test this model with a different data schema.

    1. Switch back to WebSphere Portlet Factory Designer.

    2. Open the Service Consumer builder call named EmployeeData.

      1. In the Provider Model field, click and choose...

        tutorials/basics/data/TutorialBasics_Provider_Orders_Stub

      2. Click OK to close this builder call.

    3. Test the model in a browser again. This time, the model should present an input page for entering a product order.

    4. Open the Service Consumer builder call named EmployeeData to return the service provider to its previous value.

      1. In the Provider Model field, click and choose...

        tutorials/basics/data/TutorialBasics_Provider_Employees_Stub

      2. Click OK to close this builder call.

    5. Test the model again. It should now present an input page for employee data.

  3. Open the Employees_Create model.

  4. Open the allEmployeesPage builder.

  5. Copy the HTML from the Page Contents field.

  6. Paste this text over the text in the corresponding field in the EmployeesPortlet model.

  7. Import the Employees_Create model into the EmployeesPortlet model.

    1. Open the EmployeesPortlet and click to add a new builder call to the model.

    2. Choose Imported Model and click OK.

    3. Use the following table for the details about what values to provide for the various inputs to this builder call. Click OK when you are finished entering these values.

      Input Name Value
      Name createEmployeeModel
      Model Click and choose tutorials/basics/Employees_Create.
      Profiled Inputs

      Profile Handling Set individual inputs.
      Include main Action List? Deselect this option.
      Include allEmployees Page? Deselect this option.
      Include Service Consumer? Deselect this option.

    4. Test the model again. This time there should be a Create button.

      1. Click the Create button to see what happens. You should see an input form for creating an employee.

      2. Click the Submit button without supplying any values. The fields with the red stars are required and should fail validation.

      3. Provide inputs for the required fields and submit. You should see the starting page of the application with rows of employee data.

        Note: If using a Service Provider stub for data, the new record will not be added to the stub data.

      4. Switch back to WebSphere Portlet Factory Designer.

 

Apply Formatting to an Input Form

Earlier in this tutorial, you applied page formatting using a resource bundle and some modifier builders. In this section, you will apply formatting to a data entry form. Since data entry forms contain HTML fields, there are special builders designed to modify how Data Page renders those input fields.

For example, Data Page might present a plain text field to enter data such as one's work department. A better UI choice might be a drop-down list of department names. A Rich Data Definition builder call that refers to an XML file with UI details can easily format many input fields on a page.

Once the fields are automatically placed on the page, changing their order or grouping them together might improve the UI of the page. A Data Hierarchy Modifier builder call is used to perform this task. In this builder call, you can use "drag and drop" to change the order of the fields on the page and set the "begin" and "end" points of groups of inputs.

These concepts are easier to understand by using them in a model. The following steps will help you to understand the XML file referred to by the Rich Data Definition builder call and the grouping of inputs via a Data Hierarchy modifier.

  1. Examine a Rich Data Definition file.

    1. Starting from the root of the project, open the following file:

      WebContent/samples/tutorials/data_definitions/tutorial_basics_richUI.xml

    2. At the top of this file, there are definitions called base_TextInput, base_DateInput, and base_RadioButton. These definitions declare default values for various data entry User Interface (UI) elements. Other definitions within this file can refer to these named definitions as their base UI element type. The default values can be overridden providing alternative values in subsequent data definitions.

    3. Scroll down this file and find the XML node that looks like this:

      <DataDefinition name="Row">

      This data definition contains details about how the fields for a single set of data input fields should behave.

      1. Look at the <Children> node of this data definition for details about the input fields. FIRSTNME, LASTNAME, MIDINIT,and WORKDEPT for example, are all text input fields but they have different attributes. Some are required and some have controls for their HTML attributes such as size and maxlength.

      2. Notice that the base type of these fields is called base_TextInput. Scroll up to the definition of base_TextInput to see the default values and UI element type for these fields.

    4. Scroll further down this file to find the elements using the base_DateInput UI element. These two fields will have a Calendar Picker UI element to assist users in entering dates.

    5. Locate the data definitions for the fields called JOB and EDLEVEL. These definitions have a list of <EnumerationValues>. These values will appear as a list of values from which the user can choose.

    6. Close this file when you are finished examining it.

  2. Add a Rich Data Definition Builder call.

    1. Click to add a new builder call to the model.

    2. Choose Rich Data Definition and click OK.

    3. Use the following table for the details about what values to provide for the various inputs to this builder call. Click OK when you are finished entering these values.

      Input Name Value
      Schema EmployeeDataOneRecordTransformSchema
      Data Definition Type Read Data Definition File
      Data Definition File Click and choose...

      /samples/tutorials/data_definitions/tutorial_basics_richUI.xml

    4. Test the model again. This time there should be a better UI for the input fields.

  3. Add a Data Hierarchy Modifier builder call.

    1. Click to add a new builder call to the model.

    2. Choose Data Hierarchy Modifier and click OK.

    3. Use the following table for the details about what values to provide for the various inputs to this builder call.

      Input Name Value
      Name createEmployeeFormatting
      Field Selector Tool Select by Name.
      Fields Click and choose...

      [createEmployeePage]createEmployeeDataPage/Row
      New Group Names Personal, Business, Other – Click Apply after adding these group names to refresh the table below this field.

    4. Group the inputs. Use the mouse to drag and drop fields in between the start and end rows for each group.

      Group the inputs as follows:

      Group Name Fields that belong in the Group
      Personal EMPNO, FIRSTNME, MIDINIT, LASTNAME
      Business WORKDEPT, PHONENO, HIREDATE, JOB
      Other EDLEVEL, SEX, BIRTHDATE, SALARY, BONUS, COMM

    5. Click OK when you have finished.

    6. Test the model again. This time the input page should show groups of inputs.

 

Turning the Application into a Portlet

In an earlier tutorial, you should have created a model and then added a Portlet Adapter builder call to enable the application to function within the WebSphere Portal framework. In this section, you will do the same thing. If you need more information about this concept, consult the tutorial called, "Creating a Simple Portlet".

  1. Add a Portlet Adapter builder to the model.

    1. Click to add a new builder call to the model.

    2. Choose the Portlet Adapter builder and click OK.

    3. Use the following table for the details about what values to provide for the various inputs to this builder call. Click OK when you are finished.

      Input Name Value
      Name Tutorial Basics Employees
      Portlet Title Tutorial Basics – Employees Portlet
      Portlet Description Tutorial Basics – Portlet for Employee Information

    4. Click OK and save the model.

    5. Right-click the project's name and choose...

      Portal Server WAR | Build Portlet WAR

      This task can take a few moments to complete.

    Why Rebuild the Portlet WAR?

    A portlet Web Application Archive or WAR was created when you created the Web Application Project in an earlier tutorial. As changes are made to the models and profile sets in the project, these changes get redeployed on the portal server automatically.

    Some changes to a model, however, require that the portlet WAR be rebuilt. Adding a Portlet Adapter builder to a model is one of those changes. In order for the portal framework to be aware of the new portlet, the portlet WAR on the portal server must be replaced with a new one. Rebuilding the existing portlet WAR in the WebSphere Portlet Factory Designer also automatically deploys the new WAR replacing the old one.

  2. Open the Basics page and add EmployeesPortlet

    1. Log into WebSphere Portal as an administrator.

    2. Click...

      Administration | Portal User Interface | Manage Pages | Context Root My Work | Portlet Factory page | Tutorials | Basics | Open Portlet

    3. Use the search feature to find your portlet in the list.

    4. Click on the portlet and continue to hold the mouse key down.

    5. Drag the portlet to a destination on the page. A horizontal bar appears as you drag the portlet over areas on the page available for deployment. When you drag the portlet within close proximity of a permissible drop zone, the color of the horizontal bar changes from a muted to a more saturated tone.

    6. Drop the portlet to the page as appropriate by releasing the mouse key to add the portlet where you view a horizontal bar.

    7. Click Close Portlet Palette to close the Portlet Palette.

      You should now see your portlet. It should:

      • Display rows of employee data.

      • Have a link on the ID for each row of data. Clicking the link should open a details page.

        Note: When using Service Provider stubs, the detail data should be the same sample data regardless of which link you click, but the URL should contain an argument called EmployeeID that equals the ID number you clicked on to bring up the details page.

      • Contain a Create button to create new employee records.

        Note: When using Service Provider stubs, the new records will not be added to the rows of data displayed on the first page of the portlet.

 

Using Higher Order Builders

Many tasks you just learned are encapsulated in higher order builders. In order to understand these builders, it is best to learn to work with lower order builders first. This tutorial has shown you how to perform some of these tasks already.

View & Form is a higher order page automation builder. It encapsulates many other builders' functions into a simple user interface. Adding paging buttons, enabling the ability to update and display records, and generating its own main method makes View & Form a very convenient starting point for creating a data-driven application.

A common pattern for data-driven applications is to use SOA for the data integration and View & Form for the display and editing of the data. Features of the View & Form-based application can be changed by using modifier builders. Data Column Modifier, Data Hierarchy Modifier, and Rich Data Definition are a few of the most common modifier builders used with View & Form.

There is another solution model called EP_View_and_Form. This model performs more functions and has a richer UI using only a handful of builder calls. Open this model and run it. Study the contents of the View & Form builder call. As you move forward in building models and gaining more experience, you should learn to use View & Form and the common modifier builders.

Parent topic: Learning about WebSphere Portlet Factory