IBM
WebSphere Portlet Factory 8.0.0 Documentation
First Edition
Published May 2012
© Copyright IBM Corporation 1993, 2012
First Edition
Published May 2012
© Copyright IBM Corporation 1993, 2012
In keeping with IBM's commitment to accessibility, this edition of the product documentation is accessible.
This HTML file contains the latest draft of the official product documentation for this release. This draft is refreshed on a quarterly basis, as necessary. For the latest product documentation updates, refer to the release-specific articles available in the Product Documentation section of the wiki.
You can save a local copy of this document from your browser. Each browser has different menus and menu options. Consult the browser help if you need assistance saving the document locally.
If you would like to provide feedback about this document, see the Lotus Documentation Feedback Web site.
This topic lists more links to Web Experience Factory learning resources.
Web Experience Factory Designer is integrated in to the Eclipse development environment.
Web Experience Factory Designer is a tool for developing Java 2 Platform, Enterprise Edition (J2EE) Web applications, portlets, and widgets to be published to IBM Lotus Mashups.
Web Experience Factory Designer is a plugin to Eclipse-based integrated development environments (IDEs). Working in the Web Experience Factory perspective in Eclipse, you create projects, under which you use builders and profile sets to develop models and generate the resulting Web applications from those models.
Each builder has a wizard user interface through which you specify input. The builder automatically generates or modifies part of the application. Profiles in profile sets let you tailor one application and generate multiple versions, for example, a different version for different human languages or different user groups.
You assemble builders in models to implement a user interface or a data service. If you make a change in the inputs to a builder in a model, the application code is regenerated. The regeneration lets you iteratively develop an application. The builders generate all the necessary application code, including JSPs, Java classes, and XML documents. You use builders to implement design patterns to facilitate iterative development.
The IBM WebSphere® Portal server framework provides multiple services, for example, page navigation and collaboration features.
The Web Experience Factory Designer also facilitates the creation of new builders and profiles.
On the Web Experience Factory wiki you can find supplemental content about installation and developing applications. This wiki is very active, so you should check it out regularly.
We need you to share your expertise! Sign up and start contributing to this vibrant developer community.
Web Experience Factory Designer provides context-sensitive help for all features and functions. You can access help in several ways:
All Web Experience Factory Designer windows and dialogs provide context-sensitive help that describes the tasks supported by the window or dialog. To view this help, place the pointer in a window or dialog to establish context and press the F1 key.
Builder call editors provide a Help button that you can use to access configuration help for the builder.
Web Experience Factory installs a documentation plugin into the Eclipse Help system. This plugin runs within the context of the Eclipse help engine, and can be accessed from the Eclipse Help menu. To access Web Experience Factory help, in Eclipse, click . The Eclipse SDK Help window opens. Under Contents in the left pane, click IBM Web Experience Factory Designer to display the introductory page in the right pane.
This version of IBM Web Experience Factory provides many new features.
You can add to your project a feature set () to provide the support for the development of lightweight mobile web applications with a rich native look and feel.
Information in the help for the deprecated builders suggests what measures to take as a substitute (if one is possible) for these builders that are no longer available to use.
The following features have been added to Web Experience Factory Designer.
Web Experience Factory Version 8.0 is available.
For a list of the APARs that Web Experience Factory Version 8.0 has resolved, refer to the list of fixes at the following location.
For information about hardware and software compatibility, refer to the detailed system requirements document at the following location.
Web Experience Factory Version 8.0 detailed system requirements
For step-by-step installation instructions, refer to the following topic in the information center.
Known problems are documented in the IBM Support portal at the following location.
http://www.ibm.com/support/entry/portal/Overview/Software/Lotus/IBM_Web_Experience_Factory
As problems are discovered and resolved, the IBM Support team updates the knowledge base. By searching the knowledge base, you can quickly find workarounds or solutions to problems.
The following link launches a customized query of the Support knowledge base.
Discover what Web Experience Factory can do for your portal development team.
Web Experience Factory is a powerful and flexible tool for rapidly building portlets on top of a service-oriented architecture. Developers are able to quickly and easily leverage their company's core assets, automatically assembling them into custom, high-value portlets. Portlets created with Web Experience Factory are dynamic, robust Java 2 Enterprise Edition (J2EE) applications that react automatically to change, and can be further modified by business users in real time, to meet changing business requirements without requiring any coding, duplicating or versioning of assets. By eliminating the need to code all of these implementations and their variations, Web Experience Factory simplifies the development, publishing, and change management process, saving companies time and money.
The primary features of Web Experience Factory are as follows:
This section provides a technology overview of Web Experience Factory, starting with the architecture.
The first layer of the architecture stack are the data sources. Data can be sourced from a number of different systems, including databases, enterprise applications such as SAP, collaborative platforms like Domino, and historical or analytical data from products such as SAP Business Warehouse.
The next two layers – services and portlets – can both be developed with Web Experience Factory Designer. The Designer tool is an Eclipse plug-in and runs seamlessly in Eclipse-based products, such as IBM Rational® Application Developer.
The last layer is the WebSphere Portal server framework, which provides key services such as page navigation and creation tools, single-sign-on capabilities, user management, built-in process server, and collaboration features such as instant messaging.
With Web Experience Factory, developers build portlets by snapping together a sequence of components called builders. Each builder has a simple wizard-like user interface and does the work of automatically generating or modifying part of an application. A builder implements an application design pattern.
Builders are assembled in models, which are like application production lines. Each time a change is made to any of the builders in a model, the application code is regenerated, allowing the developer to iteratively develop a custom portlet application. Some builders create webapp artifacts such as a page or a table, while other builders modify the artifacts created by previous builders by rearranging, hiding or adding columns to a table. The builders generate all the application code, including JSPs, Java classes, and XML documents.
In addition, developers can create multiple variations of a portlet from one code base, without requiring additional code changes or republishing. This is done with the profiling feature of Web Experience Factory. Different profiles can be created for different user constituencies, based on any characteristics such as region, role, or group membership. The profiling technology is also used to support runtime configuration, so that business users can control application functionality through a simple browser interface. The net result is that Web Experience Factory allows companies to rapidly create adaptive applications that respond to change on demand – something traditional tools and technologies simply cannot provide.
After you create your new project or upgrade a current project, you need to complete a few more steps to see your Web application or widget in action.
To create a new model, click .
To work with sample Web applications or widgets, include the Tutorials and Samples feature set in your project and use the Project Explorer to open one of the files in the models/samples folder.
.Web Experience Factory provides a rich user interface for editing models and profiles and developing web applications.
You use the IBM Web Experience Factory perspective when you run Web Experience Factory Designer. This perspective provides special menus and other features to support editing your models and constructing web applications. Click to activate this perspective. The title of the window indicates that the Web Experience Factory perspective is in use. The perspective uses both Eclipse and Web Experience Factory views, the Model editor, and the Profile editor.
This view also allows you to manage combinations of profiles when multiple profiles are applied to the same model. It has content only when an open model is selected in the edit area. Click to display the view.
You can use the standard Eclipse Properties view to examine and change display and validation settings for fields in the model. Click to display the view.
Click to display the view. Use the dropdown list in the menu bar of the view to change what appears in the view.
Project Explorer is an enhanced version of the standard Navigator.
The Project Explorer provides project-level folder access to some of the primary project artifacts: Java source, models, and profiles. These project-level folders are provided as a convenience for working with files that are located in folders in the WEB-INF directory. This arrangement of folders lets you access the artifacts without your having to drill down in that directory. You can work with the files in these folders by navigating to them from the special project-level folders, or from the folders under WEB-INF where the resources are actually located in the project file structure.
The Project Explorer view presents a tree-based directory hierarchy that displays all the objects that comprise the current project. The Project Explorer allows you to display the complete tree of an IBM Web Experience Factory project, specify a subset of the project components to display in that tree, and perform refactoring on selected elements in the tree. You can open an object, such as a model or profile set, by navigating to it and double-clicking on it. The object is displayed in an appropriate editor.
The Model Navigator view presents a subset of the Project Explorer to let you more easily access models and profile sets defined in your projects. Click to display the view.
In both views, you can expand the hierarchy and filter the display.
To rename a model or profile set, use the command.
Project Explorer is supported in Eclipse and Rational Application Developer. Link folders for models, profiles, and Java source are provided for earlier versions of Eclipse and Rational Application Developer to allow the user to quickly locate and navigate to these resources in the standard Navigator.
You can control the types of elements that the Project Explorer displays by filtering the types that are not of interest.
To
restrict or expand the list of resources displayed in the Project
Explorer tree, click the menu icon (
) in the Project Explorer navigation
bar, then click Filters, and select or clear
the check box from the Available Filters options.
Selecting a filter turns off the visibility of that filter type. For
example, to display only the models that the project uses, select non-models to
turn off the visibility of all resources that are not models.
You can also limit the inventory of resources to be displayed by clicking Available Content in the Filters dialog and selecting resources that you want to appear in the Project Explorer and clearing resources that you do not want to appear.
The Project Explorer is displayed by default.
If you close the Project Explorer, you can display it again by clicking and then selecting .
When you open a resource in the Project Explorer, information about that resource appears in an editor in a separate pane. You open a resource by right clicking it and choosing Open from the resulting popup. For example, when you open a model, the Model Editor appears. It contains the following tabs.
If you open a profile set, the Profile Editor appears with its own set of tabs and a set of buttons that allow you to add, edit, or delete a profile in the set. To open an individual profile, you have to open the profile set and display its contents in the Outline.
You can rename builder calls in the editor.
In IBM Web Experience Factory, the profile editor lets you create and manage profile sets.
The tabs with the profile set icon (
) at the top of the Editor area of the Web Experience
Factory perspective provide
access to the project profile sets that are open for editing. The
tab with focus displays an X and populates
the content of all the views.
The Outline view in the IBM Web Experience Factory perspective displays the builder call list for the model that you selected in the edit area.
The builder call list for the currently selected model is a listing by number, name, or type, of each builder call in the model. Builder calls that are profiled display a profile icon. With icons in the view toolbar, you can readily generate the current model or add a builder call to the model.
The Outline view supports a popup menu that lets you manage a builder call in the list by selecting it and using the available commands (for example, cut, copy, and paste).
In the builder call list, you can drag and drop the builder calls to reorder them. The number sign (#) in the builder call list indicates the numeric order of the builder call. The order of builder calls in the list is important because, if a builder call is dependent on another builder call later in the list, the call fails. Disabled builder calls are greyed-out.
Under Name is the designation that you can enter as the Name input in the builder. If you do not enter a name, one is generated based on the page location or displayed as <No Name>. Under Type is the designation of the actual builder as selected in the builder picker. Another column indicates whether the builder call has an associated profile.
At the end of the View menu, a list of names suggests builders that you might want to add to your model. Simply clicking the builder name adds the builder to your model and opens the builder call editor in the editor area.
The Sort by command lets you arrange the list display in various ways. The default is numerical order. You can also click the column titles to sort the builder call list.
The command finds the builders that have inputs matching your criterion and string and displays only their calls in the builder call list. To restore the full builder call list when you are done, specify start with and an empty string and click OK.
The column that contains an arrow icon for each listed builder call lets you link to related elements in other views. Click this arrow to highlight related elements in the Application Tree and Pages views. This feature also displays and highlights code in the Source view and the related object in the Design view. If you set Link with Application Tree in the View pull-down menu, the Application Tree view, Pages view, Source view, and Design view highlighting changes each time you select a different builder call in the list. With the command set, the arrow icon does not appear in the column. The command is not set by default, because it adds performance overhead to the IBM Web Experience Factory Designer.
Use the Columns command in the View menu to control the order and appearance of the columns in the builder call list.
The builder call list contains all the builder calls that define your model.
The builder call list is rendered in the Outline view of your development environment when a model is opened for editing. The builder call list displays the sequence number, name, and type of each builder call in the model, and indicates whether or not the builder call is profiled.
You can use the builder call list to sort, filter and categorize builder calls. You can manage a builder call in the list by selecting it and using the commands (cut, copy, paste, and so on) available in the context (right-click) menu.
Disabled builder calls are greyed-out.
IBM Web Experience Factory executes these builder calls in the numeric order in which they appear in the builder call list. As each builder call executes, it adds elements to, or modifies elements in, the WebApp object.
When you generate the web application from the model, Web Experience Factory resolves any indirect references you have used for builder call inputs and supplies any profiled builder call inputs with values from the appropriate profile.
As a result of the linear execution of builder calls, the order in which you place builder calls in the list is important. For example, to reference the value returned by a method in a builder call input, add that method to the WebApp prior to the current builder call.
As you develop your model, you may add a builder call that cannot access the objects that it needs. For example, if you add or move a Data Field Modifier builder call before the Data Page builder call on whose elements it operates, the Web Experience Factory Designer displays a warning similar to the following:
Field selector "[page1]ShowEmployeeData/RowSet/Row/EMPNO" did not evaluate to any fields.
Ensure that this BuilderCall follows the corresponding Data Page BuilderCall.In this case, once you drag the Data Field Modifier builder call below the Data Page builder call, the error is eliminated.
In general, as you add builder calls to the builder call list, be aware of the dependencies one call has on another. Make sure that you do not place a call in the list that depends on a call (or call artifact) that is yet to be created. Populate the builder call list in a top down manner and make sure that any call you add to the list depends only on the builder calls above it.
You can alter the display of the builder calls in the model by using the following builder call list view options.
The builder picker lists builders available in your environment and provides you with a way to select a builder that you can add to your model. Use Show Less and Show More to expand or contract this view.
This pane provides folders to help you manage builders and find related builders. All supplied builders are assigned at least one category, and you can view the builders according to their category in the builder picker. Some builders appear in multiple categories. Categories provide a way to organize builders. For example, clicking Page Elements under Category name lists all the builders that involve creating and manipulating pages.
Use Manage Favorites to remove entries from the list.
For example, if you enter the letter p in the search box at the top of the builder pane, a scrollable dropdown list shows all keywords containing p. If you enter the keyword page, all keywords containing page are shown.
Click a keyword to have it appear in the text box and be saved in Search Results. The names of the builders associated with that keyword are shown under Builder. Click the last entry in the dropdown list (All builder keywords containing and your search term) to add the keywords to Search Results and list under Builder the associated builder names.
Expand Search Results to list saved keywords. Click a keyword to limit the list under Builder to the names of builders associated with that keyword.
Search Results is cleared when the Builder Picker dialog closes.
This pane lists builder names in alphabetical order based on your selection in Category name or by keyword entered in the search box. You add a builder to your model by selecting the name and clicking OK.
By default, this pane displays information about the selected builder so that you can decide whether it is the builder to add. The pane provides links to further information about the builder.
If you selected to not show the help tray by default, press F1 or click the question mark icon to display it again.
The builder picker lets you add any builder included in, or added to, your Web Experience Factory installation.
If you select a builder and click OK, the builder picker closes and runs the builder call editor for that builder.
You can update the list of builders available to IBM Web Experience Factory Designer.
Your list of builders in the builder picker can be updated to include other builders. Builders defined by builder definitions that are added to the WEB-INF/builders directory are listed in the All category and any other category defined in the builder definition. The following are causes for builder names not appearing in the list of builders.
You can modify the project and add the feature set. The builders then are listed in the builder picker.
You need to upgrade the project version to update the list of builders.
You can update the list of builders.
You can open the main help topic for a builder without opening the builder call editor.
In the Builder Picker dialog, click Manage Favorites to maintain a list of builders that you frequently use.
This list is stored in the Favorites folder under Category name in the builder picker.
Click the question mark icon to display in the help tray context information about the dialog.
If you right-click in the Outline view, you open a popup menu that lets you manage the builder call list and perform other operations on builder calls.
Some of the options in this menu are available only when a builder call is selected. This menu provides access to the following commands and actions.
This menu choice is useful to convert a builder to a similar type of builder that has nearly equivalent inputs. For example, to convert a Button builder to a Link builder, or a Page builder to an Imported Page builder.
In general, builder conversions should involve builders in the same category. For example, between converting from one type of builder to another within the Pages category or within the Page Elements category. Do not attempt to convert builders that are radically different in nature or design.
Inputs of the original builder are preserved and, where appropriate, intelligently applied to the new builder. For example, the Button Label input value is applied to the Link Text input. All inputs of the original builder are added to the new builder call editor.
IBM Web Experience Factory uses several panels in the editor area of the Web Experience Factory perspective to create and develop models for a web application.
Use the Project Explorer or Model Navigator view to access
and open a model in the model editor. The tabs with the model icon
(
) at the top of the Editor area of the Web Experience
Factory perspective provide
access to the project models that are open for editing. The tab with
focus displays an X and populates the content
of all the views.
When a tab displays an asterisk (*), there are unsaved changes in the model.
You can use the panels in the model editor to understand the effect of a builder call on the model, to change builder calls, or to examine the relationships among elements within the model. The panels include:
The WebApp tree is updated each time the model is regenerated.
The Application Tree lists generated elements in the open model selected in the editor area.
You can use the Application Tree in the model editor to navigate to and access a generated element. With an open model having focus in the model editor, click the Application Tree tab to expose the panel and view the WebApp folder and subfolders in which generated elements are listed by type. If the Application Tree tab is not visible, click the arrow icon on the left side of the editor area to shrink the selected panel and expose the Application Tree panel.
The generated elements for a model are displayed in tree form under the WebApp folder. Folders representing element types can be expanded and collapsed. For example, all variables in the WebApp are contained in the Variable folder. The same is true for other types of elements. This organization of generated elements allows you to easily visualize what the WebApp contains and how the WebApp changes during regeneration. For example, you can use the Application Tree to determine what a builder adds to the WebApp.
Click the companion Pages tab to more readily access page and form elements.
For each type of generated element that is selected in the Application Tree, the corresponding code is displayed in the Source panel.
Use the Source panel to examine the related code generated by a builder call or a method.
If you expand a folder in the Application Tree and click on a WebApp object, the builder responsible for creating the object is highlighted in the builder call list. Likewise, if you select a builder call in the Outline view and enable Link with WebApp Tree, the generated elements associated with that builder call are selected in the Application Tree.
The Application Tree operation is closely coupled with the Source view and the Design view.
A standard Eclipse tree filter is available at the top of the Application Tree. If you type text in the filter, an incremental search is performed. Only those resources that have the filter characters at the start of their names are displayed under the WebApp folder in their related sub-folders. If you type the asterisk character (*) first and text, those resources that have the text anywhere in their names are displayed. An icon is available to clear the filter and display all resources.
The Application Tree supports a popup menu that you can use to more readily open builders that created or can modify the selected element.
Typically, you can see the following folders in the Application Tree.
Event: OnError.main
Action: showErrorPageUse the Pages panel for more direct access to pages and forms in the model.
You can display a visual representation of your model.
If you click Design View and a non-visible item is selected in the Application Tree or no visible elements reside in the model, you see this text.
You need to have added to your model builders that create page elements.
The Design and related Pages panels in the model editor provide a graphic representation of visual elements in a model.
With the Design panel, you can change your fields and grouping of fields on pages.
The Pages panel shows thumbnail icons of all created pages and forms in the model. (The same generated elements are listed in the Application Tree.) Click the Pages tab to expose the pane. The icons let you more easily select a visible element in your model. The Views icon in the Pages toolbar lets you also display both list and details formats of the visible elements.
The Pages panel supports a popup menu that lets you more readily open builders that created or can modify the selected element.
The Design panel shows a visual representation of a visible element that is selected in either the Application Tree or the Pages panel. Clicking the Design tab exposes the Design panel. This panel lets you quickly and conveniently see visible elements in your model without having to generate the web application and lets you make design changes.
In the pane, tags are represented visually as boxes on the page. Tags appear in orange to indicate where to add a builder. The tag names are displayed in the boxes.
An arrow icon in the left side of the editor panel can be toggled to hide or expose the Application Tree and Pages panels. Hiding the other panels gives you more room on the screen to work with the builder call editor. The visual representation includes a red star and red text indicators. These show that the associated elements have an error condition that you must remove in the builder call editor. Also included are group icons that let you easily operate on aggregate elements.
The Design panel is tightly connected to the Application Tree. If you select an element in the Design panel, the corresponding element in the Application Tree is selected. Also, the associated code in the Source panel is highlighted.
The Design panel supports popup menu options and a palette that help you develop your web application. The popup menu options available depend on the context of the element selected in the panel. Right-clicking any element or the group icon in the pane displays the menu.
In the builder call editor of any builder that you add to your model from the Design panel, page and tag fields are pre-filled based on the context of the selected element.
You typically have a situation in which your data needs to be in multiple fields. However, when you display the data, you would like these multiple fields to line up on the display as fields that they occupy only one column. For example, a person's address could consist of separate city, state, and ZIP code fields. You can use the Data Field Merge builder to treat separate fields as a single field on a details page or as a single display column.
In the Design panel, you can select multiple fields to be merged, right-click, and click Merge Fields to merge the fields into the current column. The multiple fields must all be in the same container field. After you fill in the information related to the menu command, the Data Field Merge builder is added to your model and the newly merged columns are displayed.
Right-click a page automation field in the Design panel and click or . (The Validation command is available on the menu only for data entry fields.) When you change a setting, click Apply or OK.
If you right-click a column or a field in a form or page, you can use or to quickly change its display setting. The command lets you toggle the property that prevents the field or column from being displayed or lets it be displayed.
If you right-click a column or a field in a form or page, you can use or to quickly change the sort setting. The command lets you toggle the property that allows the field or column to be sorted or prevents it from being sorted.
If the model does not contain a related builder for this form or page, a recommended builder is added to the model. If a related builder resides in the model for this form or page, the related input in that builder is updated with your change.
The Source panel in the model editor shows the application code that is associated with a generated element that is selected in the Application Tree, in the Design or Pages panel, or with a selected builder call in the Outline view.
Click the Source tab to expose the panel. Use the arrow icon on the left side of the editor area expand and shrink the panel. For example, if the Application Tree and Pages tabs are not visible, click the arrow to shrink the Source panel and expose the other panels.
In the Application Tree, navigate to and select a generated element. In the Pages panel, select a page or a form. In the Design panel, select a visible element. The related source code in the Source panel is highlighted.
If you enable Link with WebApp Tree in the Outline view, selecting a builder call causes the associated elements in the Application Tree to be selected and the related source code in the Source panel to be highlighted.
In the Source panel, you see both information about the code and the code itself. To collapse and expand the information about the element, use the triangle icon to the left of the element name. Collapsing the information gives you more space for the source code display.
Which method called the current selection
Which methods the selected code calls
Use the information about the code to more readily understand the operation of the model.
The Source View and Design View tabs can show details of elements that you select in the Application Tree.
If you select the Source View tab, and the selected object in the Application Tree view does not have any source available, you see this topic. You can make the source code for elements created by builders in your model available to be displayed in the Source View.
The popup menu in the model editor (that is, in the Application Tree, the Pages panel, and the Design panel) shows in the current context both the builder that created the selected object and available builders that can modify the selected generated element.
This menu choice is useful to convert a builder to a similar type of builder that has nearly equivalent inputs. For example, to convert a Button builder to a Link builder, or a Page builder to an Imported Page builder.
In general, builder conversions should involve builders in the same category. For example, between converting from one type of builder to another within the Pages category or within the Page Elements category. Do not attempt to convert builders that are radically different in nature or design.
Inputs of the original builder are preserved and, where appropriate, intelligently applied to the new builder. For example, the Button Label input value is applied to the Link Text input. All inputs of the original builder are added to the new builder call editor.
Creates a file that contains the HTML code for the selected generated element
Creates a file that contains the HTML code for the whole page
These commands are available only for pages that page automation generates, for example, pages that the Data Services User Interface builder creates.
In the submenu for a category, click a builder name to run the builder call editor to create in the model a new builder call that modifies the element.
The categories and list of builders are not exhaustive. Thus, a certain builder might be able to create a particular element, but it would not be on the list because it would not make sense in that context.
Right-click a page automation field in the Design panel and click or . (The Validation command is available on the menu only for data entry fields.) When you change a setting, click Apply or OK.
If the model does not contain a related builder for this form or page, a recommended builder is added to the model. If a related builder resides in the model for this form or page, the related input in that builder is updated with your change.
You can use the Ctrl key and clicking to select multiple objects of the same type (either field or column) for the command.
In the Design panel, you can select multiple fields to be merged, right-click, and click Merge Fields to merge the fields into the current column. The multiple fields must all be in the same container field. After you fill in the information related to the menu command, the Data Field Merge builder is added to your model and the newly merged columns are displayed.
The Model XML panel in the model editor displays the XML for the model as it is saved on disk.
If you are creating builders, you can use the Model XML panel to examine how indirect references are resolved. Also, you can examine the schemas generated by various builders, such as the Data Page builders and Database builders.
The builder call editor allows you to specify all the input values to a builder call.
You can also reference elements in an XML structure and locate control builder calls on one or more pages in the model.
The following builder call input groups are common to many builders:
TODO Update the style for this page
FIXME Add SmartPhone supportBuilders can also have tasks added when they are called through the API. When a builder calls a target builder, the calling builder adds to the call a message with the severity indicator task. The indicated message is added to the target builder.
The message can have any text that the builder wants; but if they want the standard TODO and FIXME behavior, the message needs to start with TODO or FIXME. These tasks are displayed until the builder no longer generates these messages. This will allow builders to dynamically add tasks to assist users in advanced functionality.
Other options might be present, depending on the builder.
Most inputs to a builder call can take a value derived from an indirect reference, a Java expression, or directly from a String value. Some inputs that require a name to a specific object like a variable or model use specific choosers that filter out inappropriate elements.
In general, name builders in models using the same conventions as Java variables.
(Initial lowercase character, then an uppercase character for the first letter of each word.) For example:
Sometimes the initial lowercase rule should not be followed. For example, the Name input of the Portlet Adapter builder is used as the portlet name in the portal (not for generated web application objects), so using initial uppercase letters for this builder call name makes more sense.
The Name input for control builders (such as Button or Link builders) is generally best left blank. When this input is blank, the control builder automatically displays the name of the tag on which it is located.
The Choose Reference dialog allows you to specify the value of a model entity as the value for a builder input.
The Choose Reference dialog displays all the variables, methods, inputs, and pages from which you can choose to map the output value of the selected element to the input value for the builder call. For references to XML structures associated with a schema, the Choose Reference dialog displays all the elements as well as any attributes associated with those elements. Attributes are differentiated by an @ symbol preceding their name in the dialog tree.
The Choose Reference dialog does filter out non-valid possibilities. For example, you can set the Label input value for the button builder to be the output of a method, the value of a variable, or the value from an input on the previously submitted page. When you display the Choose Reference dialog for the Label input, it does not show the pages in the model because they are not a valid means of deriving a label for the button.
The Choose Reference dialog only shows methods that do not take arguments. When trying to supply an input with a value returned by a method, keep in mind that some builders do not support specifying arguments to a method selected in the Choose Reference dialog. If you want to supply a builder call input with the value returned from a method that takes arguments, add a method call builder call to your model, calling the method and supplying arguments there. Set the input value by using the Choose Reference dialog and selecting the method call that you just created.
You can specify values for builder inputs in multiple ways.
For example, you can use the input select box or text input control. Specifying values using these controls is straightforward. The IBM Web Experience Factory Designer also uses several types of chooser controls for specifying input values for you to select resources.
The following dialogs display selectable elements as a tree from which you can choose. For example, the Choose File dialog displays a list of files or directories that contain files. Use these dialogs to navigate to the appropriate resource.
You can use combinations of indirect reference types.
For example, you could combine a Java expression and a variable reference to derive the URL for an image:
${Java/webAppAccess.getRequestData().getContextURL()}/${Variables/ImageFileName}The ImageFileName variable contains the file name of an image.
You can also enter Java syntax for the input to a builder.
${Java/webAppAccess.getRequestData().getContextURL()}To set a text input value to the value returned by a method that takes arguments:
${Java/webAppAccess.callMethod("MethodName", arg1, arg2)}The Java node of the Choose Reference dialog also offers you some pre-defined expressions you can use.
Once you select an expression from the Choose Reference dialog it is placed in the builder input field. At this point you can edit the expression if you need to add arguments or otherwise modify it.
You can concatenate indirect references or nest them as needed.
${Variables/MyXML/XmlElement[
${Variables/IndexValue}]}To create nested indirect references:
to
display the Choose Reference dialog.The reference chooser allows you to assign the value of an element in the model to a builder call input.
The reference chooser displays all the variables, methods, inputs, and pages from which you can derive a value. When you select an item in the reference chooser, the value it returns is called an indirect reference and defines the path to the selected element in the model. For example, ${Variables/CustomerName} or ${MethodCall/GetCustomerName}.
${Variables/Customers/Customer[${MethodCall/GetIndexValue}]}The reference chooser displays the most likely model elements (for example, variables, methods, inputs, and pages) from which you can choose to map the output value of the selected element to the input value for the builder call. By default, the reference chooser purposely hides many elements that are not likely to be helpful. Click Show more in the dialog to display those elements that are initially hidden by default.
The reference chooser does filter out invalid possibilities. For example, you can set the Label input value for the Button builder to be the output of a method, the value of a variable, or the value from an input on the previously submitted page. When you display the reference chooser for the Label input, it does not show the pages in the model because they are not a valid means of deriving a label for the button.
The following are aspects of using the reference chooser:
You can directly enter an indirect reference in the reference chooser to provide access to theme properties data.
${Properties/bowstreet.Theme/property-name}<PagingButtons_NormalImage>/myfiles/images/normal.jpg
</PagingButtons_NormalImage>${Properties/bowstreet.Theme/PagingButtons_NormalImage}This syntax is available only to builder inputs that accept single values. It is not available to inputs that accept a list of values.
You can use the reference chooser to specify the value for a page control (for example, a text input or the label for a button).
Do not choose an indirect reference to a request input. For example, ${Inputs/someValue}. If the application runs in a portlet environment, it may have to render output as the result of a request to another portlet on the page. However, any controls or labels that get their values from request inputs do not have a value.
A best practice in this application is to use page automation builders, for example, Data Page builder with Data Field Modifier and Data Column Modifier builders. Alternatively, you can specify the value for the page control from a variable.
The reference chooser shows methods which can provide a value for a builder input.
If you select a method which requires arguments, a popup dialog will prompt you to supply arguments to the method. The method arguments that you supply may be hardcoded arguments, or may themselves be indirect references to other methods or variables.
You can concatenate indirect references or nest them as needed.
For example, if the index of an XML element to use as the value for the builder call input is determined by another variable, the nested indirect reference would look like:
${Variables/MyXML/XmlElement[${Variables/IndexValue}]}You can enter Java syntax for the input to a builder.
${Java/webAppAccess.getRequestData().getContextURL()}To call a method named MethodName that takes two arguments:
${Java/webAppAccess.callMethod("MethodName", arg1, arg2)}You can use combinations of indirect reference types.
${Java/webAppAccess.getRequestData().getContextURL()}/${Variables/ImageFileName}The ImageFileName variable contains the file name of an image.
You can supply any builder input that accepts a comma-delimited list with any object that implements java.util.Collection or extends java.util.Iterator, thereby populating the builder input value with the items in the underlying collection.
${Java/webAppAccess.getRequestInputs().getInputValues("myInput")}You can add your own expressions to the Java node of the Choose Reference dialog.
You might want to do this to keep frequently used expressions available from within the dialog. To populate the Choose Reference dialog with an expression, you must add a line defining the expression to the ../WEB-INF/config/IndirectJavaExpressions.config file. For example:
You can use a dialog to help you specify a model as a builder input.
Many builders have a Model input that requires
you to specify a model. Clicking the ellipsis button () displays the Model
Chooser dialog in which you can navigate to and select a model. By default,
the specification of the model location used in the builder is an absolute
reference to the model.
There is an option (Use relative model reference) to make the model reference be a relative reference. Thus, the reference from model A to model B is based on the location of model A within the models folder. With a relative reference, if you move or copy both models together from one folder to another, the new copy of model A refers to the new copy of model B. With an absolute reference, the new copy of model A would still refer to the original copy of model B in its original location.
Builder call editors support the most commonly used reference methods and syntax.
A Web application includes a set of runtime entities, for example, variables, methods, and service calls. You interconnect these Web application elements by building references from one to another. References can be made in several ways. However, you may find that you need a combination of indirect references to provide the appropriate input value or that you need to get the value for an XML element using an XPath-like notation.
To use alternative forms of input, you need to know the correct syntax to specify the builder inputs. The information in the following sections describes the types of input available and provides examples of the syntax you must follow to use a specific input type:
You can use an indirect data reference in a model. For example, you can use as the input to a builder a value that is entered by the user and that is stored in a variable. You accomplish this with an indirect data reference to the variable.
The syntax for an indirect reference requires the dollar sign $ followed by a pair of braces, as follows:
${...} The braces surround the source of data. In the following button label example, you can use the value of a variable named ButtonLabel in the Button Label input by entering the following data reference:
${Variables/ButtonLabel}You can enter Java syntax for the input to a builder. IBM Web Experience Factory arranges for the Java expression to be executed at runtime to provide the builder input value. You can use a Java expression for indirect references to specify an element in the Web application that the chooser or builder call editor does not directly support. For example, to supply the input with the URL to the Web Experience Factory, you can use the following Java expression:
${Java/webAppAccess.getRequestData().getContextURL()}The following expression sets a text input value to the value returned by a method that takes arguments:
${Java/webAppAccess.callMethod("MethodName", arg1, arg2)}To derive the value for a page to import, you can use combinations of indirect reference types with an indirect reference similar to the following:
${Java/webAppAccess.getRequestData().getContextURL()}/${Variables/PageToImport}The PageToImport variable contains the name of a page to import.
The location in which you locate and create your project contains all of the HTML pages, generated JSP pages, and other servable resources and is referred to as the servable content root directory. When you develop Web applications that may be published or exported in multiple application contexts, use thewebAppAccess.getRequestData().getContextURL() method to ensure that any references you make to servable resources are flexible enough to allow for all application contexts. See Use of a Java expression. To make references to servable resources flexible, use the method webAppAccess.getRequestData().getContextURL() when referring to servable resources in methods or in builder call inputs. For example, you could enter the following as the value for the Page to Import input for the Imported Page builder:
${Java/webAppAccess.getRequestData().getContextURL()}/pages_to_import_dir/MyPage.htmThis syntax always evaluates to the pages_to_import_dir directory regardless of the application context in which this model runs.
To access data that results from a method call, you can use an indirect data reference. You can use any method call or method that takes no arguments. However, the method must return a value so that you can reference it. You can also concatenate the results of a method call with other method calls or strings. The syntax for this type of indirection is:
${MethodCall/methodName}To select a method to reference, use the reference chooser, which displays a tree that includes a section called Method Call. The displayed section lists the action lists, methods, and method calls of the model that can be used.
Note that you cannot navigate to the results of the method as you can with an XML variable. For example:
${Variables/Customers/customer[2]/name}Consider using an indirect data reference to a method if additional processing on data is needed or if processing could not take place previously. An example of the use of the indirect reference to a method is in the Repeated Region builder. Normally, it is hard to do any processing inside the execution of this builder. By using an indirect reference to a method, however, you can do the processing. For example, you can use a method call to alternate the background color of table rows. Create a method called getRowColor that returns each color every other time. Then, to set the background color, make a call to this method inside the property setter that you attach to the table row.
To enter a string of text as a builder input, you can type the string directly into the input area. In addition, for any input that takes a string, you can concatenate multiple strings. For example, in the Value input for a Formatted Text builder, you can enter the entire following line:
The values of Foo and Bar are: ${Variables/Foo} and ${Variables/Bar}When the Text builder is regenerated, the two ${...} regions are replaced with the appropriate string value from the variables being referenced if they have values.
Using a similar technique, you can also nest the indirections. If you have a variable named FooOrBar which has either the text Foo or the text Bar as its result, you can have the following line:
The value of ${Variables/FooOrBar} is "${Variables/${Variables/FooOrBar}}"The quoted part evaluates to the string stored in either Variables/Foo or Variables/Bar, depending on the value of Variables/FooOrBar. Thus, given the following values:
Variables/Foo: dataVariables/Bar: stuff
Variables/FooOrBar: BarThe result of the expression in the line above is:
The value of Bar is "stuff"Often the one level of reference described in Concatenation of indirect reference values does not support your need for data access and manipulation. The indirect referencing mechanism can be further extended.
You can refer to a component in a list by using bracket characters [ and ] in the syntax. See Reference to a subelement in an XML structure. You can use this syntax in combination with the indirect referencing mechanism to access a component in a list. For example, a variable named TableData has a number of children, which are all named Row. Each of the children has more data below it, such as Name and Address. You can access the name in the third row by specifying the following code:
${Variables/TableData/Row[2]}Note that indices are zero-based, so that index 0 is the first, and index 1 is the second.
If the variable TableData also has other children, the above example can select the third row and ignore any other children. To refer to the third child of TableData, use an asterisk (*) to represent any child:
${Variables/TableData/*[2]}You can also specify the index itself with another variable. For example, a specific row of the table is specified by a variable of RowIndex. The current row can be specified by the following syntax:
${Variables/TableData/*[${Variables/RowIndex}]}You can use the / character to walk down a tagged data string and access an element. You can also combine this technique with an indirect reference to select a subelement, the name of which is stored in a variable. For example, the variable Data has as subelements Name and Address, and the variable WhichOne has as its value either the word Name or the word Address. Thus, the following reference returns the value stored in ${Variables/Data/Name} or the value stored in ${Variables/Data/Address}, depending on which of the two values is in the variable WhichOne.
${Variables/Data/${Variables/WhichOne}}These techniques can be combined. Use the Table Data example in List index references and use of brackets. If you have an additional variable ColumnName which selects which column should be accessed, the following syntax gets the cell data for the selected column in the selected row:
${Variables/TableData/*[${Variables/RowIndex]/@ColumnName}You can walk the structure of an IXml object returned by a service call or by a method and stored in variables. The following examples illustrate techniques you can use to create filters that find elements within an XML document.
All the examples are based on the following example XML code segment:
<Employees>
<Employee age="25">
<Name>John Smith</Name>
<Address>14 Park Lane</Address>
<City>Portsmouth</City>
<State zip="03801">New Hampshire</State>
</Employee>
<Employee age="21">
<Name>Ted Jones</Name>
<Address>26 Harbor View</Address>
<City>Hampton</City>
<State zip="03802">New Hampshire</State>
</Employee>
<Employee age="35">
<Name>Jill Jeffries</Name>
<Address>100 Oak Lane</Address>
<City>Exeter</City>
<State zip="03803">New Hampshire</State>
</Employee>
<Employee age="40">
<Name>Josh Vanderwall</Name>
<Address>45 Maple Ave.</Address>
<City>Bedford</City>
<State zip="03804">Massachusetts</State>
</Employee>
</Employees>The following reference finds a specified element name:
${Employees/Employee/Name}This expression returns the first matching element. In this example, the element returned is <Name>John Smith</Name>.
The following reference finds the second instance of an element with the name Name:
${Employees/Employee/Name[1]}This expression returns the matching element specified by the zero-based index number. In this example, the element returned is <Name>Ted Jones</Name>.
Note that you can also use an indirect reference in this situation. For example, you can enter:
$Variables/Foo/Bar[${Variables/Index}]The expression locates an element stored in a variable at a particular index.
The following reference finds the element instance of Name, where the text value equals Jill Jeffries:
${Employees/Employee/[Name=Jill Jeffries]}This expression returns the matching element specified by the element text. In this example, the element returned is <Name>Jill Jeffries</Name>.
The following expression finds the instance of Employee where a specified attribute value equals 40:
${Employees/Employee[@age=40]}This expression returns the matching element specified by the attribute text. In this example, the element returned is:
<Employee age="40">
<Name>Josh Vanderwall</Name>
<Address>45 Maple Ave.</Address>
<City>Bedford</City>
<State>Massachusetts</State>
</Employee>To find the instance of Name (where the second-level element is unknown), use a wild card * to specify the element name.
${Employees/*[2]/Name}This expression returns the matching element specified by index number. In this example, the element returned is:
<Name>Jill Jeffries</Name>The following syntax finds the parent element of State where a specified attribute zip value equals 03804:
${Employees/Employee/State[@zip=03804]/..}This expression returns the matching parent element specified by the attribute text. In this example, the element returned is:
<Employee age="40">
<Name>Josh Vanderwall</Name>
<Address>45 Maple Ave.</Address>
<City>Bedford</City>
<State zip="03804">Massachusetts</State>
</Employee>This information describes how to execute model actions.
You can run another model by instantiating a model instance, retrieving a WebAppAccess object for that model instance, and calling the model main method. The getModelInstance() method takes three arguments:
To name more than one profile, separate the profile names with a plus sign (+), as shown: ProfileSetName!ProfileName+ProfileSetName!ProfileName
Web Experience Factory instantiates singleton models once per session. For non-singleton models, Web Experience Factory instantiates them for each request.
The following code sample shows how to run another model from a method:
WebAppAccess remoteWebAppAccess =
webAppAccess.getModelInstance("myModels/ModelName", "Region!Southwest", "false");
remoteWebAppAccess.callMethod("main");You can display a page in the current model simply by calling the processPage() method on the current WebAppAccess object.
webAppAccess.processPage("pageName");To display a page in a linked model, you make a call to processPage() similar to:
webAppAccess.processPage("LinkedModelName.pageName");To display a page in another model, see the code for running another model from a method. Instead of calling callMethod() on the remoteWebAppAccess object, call processPage(), supplying the page name as the argument.
webAppAccess.processAction("ServiceCallName.invoke");webAppAccess.processAction("ActionListName");You can call methods in the current model or linked model with the callMethod() method. You can pass arguments to the method as a comma-separated list after specifying the method name, as shown below:
You cannot directly execute a method that takes arguments via a URL. You can however, add the arguments as name and value pairs to the URL and extract those argument values from the WebApp's RequestData object. The code sample below extracts the argument values passed in the following URL:
http://localhost:7001/Factory/webengine/URLTester/Action!MethodFielder?name=Tom&id=111?method=MethodWithArgsBody of method in LJO class:
public void MethodFielder(WebAppAccess webAppAccess) {
String name = webAppAccess.getRequestInputs().getInputValue("name");
String id = webAppAccess.getRequestInputs().getInputValue("id");
String method = webAppAccess.getRequestInputs().getInputValue("method");
webAppAccess.getVariables().setString("Name", name);
webAppAccess.getVariables().setString("ID", id);
webAppAccess.callMethod(method, name, id);
}LJO Methods and Method builder calls access inputs submitted by FORM POST or URL query parameters, by the RequestInputs interface, or direct arguments to the method.
Methods called via URL should take no (zero) arguments or just a WebAppAccess argument, and should retrieve inputs from the HTTP Request via the RequestInputs interface.
To retrieve a reference to the current instance of RequestInputs for a WebApp request, you would call:
RequestInputs requestInputs = webAppAccess.getRequestInputs();For example, to get all inputs from a Checkbox Group input, you may do something like the following:
Iterator inputs = webAppAccess.getRequestInputs().getInputValues("MyCheckboxGroup");
while(inputs.hasNext()) {
//process input values here
}You can store objects in the session by setting attributes on the session and specifying the value for those attributes as the objects that you want to share between models.
webAppAccess.getHttpServletRequest().getSession().put("companyname", webAppAccess.getVariables().getText("companyname"));String companyName = webAppAccess.getHttpServletRequest().getSession().get("companyname");webAppAccess.getHttpServletRequest().getSession().remove("companyname");Methods do the work of processing form inputs, executing other parts of the web applications (even other web applications), and performing any other logic that the WebApp requires to function the way you want it to.
The primary object used in methods is the WebAppAccess object, which is an instance of the com.bowstreet.webapp.WebAppAccess class. The WebAppAccess object serves as a proxy to the WebApp's structure, represented by the WebApp object, which is an instance of the com.bowstreet.webapp.WebApp class.
You can generate the URL for actions in the current model or in another model.
webAppAccess.getActionURL("actionName");/appcontext/servletname/models/path/to/models/Action!actionName/MyApp/webengine/test/TestModel/Action!getCustomerswebAppAccess.getURLMapper().getURL("ModelName", "GetCustomers",
"Region!Northeast$ServiceLevel!Gold", null);/MyApp/webengine/method/MethodTest2/
Action!main/Profile!Region!Northeast$ServiceLevel!Gold You can get the values of IBM Web Experience Factory properties stored in the cluster.properties and bowstreet.properties files.
Access the com.bowstreet.util.SystemProperties object returned by a call to webAppAccess.getSystemProperties(). Using the SystemProperties object, you can access information such as the directory path to the document root, the URL to the server, and other information. Call the following methods:
AppServerDeployDir\MyApp.ear\MyApp.warAppServerDeployDir\MyApp.ear\MyApp.war\WEB-INFhttp://127.0.0.1:9080/MyApphttp://127.0.0.1:9080/MyApp/webengineYou can access all of the variables in the web application by calling the webAppAccess.getVariables() method.
webAppAccess.getVariables().getXmlElement("VariableTest", "customers/customer[1]");The following code sample removes the second <customer /> element from the <customers /> structure:
IXml customers = webAppAccess.getVariables().getXml("CustomerList");
customers.removeChildElement(customers.findElement("customers/customer[1]"));IXml customers = webAppAccess.getVariables().getXml("CustomerList");
customers.setText("customers/customer[2]/name", "NewName");You can access the HttpServletRequest object by calling the webAppAccess.getHttpServletRequest() method.
See the Javadoc for the javax.servlet.http.HttpServletRequest class in your JDK installation for a complete description of the public methods.
Use the HttpServletResponse object to modify the content type of the data returned by a method.
This object sets the ContentType of the response to something other than text or html.
You can also add headers to the response or otherwise modify the response to the client.
For example, the following code sample sets the ContentType of the response to return an Microsoft Excel spreadsheet:
public void setContentTypeXL(WebAppAccess webAppAccess) {
webAppAccess.getHttpServletResponse().setContentType("application/msexcel") ;
try {
File excelSheet = new File(webAppAccess.getSystemProperties().getDocumentRoot()+
File.separator + "Schedule.xls");
int numFileBytes = (int)excelSheet.length();
byte[] fileBytes = new byte[numFileBytes];
BufferedInputStream bis = new BufferedInputStream(new FileInputStream(excelSheet));
int i = 0;
while(i < numFileBytes){
fileBytes[i] = (byte)bis.read();
i++;
}
webAppAccess.getHttpServletResponse().getOutputStream().write(fileBytes);
}
catch (IOException ioe) {
System.out.println(ioe+"Cannot find file.");
}
}See the Javadoc for the javax.servlet.http.HttpServletResponse class in your JDK installation for a complete description of the public methods.
You can specify a variable to be one of the types in this file.
<customers>
<customer>
<name>Jane</name>
<id>1112</id>
</customer>
<customer>
<name>Jane</name>
<id>1112</id>
</customer>
</customers>In addition, you can specify a variable to be of a type defined by a schema. These types are displayed in the Variable Type Chooser. If you select a type defined by a schema, be sure to choose from the schema's Type folder and not its Element folder.
Use the reference chooser to create a nested indirect reference.
. The reference chooser window
opens.Many builders provide inputs in tables, from which you delete a row to remove the related input value.
If you remove a row from a table in a builder input, for example, in an Action List builder, it is important to use the correct technique so that the input related to the row is not considered null.
If you delete the contents of the row without removing the row, the builder considers the input null.
You can have the builder call editor open in a separate window from your IBM Web Experience Factory Designer window.
The next time that you start the Workbench and add a builder to your model, the builder call editor opens in a separate window.
You can display web feeds from information sources without leaving Web Experience Factory Designer.
The Web Experience Factory web resources view connects you to additional product information and resources, for example, the product wiki.
When you open the Web Experience Factory web resources view, the internal Eclipse browser connects to the Web Experience Factory product wiki on the internet. By default, the browser opens at the home page of the product wiki. On this home page are links to categories of information, for example, articles that contain recommendations to help you have the best experience with the Web Experience Factory family of products. There are also links to product information sources and other related wikis.
In the product wiki, community members contribute their experience-driven expertise. The community includes customers, business partners, and IBMers from around the world. Not only can you learn from the active community’s experience, you can share your knowledge with the community.
In the Web Experience Factory web resources view, the toolbar at the top lists other resources. For example, you can click Samples and techniques, the section of the wiki that contains samples and articles on techniques that you can adapt for your applications. Icons in toolbar let you navigate in the browser.
You can also use the Help menu to access the Web Experience Factory web resources view. Click and select one of the options.
The Resource Log view displays significant events in current project session.
This view shows the results of the last Add or Remove Feature Set (or WebApp) operation performed in this Eclipse session. The view displays a list of all the files that have been removed, modified, and added to a project, and any errors that occurred as a result of those changes because of the most recent copy or remove operation. Use this view to track the activities that have taken place within the current development session. When Eclipse is restarted, the view is cleared.
Click to display the view. The view opens in the Task view area of the Web Experience Factory perspective.
The View menu provides filtering and copy options. The set of events displayed in this view is categorized into the following filtering types available within the view menu.
In addition to the event filtering options, the Resource Log view popup menu provides a copy operation. Copy places the view contents on the clipboard as text (lines separated by a Return and Line Feed character combination).
Copy is handy for providing a comprehensive record of project activities. For example, if you have a situation that requires several files to be overwritten and for some reason they are not, copy allows you to get a list of those files for future reference. In addition, you can manually copy and paste file names into other commands to complete the overwrite process.
Here are all the types of events that are logged in the view, along with how they are rendered in the view.
You can create a IBM Web Experience Factory Model configuration type.
In IBM Web Experience Factory Designer, you can set the run configuration properties.
These properties are used when you run a model from within Web Experience Factory Designer.
The standard Eclipse Run Configuration dialog lets you define the parameters that are used when running (launching) a program from within Eclipse environment. Running a model is a distinct run configuration type. Therefore, you must define a new run configuration of type Factory Model before you can run a model.
You can configure the Factory Model type to run as:
As part of the Run configuration, you supply information about the Web Experience Factory server on which to run the model, and the type of browser to use. You can also specify whether you want Web Experience Factory server tracing turned on.
This table describes the property values that you can set in the various tabs of the Run Configurations dialog.
| Main Tab | Description |
|---|---|
| Model to run | You can configure the Factory
Model type to run in one of two modes:
Note: When you choose a mode for the run named model you must
also select a project.
|
| Server Tab | Description |
| Server Host | Enter the host name of the server running the IBM Web Experience Factory servlet to which you want to connect. You can use localhost if the Web Experience Factory servlet and Web Experience Factory Designer are on the same machine. |
| Server Port | Enter the port number on
which Web Experience
Factory listens
for requests. Example: 9080 |
| Browser Tab | Description |
| Browser Command | Enter the path to the web browser to run when running models. |
| Tracing Tab | Description |
| Run with system tracing | Enable this checkbox to print system tracing information about the method and page actions whenever you run a model. |
| Common Tab | Description |
| Type of Run configuration | This field defines the location
of the file with the Run configuration settings:
|
| Perspective to switch to or open when Runed in | Models are Runed in run mode
(debug mode is not supported). In run mode, the program executes, but the
execution may not be suspended or examined. This field lets you choose which perspective becomes active when the Run configuration is Runed. |
| Display in favorites menu | Check the Run box to specify that the Run configuration should appear in the Run favorites list. |
In some cases you might need to change the server configuration.
To delete a IBM Web Experience Factory Model configuration type:
You can share the project resources among developers.
You can create or install an IBM Web Experience Factory archive file. An archive file is a special compressed file that you create using the Web Experience Factory Export/Import Wizard. This wizard is integrated into the and menus in Web Experience Factory Designer. An archive provides a way for you to easily collect and distribute project components.
IBM Web Experience Factory Designer provides a wizard that you can use to export and import project resources.
You might want to export and import project resources to share resources with another developer. You can use this wizard to create a Web Experience Factory archive Zip file.
A Web Experience Factory archive is a Zip file you use to package resources for sharing. This file is automatically constructed by the Web Experience Factory Export wizard. These special-purpose wizards are incorporated into the Eclipse Export/Import menu.
All resources that are saved to the archive file are relative to the project servable content directory (the project root directory).
IBM Web Experience Factory applications are simply a coordinated set of files that are used to regenerate applications at design time, when you publish to development servers, or export a completed project to a production server.
Like most portlets, web applications and widgets, Web Experience Factory applications are distributed (or published) as WARs.
Everything needed to run the application is packaged in the WAR build process, including profile sets. The self-contained WAR file can thus be distributed or published to any appropriate server and expected to run.
You can use two basic approaches when translating this project structure to source control.
This approach is useful if the projects have only loose coupling (for example, http connections). Artifact names should be chosen to avoid collisions if the created artifacts are to be brought more close together (in a common build). If there is to be a common build, a build process will be needed.
This approach is useful when several people are working on different parts of one application. Each developer has a copy of Web Experience Factory and checks his work into a common source control area. Every team member can easily populate their project with all artifacts if necessary, and name collisions are easier to avoid.
In both cases, mirroring the structure of the project in source control allows easy traffic between your source control system and the project.
If you want the ability to recreate the application over the long term, it is important to capture all of the artifacts used by the project.
At a project level, you have the following choices for what to place under version control.
Only your source files and generated files remain in the project. You can check in the generated files (not recommended) or they can easily be created from the source later if you are trying to reproduce this exact environment. Generated files are located in the WEB-INF/factory/generated/ folder. Using this technique, you can have source files in source control and have each developer install the same version of Web Experience Factory and any other shipping software needed for the project.
If you use a Shared Team Project in source control and check in only new or modified files, setup a Proto-Project in your source control system that contains all the artifacts you share across team members and do not expect to modify (Jars, builder defs, properties). That way you can create a project for a new team member by simply combining the Proto-Project and the Shared Team Project. There are many variations across these two dimensions (what to capture and how to shape it), of course.
At the very least, these are the project artifacts you should store in your source control system.
Do not capture or store in source control the following artifacts.
IBM Web Experience Factory provides a default selection of files that are excluded from source control.
The Eclipse development environment supports setting folders and files that are by default excluded from source control. Web Experience Factory integrates with the standard team function of Eclipse by providing a list of folders and files to be excluded from source control. To see the list, in Eclipse, click and note the entries that begin with */WebContent. These entries are provided by default by Web Experience Factory.
Using the controls in the Preferences dialog, you can modify the list according to your project needs. Also, you can override any entries in the list through the source control commands that you use.
This document describes the structure and behavior of WebApp objects in the IBM Web Experience Factory system.
The information in this document is useful for:
A WebApp is the executable result of generation for a WebApp parametric model. The WebApp elements are the fundamental building blocks that are available for builders to use when generating an application.
A WebApp represents all or part of a J2EE web application, and includes:
This information describes the WebApp runtime environment process as well as the APIs that are to be used by a WebApp application developer.
It is important to understand the WebApp execution path, and the WebApp execution time actions.
Internally there are two types of actions that get processed in the running of a WebApp.
To get a better understanding of the WebApp runtime environment it is good to have an understanding of the execution path for an individual request.
Here are the high level steps for a subsequent request to the WebApp request made above for the same requester.
The WebAppAccess is the programmer's interface into the running application.
Through this interface the programmer can access and modify all of the runtime components that are instance specific such as variables, linked Models and linked Java objects. Components that cannot be modified (read-only) are pages, methods, system event listeners and error handlers, which can be accessed through the WebApp interface. The WebAppAccess interface API is available to the developer in methods, LJOs, and JSP pages. WebApps, variables, and linked models can be accessed through the WebAppAccess API.
In IBM Web Experience Factory, you can incorporate Java code into your application in multiple ways.
You use the WebAppAccess object to program the Web Experience Factory runtime and APIs. For more information about Java use inWeb Experience Factory, refer to the article Using Java in your Web applications in the product wiki.
The WebApp is the result of the generation process. If the model you created is profiled then a unique version of a WebApp will be created as required. The WebApp contains all of the structural data required to run the application.
The components that are contained on a WebApp are pages, methods, action lists, variables, linked Java objects, linked models, system event listeners, and error handlers.
When a WebAppAccess is instantiated for the first time the runtime modifiable components of the WebApp are copied from the WebApp to the WebAppAccess object. These components are variables, linked models and linked Java objects. This allows the WebAppAccess to modify those items without corrupting the shared WebApp object.
WebApp webApp = webAppAccess.getWebApp();Linked models provide a mechanism for the WebApp developer to reuse and share model functionality among other WebApps.
By linking a model, you expose to the model requesting the linking the linked-in model's public functionality, such as methods or pages.
To add a linked model, you use the Linked Model builder to specify which model to link in. The Linked Model builder adds a named slot into your model, which contains information about the model being linked in. The example below shows model A linking in model B using LM1 as the local linked model reference name.
The name of the builder is used as the prefix name that must be used to access the linked model functionality. For example, if you added a linked model where you have specified LM1 as the builder name, you refer to a page in that model by using the Linked Model builder name, a period (.) separator, and the page name.
webAppAccess.processPage("LM1.HomePage");You also use a similar format for calling methods on the linked model.
String value = webAppAccess.callMethod("LM1.doWork");When models are linked in, you can create a single instance of the model that is shared within a session or specify that the linked model is not shared within the session. If the linked model is not shared, multiple instances of the model are created if it is used by more than one Linked Model builder.
When a linked model is specified to be Non-Session Singleton, multiple instances of this model are created for a given requester session.
Other linked models that reference the same model get their own unique instance. In the non-singleton mode, the linked in models are not stored in the requester's session but instead are held, as a reference, in the model that linked them in. For example, if model A and model B link in model C, there are two instances of model C created for a given session. The linked model slot in the parent model refers to each instance.
Because there are multiple instances of model C and there is not a reference to it in the user's session, links in the pages of model C need to point back to the highest singleton parent model in the chain. For example, if HomePage contained a link to the model doWork method, the link looks like this:
/webengin/A/Action:LM1.doWorkIf we add another linked model and model C now links in model D and you want a page in model D to link to its main method, the link looks like this:
/webengin/A/Action:LM1.LM2.mainIn this example, LM2 is the builder name of the linked model added to model C.
When a linked model is specified to be Session Singleton, only one instance of this model is created for a given session.
Because there is only one instance of model C and there is a reference to it in the requester's session, links in the pages of model C can point directly back to itself for internal actions. For example, if HomePage contained a link back to the model doWork method, the link looks like this:
/webengin/C/Action:doWorkA WebAppAccess of a linked model can be used to set or change the instantiated model that is associated with a linked model slot.
// create or get a singleton instance of model "C"
WebAppAccess modelC = webAppAccess.getModelInstance("C", null, true);
// Get the linked model slot holder
LinkedModel linkedModel = webAppAccess.getLinkedModel("LM1");
// Now set the instance on the linked model slot
linkedModel.setLinkedModelInstance(modelC);Now when calls to LM1 are made they will go to the new model. This assumes that when you swap out linked models you replace them with models that contain the same methods/pages that may be called.
In some cases you may want to free the reference to a linked model so that the JVM garbage collection will reclaim the memory used by the linked model.
WebApp methods and action lists are converted into a generated Java class that represents all the WebApp methods and action lists.
There will be one Java class generated for each unique instance of the WebApp. The name of the generated class will be the WebApp name plus a unique suffix, which is used to identify the profile data that was used to generate the WebApp.
If you are in a WebApp method or another LJO you can make a call to an LJO method in one of two ways.
webAppAccess.callMethod("MyLJO.doWork", "foo");In this example the actual signature of doWork is as follows:
public void doWork(WebAppAccess webAppAccess, String name);Calling it through the callMethod(..) automatically passes the WebAppAccess as the first argument.
You can also get an instance of the LJO and make the call directly like so:
SampleLJO myLJO = (SampleLJO)webAppAccess.getVariables().getObject("MyLJO");
myLJO.doWork(webAppAccess, "foo");If the LJO has been specified to be used as the base class of the generated method class then you may call the method directly without using the linked Java object builder name as the prefix (without "MyLJO.").
webAppAccess.callMethod("doWork", "foo");If you are in a WebApp method or an LJO you can make a call to a linked model LJO method by using the WebAppAccess callMethod(..) method just as you would for a WebApp method, except that in the method name, you must specify the name of the linked model builder call, plus the name of the LJO builder call in the linked model, as well as the method name on the LJO.
webAppAccess.callMethod("MyLinkedModel.MyLJO.doWork", "foo");In this example the actual signature of doWork is as follows:
public void doWork(WebAppAccess webAppAccess, String name);Calling it through callMethod(..) automatically passes the WebAppAccess as the first argument.
You can also get an instance of the Linked Model and use callMethod(..) on the Linked Model WebAppAccess like so:
WebAppAccess linkedWebAppAccess = webAppAccess.getLinkedModel("MyLinkedModel");
linkedWebAppAccess.callMethod("MyLJO.doWork", "foo");Or you can go directly to the LJO instance and make the call.
WebAppAccess linkedWebAppAccess = webAppAccess.getLinkedModel("MyLinkedModel");
SampleLJO myLJO = (SampleLJO)linkedWebAppAccess.getVariables().getObject("MyLJO");
myLJO.doWork(linkedWebAppAccess, "foo");Calling a method from your java code can be done two ways depending on where you are making the call from.
webAppAccess.callMethod("doWork", "foo");public void doWork(WebAppAccess webAppAccess, String name);Making a call through the callMethod(..) method automatically passes the WebAppAccess as the first argument.
doWork(webAppAccess, "foo");If you are in a WebApp method or an LJO, you can make a call to a linked model method by using the WebAppAccess callMethod(..) method just as you would for a WebApp method, except that in the method name, you must specify the name of the Linked Model builder call as well as the method name.
webAppAccess.callMethod("MyLinkedModel.doWork", "foo");In this example the actual signature of doWork is as follows:
public void doWork(WebAppAccess webAppAccess, String name);Calling it through callMethod(..) automatically passes the WebAppAccess as the first argument.
If your IBM Web Experience Factory application utilizes more than one model for its functionality, you may need to send data from one model to another.
There are multiple ways to communicate between models.
Events are named broadcasts which arrive at any model in the session (for example, for the same user) that is listening for them. There are two types of events: general events and widget events.
An event can be declared to have arguments, and the values are specified when the event is fired. For general events, it is important that all users of a given event declare it the same way.
For general events, put your Event Declaration builders in a single model and then import that model into any others that want to fire or handle the events. Events are named broadcasts across the session. Any other model that the same user is running at the time the event is fired can catch that event.
When you include an Event Declaration builder in a model, either directly or through an Imported Model builder, the builder creates, in your WebApp, a method called fireXxx, where Xxx is the event name. This method has the correct arguments, as defined in the Event Declaration builder.
To handle an event, create a method with the same arguments as the Event Declaration and then create an Event Handler builder to tell the system to route that named event to that method. If your model is instantiated, it listens for any model (including your own) that fires that event. Events are a good technique for communication when you know that a certain model (or type of model) exists, but you do not have a direct link to it.
For widget events, use the Widget Event builder input to specify whether the widget fires, handles, or both fires and handles the event. Specify how to handle the event in the same dialog box.
You can store session data in a simple map, so two different models can share the same object just by using the same key.
Models can store data in the session by using the getWebAppData method on the WebAppAccess object. The data is stored in a simple map, so two different models can share the same object just by using the same key.
Use the methods in the linked model to send data from the primary model to the linked model or to retrieve data from the linked model.
When one model refers to another model by using a Linked Model builder, the first model can access the public methods of the linked-to model in the same way that it accesses its own methods.
The primary model invokes, either in an Action List or in a Method, the public method by specifying it as <Linked Model Name>.<Public Method Name>.
You can use the methods in the linked model to send data from the primary model to the linked model or to retrieve data from the linked model.
IBM strives to provide products with usable access for everyone, regardless of age or ability.
This product uses standard Microsoft Windows navigation keys.
For more information about IBM and accessibility, see the IBM Accessibility Center.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">Accessibility features help users who have a physical disability, such as restricted mobility or limited vision, to use information technology products successfully.
Use the High Contrast mode setting if you want Windows to use color and fonts that are designed for easy reading. Eclipse was tested for High Contrast using 1152 x 864 resolution in Microsoft Windows XP High Contrast mode. You can use the tested resolution or higher for High Contrast mode.
To use the High Contrast mode, open the Windows Control Panel, double-click Accessibility Options to open the Accessibility Options dialog box, click the Display tab, and then select Use High Contrast.
Eclipse provides a set of key bindings that can be used within the Eclipse workbench. Eclipse defines key bindings as the association of key combinations and commands that invoke the commands. To view a list of available Eclipse key bindings that can be used while working in Web Experience Factory Designer, click or type Ctrl+Shift+L. For more details about Eclipse key bindings, see the Workbench User Guide in Help.
This product uses standard Windows navigation keys. For information on accessibility features and keyboard navigation in Eclipse, see the Workbench User Guide in Help.
| Keyboard combination | Action |
|---|---|
| F10 | Access menus in menu bar |
| Right Arrow | Navigate to the right in menu bar |
| Left Arrow | Navigate to the left in menu bar |
| Down Arrow | Navigate down menu options in selected menu |
| Up Arrow | Navigate up menu options in selected menu |
| Shift+F10 | Open context menu for current view |
| Ctrl+F10 | Open drop-down menu for current view |
| Alt+mnemonic | Open mnemonic's corresponding menu and menu option in menu bar |
You can use keyboard navigation to navigate between all views and editors. When you navigate between views and editors, Web Experience Factory Designer remembers the last item that was selected, so you can quickly navigate between two items if necessary. For example, if you have focus in the Project Explorer and have a builder call editor open, press Ctrl+F7 to activate the view menu and select Editor from the view menu. After the builder call editor has focus, use Ctrl+F7 to toggle back and forth between the Project Explorer and the builder call editor.
| Keyboard combination | Action |
|---|---|
| Ctrl+F6 | Activate editor menu and navigate between open editors |
| Ctrl+F7 | Activate view menu and navigate between open views |
| Ctrl+E | Activate editor drop-down menu from editor to navigate between open editors |
| Ctrl+Page Up, Ctrl+Page Down | Navigate between open tabs within the model
editor area of the perspective. Tabs can be in the bar above the Application Tree panel or in the bar below the builder call editor. The keys work in the bar for the panel that has focus. |
| Alt+(-) | Activate view menu to move view tabs, resize views, access fast views, detach views, minimize, and maximize |
| Alt+Page Up, Alt+Page Down | Move the builder call editor vertical scroll bars up and down. |
| Ctrl+Alt+Tab | Move out of a table on the left to the corresponding fields on the right. |
| Shift+Alt+Page Up, Shift+Alt+Page Down | Move the builder call editor horizontal scroll bars left and right. |
| Down Arrow | Navigate down menu options |
| Up Arrow | Navigate up menu options |
| Right Arrow | Navigate to submenu options |
| Left Arrow | Navigate to menu options from submenu |
If you find the builder call editor difficult to read, you can try using larger fonts or lower screen resolution. If these actions do not increase legibility enough, you can run the builder call editor in its own window.
You can use keyboard navigation to select focus within a table. However, navigating and editing within a table in the builder call editor differs from editing normal table data. Within the builder call editor, selecting a certain option in a table cell can make new inputs available outside the table. The normal use case is to leave the cell that has focus and place focus in the first new input. To change focus from a cell in a table to the first new input, the builder call editor supports the Ctrl+Tab combination. This relieves the requirement to press Tab multiple times to navigate to the end of the table and press Down Arrow in the last row to exit the table and navigate to the new input. The combination changes focus to the first input related to the option selected in the cell that currently has focus.
| Keyboard combination | Action |
|---|---|
| Right Arrow | Move to beginning of next cell if current focus is at the end of cell |
| Left Arrow | Move to end of previous cell if current focus is at the beginning of the cell |
| Up Arrow | Move to cell above if current focus is on the first line of the cell |
| Up Arrow | Exit table if current focus is in the first row of the table |
| Down Arrow | Move to cell below if current focus is on the last line of the cell |
| Down Arrow | Exit table if current focus is in the last row of the table |
| Tab | Move to next cell |
| Tab | Append new row to table and move to that cell if focus is in last cell of the table |
| Ctrl+Tab | Move out of the table |
| Shift+Tab | Move to previous cell (if focus is in first cell, no navigation) |
IBM Support provides assistance with IBM Web Experience Factory product defects.
To contact IBM Support, your company must have an active IBM software maintenance contract, and you must be authorized to submit problems to IBM. For information about the types of maintenance contracts available, see "Support Portfolio" in the Software Support Handbook at the following location.
http://techsupport.services.ibm.com/guides/services.htmlComplete the following steps to contact IBM Support with a problem.
You may have to perform a task to improve the quality of the searches in the information center.
The procedure to start Web Experience Factory Designer differs between Windows and Linux systems.
Installing the product involves running a program and answering a few questions.
When the installation completes, you can set up various extensions that you can use in developing your web applications.
Use this guide to install IBM Web Experience Factory Version 8.0.
This guide contains the following installation topics.
This guide applies to Web Experience Factory, but the installation may involve installing other products.
The default installation selection includes a supported version of Eclipse. Alternatively, Web Experience Factory can be installed into a supported version of one of the following IDEs.
Prior to installation, you must install IBM WebSphere Portal or one of the supported application servers. Refer to the detailed system requirements section in the product release notes topic for application server versions and patch levels.
If you have an existing installation of Web Experience Factory, do not install the new version over the old one in the same directory.
If you want to use the same directory for the new installation, follow these steps.
Then, you can follow the steps described in Web Experience Factory Product Installation Guide to begin exploring the product.
Before you install Web Experience Factory, you should install:
To install Web Experience Factory into an existing Rational Application Developer or Rational Software Architect installation on Linux systems, follow the procedures described in Web Experience Factory Product Installation Guide.
config/win_silent_install.properties
config/linux_silent_install.propertiesThe installation program installs everything to the target location without showing the user any output. You know that the installation is complete when the log file is created in the root of the installation directory.
You can run the installation executable file, select the options desired, and save those options to a text file that can be used to install the product silently.
Follow the procedure in Web Experience Factory Product Installation Guide to run a silent installation with your response file rather than the supplied property file.
Once you successfully install the Web Experience Factory Designer, you must create a new project. In creating a project, you provide application server-specific and WebSphere Portal server-specific information about your installation. This process completes the deployment phase of Web Experience Factory installation.
The Web Experience Factory Designer provides a New Project wizard to help you create a project. This multiple page wizard walks you through the steps involved in project creation and deployment and also builds the project for you. F1 Help that describes project settings and parameters is available for each page of the wizard. Refer to F1 Help to learn about the settings on a given page and to access links to additional information.
The best way to create your first project is to run the tutorial that describes this process. If you are using a Windows client, this tutorial is available from the Welcome page, or from Start. Click . If you are using a Linux client, this tutorial is available from the Web Experience Factory Help system.
Web Experience Factory Designer supports the following languages: German, Spanish, French, Italian, Japanese, Korean, Portuguese (Brazil), Traditional Chinese, and Simplified Chinese.
To use Eclipse in a language other than English, you must download a language pack from the Eclipse web site, and install that pack into your Eclipse IDE.
After you run the Web Experience Factory Designer New Project wizard, restart Tomcat. This ensures that all libraries are loaded correctly.
/Factory.bin LAX_VM $JAVA_HOME/bin/java Follow the steps in Web Experience Factory Product Installation Guide or Web Experience Factory Product Installation Guide (depending on your client platform) and then Web Experience Factory Product Installation Guide to remove Web Experience Factory Designer files and project WAR files.
This section discusses the procedures required to upgrade IBM Web Experience Factory plug-in files if you have installed a new version of Web Experience Factory into an IDE (Eclipse or IBM Rational) that has a previous version installed. This section also describes how to update a project built with a previous version of Web Experience Factory Designer to the latest project version. Finally, this section describes how to upgrade portlets to the Java Portlet Standard API.
When upgrading 'flat' projects, create a new project and migrate your content to it using the function. A flat project is a 5.12 or 6.0 project that does not have a WebContent directory. You will not get the added benefits of facet support if you upgrade a flat project.
You must modify any projects that you created using the old plug-in files so that these projects can include changes related to the new plug-in files and feature sets.
If you have added any jar files to /WEB-INF/work/lib, you will need to manually add them to the build path after a project upgrade.
WebSphere Portal has support for the Java Portlet Standard API for WebSphere portlets. While portlets designed for use in the deprecated WebSphere Native portlet API may continue to run in WebSphere Portal, it is recommended that any new portlets be built using the Java Portlet Standard API.
To upgrade a portlet built in a previous version of the Web Experience Factory to use the Java Portlet Standard API, perform the following steps.
If you have a model that uses the Cooperative Portlet Source builder or the Cooperative Portlet Target builder and the project uses the Java Portlet Standard 2.0 API (JSR 286), regenerate the model.
These steps are required to capture new event metadata that did not exist in prior releases of Web Experience Factory.
This procedure captures the new event metadata.
IBM Tivoli® License Manager (ITLM) recognizes and monitors what products and their versions, releases, and fix packs are installed, and used, on a system. This allows IBM to communicate updates for products installed in its customer base, and appropriately bill for the product and the amount of usage. It also prevents billing for multiple installations of the same product that is bundled with various IBM software packages.
The usage of applications and portlet WAR files created with the IBM Web Experience Factory can be monitored and tracked by Tivoli License Manager. To enable this capability, you must place at the root level of an application or portlet EAR file certain files that are generated by the Web Experience Factory and recognizable by Tivoli License Manager.
To enable Tivoli License Manager usage tracking, perform the following operation:
If you want to install Web Experience Factory and use the JAWS screen reader for accessibility, you need to perform the following additional step to correctly start the installation.
Use the Web Translator feature to enable IBM Lotus Expeditor (XPD) 6.1.1 to support dynamic JSPs.
Install IBM Lotus Expeditor (XPD) 6.1.1 and enable it to support dynamic JSPs by means of the Web Translator feature.
Several integrations with back end systems are provided in IBM Web Experience Factory.
You can add an integration extension to your project as you would add any other feature set. This lets you use the builders that are provided with the extension.
However, before you can use an extension, perform the necessary installation, configuration, and set-up steps described in the related getting started topic.
This topic describes the Lotus Collaboration Extension.
This package expands the power and flexibility of Web Experience Factory by providing Domino builders for IBM Lotus Domino components and services.
This feature set also includes functionality to support remotely calling and running Domino agents, and using additional security schemes, such as LTPA tokens or IBM WebSphere Portal Server credentials. Both enable single sign-on for portlet users.
The portlets and widgets that you create with this package can also incorporate awareness to take advantage of Lotus collaboration services such as chat, e-mail, profile discovery and author and document search. And, using the unique ability of Web Experience Factory to customize a portlet and a widget, you can create custom portlets or widgets that provide your users with only the views and collaboration features they require.
Install this collaboration package as you would any other feature set.
For convenience, you can set up a property file to establish and control Domino server settings. When you select this file in a Domino Data Access builder, it is used to establish connection settings to the Domino server.
This file is located in the project WEB-INF/config/domino_config directory. The properties file is used to specify basic Domino connection properties such as the name of the Domino server and a valid Domino user name and password. A typical Domino properties file might be named domino.properties and contain the following:
# Domino application server
ServerName=
# Domino User Name
UserName=
# Domino Password
PassWord=
# Domino server http port
# The http port is used when the builder is configured to retrieve rich rext items as HTML.
# The Domino Attachment builder also uses these values when creating http
# links to attachments in the documents.
DominoHttpPort=80
# SSL Settings
# When rich text items are fetched as HTML, relative urls to Domino resources (images,
# other documents, etc.) in the html are converted to absolute URLS to the Domino
# resource. Thus, the browser will request these resources using the absolute URL.
# If the absolute URLS to Domino resources should use https, set DominoConvertAbsUrlsToSSL
# to true. Also set DominoHttpsPort to your Domino server's https port.
# The Domino Attachment builder will also use these properties when forming
# the URL to the attachment.
DominoConvertAbsUrlsToSSL=true
DominoHttpsPort=443
# If the application on the application server should use https when fetching rich text
# items from Domino's web server, set the following property to true.
# Note: if this property is true, the certificate from Domino's web server will need
# to be added to your application server JVM's cacerts file.
DominoUseHttps=falseTo use this package and the builders it contains, you must have IIOP (Internet Inter-Orb Protocol) access to the Domino server. See Domino help for additional information.
To activate awareness functionality, you must be running the IBM WebSphere Portal Server Extend or the WebSphere Portal Experience products, and collaboration components in these products must be correctly configured and running on the Domino server. These components include one or more of the following: Sametime® (for chat), Discovery (for user profiles display, author/document search and mail).
Check the release notes for this product to see which Lotus Collaboration products support the components in this package.
In order for the Domino Data Access builder to access Domino resources, Domino server security must be configured to allow and restrict remote calls appropriately. Configuration settings governing this access are set in the Domino Administrator.
You can review security settings by examining the current server document's Security tab. For more information about establishing these settings, see Domino Designer help. In Domino version 6, refer to the following Domino Designer help topic: . The section on server requirements discusses security settings.
The Domino server must support the browsing of databases to allow the various controls in builders to be populated with lists of available databases, views, forms and agents. The Domino server setting to make databases browsable is located in the server document tab in the Domino directory. You should also open the Security tab and set Allow anonymous Notes connections to enable (Yes) .
To run a Domino agent by calling it remotely from a portlet or a widget, you must sign the agent. Your enterprise security policies can dictate how you do this, but the end result must be that the portlet or widget user has the right to invoke the agent remotely from within a portlet or widget.
To take advantage of security provided by SSL, perform some procedures to correctly configure Web Experience Factory and Domino for SSL operations. The following steps are required to use SSL for a Domino connection.
bowstreet.domino.session.enableSSL=trueThe TrustedCerts.class file is generated by the Domino server when DIIOP port is enabled with SSL. This file contains a certificate that is verified by the server.
install_directory\Designer\eclipse\plugins\com.bowstreet.designer.core_version-number\libBundle-ClassPath: designercore.jar,
lib/jakarta-poi.jar,
lib/jxl.jar,
lib/sapjco.jar,
lib/SiebelJI.jar,
lib/SiebelJI_Common.jar,
lib/SiebelJI_enu.jar,
lib/Siebel.jar,
lib/sslClasses.jar
lib/activation.jar,
lib/portlet.jar,
lib/bstres.jar,
lib/bstres_nl1.jar,
lib/builderui-res.jar,
lib/builderui-res_nl1.jar,
lib/jdom.jar,
lib/builderimages.jar,
lib/NCSO.jar,
lib/packman.jar,
lib/factory.jar,
lib/builderui.jar,
lib/j2ee.jar,
lib/icons.jar,
lib/wsdl4j.jar,
lib/classparser.jar,
lib/axis.jar,
lib/commons-fileupload.jar,
lib/commons-logging.jar,
lib/commons-discovery.jar,
lib/commons-pool.jar,
lib/wc50.jar,
lib/WidgetExtension.jar,
lib/WidgetExtension_nl1.jar,
lib/xercesImpl.jar,
lib/xml-apis.jar,
bin/,
lib/log4j.jarinstall_directory\WEFDesigner\eclipse\plugins\com.bowstreet.designer.core_version-numberFor example, such an edit might look as follows:
<library name="lib/sslClasses.jar">
<export name="*"/>
</library>This addition makes the TrustedCerts.class file available to the runtime environment.
domino_server.my_company.com:63148There are two ways to get started building Domino portlets:
From within WebSphere Portal, use the Domino Customizer to clone and then modify Domino portlets. For more information, see 3.1 For power users.
Run the Domino samples and examine the sample models. For more information, see 3.2 For developers.
Follow these simple steps to build a custom Domino portlet.
This portlet has not been configured. Use the portlet's Configure icon to configure the portlet. This involves specifying a Domino server, database and view, in additional to several other Domino configuration settings. Press the portlet's Help button to display additional information about configuring the portlet and viewing it in the WebSphere portal.Access the Domino samples and examine the related articles in the product wiki.
Access the Domino samples and examine the related articles in the product wiki.
Packaged with Web Experience Factory is a backwards compatible Domino 8 version of NCSO.jar, which contains performance enhancements in the Domino CORBA implementation.
This topic describes PeopleSoft Extension.
The PeopleSoft Extension delivers to IBM Web Experience Factory users the following important features:
Install the PeopleSoft Extension as you would any other feature set.
The PeopleSoft Java Object Adapter JAR file, psjoa.jar, can be obtained from your PeopleSoft installation or from your PeopleSoft Customer Service representative.
The JAR file contains Java classes used by the builders to access your PeopleSoft servers. If you have a local installation of PeopleSoft, look into the PS_HOME directory for a copy of this file.
To confirm correct installation of the builder and JAR files, follow these steps.
The first step in using the PeopleSoft builders is to establish a connection properties file. This file is located in the project /WEB-INF/config/peoplesoft_config/ directory. The properties file (default_connection.properties) is used to specify connection properties, such as the name of the PeopleSoft server and a valid PeopleSoft user name and password.
A typical properties file might contain the following properties:
#Default connection properties for the PeopleSoft Builders
# PeopleSoft application server
hostserver=pplsoft:9000
# Logon user name
UserName=jdoe
# Logon password
PassWord=PSThe PeopleSoft builders support pooling of sessions to your backend PeopleSoft servers. By default, session pooling is disabled (a reasonable configuration for a Web Experience Factory Designer environment). However, on the server, you may want to enable pooling to minimize the number of sessions created and improve overall builder runtime performance.
You can add the properties in the table below to a PeopleSoft project .../WEB-INF/config/override.properties file to enable and configure PeopleSoft session pooling.
| Property | Default value | Effect |
|---|---|---|
| bowstreet.peoplesoft.session.pool.enabled | false | If defined and set to TRUE session pooling is enabled. |
| bowstreet.peoplesoft.session.pool.maxActiveSessions | 8 | Maximum number of active sessions at one time. When negative, there is no limit to the number of active sessions. |
| bowstreet.peoplesoft.session.pool.maxIdleSessions | 8 | Maximum number of idle session in the pool at one time. When negative, there is no limit to the number of idle sessions. |
| bowstreet.peoplesoft.session.pool.maxWait | -1 | Maximum time in milliseconds to wait for a session to be returned to the pool. When negative, the requesting thread will wait indefinitely for a session to be returned. If no session is returned to the pool in the specified time, then the requesting thread receives an exception. |
| bowstreet.peoplesoft.session.pool.maxIdleTimeSeconds | 1800 | Maximum time in seconds that a session is allowed to remain idle in the pool before being evicted and reclaimed. When negative, no sessions will be evicted based upon idle time. |
| bowstreet.peoplesoft.session.pool.idleSessionSweepSeconds | 30 | Maximum time in seconds between sweeps of the pool looking for idle sessions to evict and reclaim. When negative, pool sweeping is disabled. |
| bowstreet.peoplesoft.session.pool.maxAgeMinutes | -1 | Maximum age in minutes of a session before
it is evicted and reclaimed no matter what the idle session settings
may be. When negative, sessions are never evicted and reclaimed due
to their age. Note: This is a feature/property specific to Web Experience
Factory that is not implemented
in the Commons library.
|
This topic describes the SAP extension.
The SAP Extension provides IBM Web Experience Factory users with the following important features.
The components in the SAP Extension support the following SAP product version.
| SAP Product | Versions Supported |
|---|---|
| R3 | See the detailed system requirements in the Web Experience Factory release notes topic for the versions supported. |
Install the SAP Extension:
Also copy the sapjco3.dll file into the system32 directory of your Windows operating system. (For example, on Windows XP systems, C:\Windows\system32.)
The values for the Group, Artifact, Version, and Type are largely arbitrary. Choose values that correspond to any naming conventions that you have or any other considerations. Clicking install results in the JAR files being placed in the WASCE/repository/Group/Artifact/Version/Type directory and they are loaded by the WebSphere Application Server Community Edition server-wide class loader.
-rwxr-xr-x (755)C:\Program Files\IBM\Web Experience Factory\Designer\eclipse\plugins\com.bowstreet.designer.core_latest version/home/user/IBM/Designer/eclipse/plugins/com.bowstreet.designer.core_latest version<?xml version="1.0" encoding="UTF-8"?>
<web-app>
<dependency>
<groupId>wef_integration</groupId>
<artifactId>WEF_JCo3Common.jar</artifactId>
<version>1.0.0</version>
</dependency>
<dependency>
<groupId>wef_integration</groupId>
<artifactId>sapjco3.jar</artifactId>
<version>3.0.5</version>
</dependency>
</web-app>To confirm correct installation of the builders and JCo, follow these steps.
The first step in using the SAP builder is establishing a destination properties file. This file is located in the project WEB-INF/config/sap_config/ directory.
The properties file is used to specify SAP connection properties such as the name of the SAP server and a valid SAP user name and password. A typical SAP properties file might be named my_sap.properties and would contain the following properties:
# SAP application server
jco.client.ashost=
# Logon user
jco.client.user=
# Logon password
jco.client.passwd=
# SAP client
jco.client.client=000
# Logon language
jco.client.lang=EN
# SAP system number
jco.client.sysnr=00A default SAP server.properties file is installed with the SAP Builder and is located in the WEB-INF/config/sap_config directory. You can use the file to establish your basic SAP settings and view examples of valid property values. As configured at installation, this file is applicable to a MiniSAP server running on the local host.
After you install and configure the SAP Extension, run the object browser model. You can use this model to explore the objects in an SAP system. Use the following steps.
The SAP Builder use the SAP JCo interface (available with your SAP system) to connect to SAP. This interface allows a Java application to communicate with any SAP System. The SAP JCo interface supports connection pooling and oversees the management of portlet-to-SAP communications.
The JCo interface defines several new properties used to enable and configure destination pooling. From the client perspective, a destination is a set of connection properties used by the JCo interface to establish communication with an SAP server. These pooling properties can be added to the property files stored under WEB-INF/config/SAP_config/.:
jco.destination.peak_limit=5
jco.destination.pool_capacity=1
jco.destination.expiration_time=60000The peak limit defines the maximum number of connections active at one time for a destination. The pool capacity defines the number of idle connections to be maintained in the destination's pool; a value of zero disables the use of pooling. The expiration time, specified in milliseconds, defines the maximum time an idle connection will sit in the destination connection pool before being closed and removed.
A default value of 5 for the peak limit has been found to provide adequate number of connections and good performance.
This section pertains to deployed WARs that access SAP and are implemented using Web Experience Factory. If you have a mixed environment, then you may need to write a small amount of custom code to have Web Experience Factory and WARs not created by Web Experience Factory coordinate their configuration and access to SAP through the JCo interface.
Ignore this section if you use Web Experience Factory to implement all of the deployed WARs that access SAP.
The SAP JCo interface uses the concept of a destination to define how clients access a server. From a client perspective a destination is a named set of connection properties that the JCo interface uses to create connections to the server specified in the properties. These connections are not exposed to clients therefore all clients are required to communicate with the SAP server by passing a destination name to JCo methods.
Web Experience Factory implements a registry, also known as a destination data provider, that is responsible for managing destination property sets. This registry assigns each property set a unique destination name and then provides the appropriate set of properties to JCo when a client references a destination name in a JCo method.
Only one destination data provider can be configured for the JCo runtime, using the JCo interface. All WARs accessing SAP through the JCo interface must use the same destination data provider. The destination data provider registry is located in the WEF_JCo3Common.jar file. By placing this JAR in a directory from which your application server loads shared JAR files, you have made the Web Experience Factory destination data provider implementation available to all WARs whether or not they were built with Web Experience Factory or otherwise. If all of the WARs accessing SAP have been built with Web Experience Factory, then no additional steps are required.
com.bowstreet.builders.webapp.methods.JCo3Common.DestinationRegistrybowstreet.sap.destinationRegistryAt runtime, the SAP builders in a WAR instantiate a single instance of this class and use that single instance to register all required destinations.
The JCo interface uses a session reference provider to generate session IDs to support calling multiple SAP functions as part of a single transaction that spans multiple threads. Web Experience Factory implements and uses a session reference provider as part of the SAP builder runtime. The JCo interface only uses one session reference provider when it is configured for the JCo runtime. All WARs that access SAP through the JCo interface must use the same session reference provider.
The Web Experience Factory session reference provider is contained in the WEF_JCo3Common.jar file. By placing this file in a directory from which your application server loads shared JARs, you made the Web Experience Factory provider implementation available to all WARs (built with Web Experience Factory or otherwise). If all the WARs that access SAP are built with Web Experience Factory, no additional steps are required.
com.bowstreet.builders.webapp.methods.JCo3Common.SessionProviderbowstreet.sap.sessionProviderThis topic describes the Siebel extension.
The Siebel extension provides IBM Web Experience Factory users with the following features.
The components in the Siebel Extension support the following Siebel product versions.
| Siebel product | Versions supported |
|---|---|
| Siebel CRM Solutions | See the detailed system requirements referred to in Web Experience Factory release note topic for the versions supported. |
The Siebel Extension leverages the Siebel Java Data Bean interface to access the Siebel repository. As a result, you must acquire the following, version-specific, Siebel JAR files from your Siebel systems administrator:
Install this Siebel Extension as you would any other feature set.
C:\IBM\WEF\WEFDesigner\eclipse\plugins\com.bowstreet.designer.core_x.y.zThe Meta-Inf folder is located in the same plugin folder as the \lib folder in which you placed your JAR files.
The default definitions in the manifest file should be sufficient. However, if the Siebel JAR files that you obtained for your server are named differently, adjust the definitions so that these JAR files can be loaded by Web Experience Factory Designer.
Add the Siebel jar files to the IBM WebSphere Application Server Community Edition (CE) server.
Update the geromino-web.xml file for your project in Web Experience Factory.
<dependency>
<groupId>wef_integration</groupId>
<artifactId>SiebelJI_enu</artifactId>
<version>7.8</version>
</dependency>
<dependency>
<groupId>wef_integration</groupId>
<artifactId>siebel</artifactId>
<version>7.8</version>
</dependency>/WebSphere/AppServer/lib/extYou must match file encoding. To communicate successfully, a Siebel server and an external Siebel client (such as Web Experience Factory), must use a compatible file encoding. For example, the default Windows file encoding is Cp1252. On RedHat Linux, the default file encoding is UTF-8.
To use Siebel builders successfully, ensure that your client platform matches the file encoding used by your Siebel server. For example, when Web Experience Factory Designer runs on the Linux system, the default file encoding for the JVM can be different than the default file encoding used by the Siebel server. Siebel requires that a client that uses the Java API to connect to a Siebel server have the same default file encoding as the Siebel server. If the default file encoding settings differ, the Siebel coordinator fails during regeneration with the message Could not open a session in 4 attempts. This causes model errors and the model does not run.
-Dfile.encoding=utf8Use the WebContent\factory\util\testSiebelConnection.jsp file to test your Siebel connection. Perform the following steps to ensure that your connection properties are correct.
http://yourserver:port/projectName/factory/util/testSiebelConnection.jspThe first step in using the Siebel builder is establishing a properties file. This file is located in the project WEB-INF/config/siebel_config/ directory. The properties file (default_connection.properties) is used to specify connection properties such as the connection string to the Siebel server, and a valid Siebel user name and password.
A typical properties file might contain the following properties.
#Default connection properties for the Siebel Builder
ConnectString=siebel://10.10.2.125:2320/siebel_es/SSEObjMgr_enu/wicdemo9
UserName=sadmin
Password=sadminA Siebel default_connection.properties file is installed with the Siebel Builder. This properties file is located in the WEB-INF/config/siebel_config/ directory. You can use the file to establish your basic Siebel settings and view examples of valid property values. As configured at install time, this file is applicable to a Siebel server running on the local host.
RepositoryName=Siebel Repository The Siebel builders support pooling of sessions to your backend Siebel servers. By default, session pooling is disabled (a reasonable configuration for a Web Experience Factory Designer environment). However, on the server, you can enable pooling to minimize the number of sessions created and improve overall builder runtime performance.
You can add the properties in the table below to a Siebel project .../WEB-INF/config/override.properties file to enable and configure Siebel session pooling.
| Property | Default Value | Effect |
|---|---|---|
| bowstreet.siebel.session.pool.enabled | false | If defined and set to TRUE, session pooling is enabled. |
| bowstreet.siebel.session.pool.maxActiveSessions | 8 | Maximum number of active sessions at one
time. When negative, there is no limit to the number of active sessions. |
| bowstreet.siebel.session.pool.maxIdleSessions | 8 | Maximum number of idle session in the pool
at one time. When value is negative, there is no limit to the number of idle sessions. |
| bowstreet.siebel.session.pool.maxWait | -1 | Maximum time in milliseconds to wait for
a session to be returned to the pool. When value is negative, the requesting thread will wait indefinitely for a session to be returned. If no session is returned to the pool in the specified time, then the requesting thread receives an exception. |
| bowstreet.siebel.session.pool.maxIdleTimeSeconds | 1800 | Maximum time in seconds that a session is
allowed to remain idle in the pool before being evicted and reclaimed. When negative, no sessions will be evicted based upon idle time. |
| bowstreet.siebel.session.pool.idleSessionSweepSeconds | 30 | Maximum time in seconds between sweeps of
the pool looking for idle sessions to evict and reclaim. When negative, pool sweeping is disabled. |
| bowstreet.siebel.session.pool.maxAgeMinutes | -1 | Maximum age in minutes of a session before
it is evicted and reclaimed, no matter what the idle session settings
may be. When value is negative, sessions are never evicted and reclaimed due to their age. Note: This is a feature and property specific
to Web Experience
Factory that is not
implemented in the Commons library.
|
You can configure many aspects of your work environment.
Follow this wiki link http://www-10.lotus.com/ldd/pfwiki.nsf/xpViewRecent.xsp?searchValue=configure%2C%20configuring for additional information about configuring Web Experience Factory.
Follow these steps to change the Web Experience Factory Designer preferences.
You can display the Web Experience Factory Preferences dialog.
Follow these steps to restore the Web Experience Factory Designer default preferences.
In Web Experience Factory Designer, you can set various preferences.
These preferences determine functionality and appearance of the Web Experience Factory Designer editing environment and the server runtime resources to use when you run a model.
The set of Web Experience Factory Designer default preferences are stored in the Web Experience Factory Designer preferences.ini file, which is in the eclipse\plugins\com.bowstreet.designer.ui directory. If you change the default preferences, the customized set of preferences is stored in your workspace, so that it does not overwrite the default preferences. This storage strategy allows you to restore the default preferences at any time.
This topic describes the Web Experience Factory Designer editing preferences you can change.
You have available the following settings if you click .
| Setting | Description |
|---|---|
| Browser Command | Enter the path to
the web browser to launch when you run models. Note: Changing this
setting effects new run configurations only, not existing run configurations.
|
| Override Properties File Location | Use this setting
to specify the path to store the override.properties file.
This file is created in the WEB-INF/config directory
when you create a project. Settings in this file are used to replace
default property settings established in supplied properties files
and also to determine log locations. Note: Changes made to the value
of this field do not take effect until Web Experience
Factory Designer is restarted.
|
| IBM Support Assistant Location | If you have IBM Support Assistant installed, specify the path used to run it. |
| Show Hidden Objects | Sets the Application
Tree panel in the model editor to show all the objects added to the
WebApp by the builder calls. When you click Apply in
the builder call editor, all hidden objects are displayed. Typically
you do not need to see hidden objects. Note: The variables, methods,
LJOs, and other objects designated as hidden by the developer do not
show up in the Reference Chooser, regardless of the status of the Show
Hidden Objects check box.
|
| Wrap View Data | Causes long text
lines in various Method and Page Domain viewers to display on the
next physical line. The viewers associated with the Application Tree panel display the contents of WebApp objects (such as pages or methods). In some cases, viewing this information on a single line is useful. In other cases, the information is better displayed as wrapped text. |
| Expand view on opening builder | Expands the view when you open the builder. |
| Create default folders in new projects | Sets the Create default folders option in the Create Project wizard so that it is enabled whenever you create a new Web Experience Factory project. |
| Show Apply button on Builder Call Editor page | Sets the Apply button to be available. Clicking Apply saves your edits, starts a regeneration, and keeps the builder call editor open. Without the Apply button, you need to click OK to save your changes, but the builder call editor closes. |
| Default builder picker to show both builder types | Normally the builder picker displays as available either user interface or data provider builders, based on model editor context. Enable this setting to have Both set in the builder picker to show both types regardless of context. |
| Group outline by | Sets the default control for listing builders in the Outline view with the View menu Group by command. Click Apply to change the current Outline view to match the setting. Drag and drop is enabled only if the sorting is by number. |
| Builder Call Editor | Select the type of
display for builder call editors.
Note: A change in this setting effects models opened
after the preferences are saved. To apply this setting to an open
model, you must close and re-open the model.
|
Web Experience Factory properties affect some aspects of development.
The following aspects of model development are determined by Web Experience Factory properties. All properties shown are in the WEB-INF/config/cluster.properties file unless otherwise noted.
# specifies the compiler to use
bowstreet.methods.compiler=C:/jdk131/bin/javac.exe# This is where the generated source(.java) will go
bowstreet.methods.sourceDirectory=${bowstreet.rootDirectory}/work/source# This is where the compiled class will go. This should be in a place where the dynamic class loader can pick it up.
bowstreet.methods.targetDirectory=${bowstreet.rootDirectory}/work/classes#In bowstreet.properties file
# classpath-like syntax (semi-colon delimited) for location of BuilderDef files
# default if unavailable is ${bowstreet.rootDirectory}/builders
bowstreet.location.builderdef.path=${bowstreet.rootDirectory}/buildersTo specify multiple locations from which to dynamically load classes, append the additional paths in the property by separating each path with a comma, as in this example:
#In bowstreet.properties file
bowstreet.dynamic.class.load.path=${bowstreet.rootDirectory}/work/classes,${bowstreet.rootDirectory}/work/my_classes
bowstreet.dynamic.class.load.checkTimestamp=trueThe bowstreet.dynamic.class.load.checkTimestamp property, if set to true, enables the time check for classes being loaded by the dynamic class loader. If the property is set to true and a class changes, the class will be dynamically reloaded on the next instance creation, providing it is on the loader class path and is one of the supported classes to be dynamically loaded.
# Uncomment these parameters to add 1999 and/or 2000/11 XMLSchema References into
# SOAP responses when using pre-Factory 5.9 SOAPPC and SOAPDOC URLs (not used by Axis)
#bowstreet.soap.schemaRef.1999=true
#bowstreet.soap.schemaRef.2000=trueFor example:
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<SOAP-ENV:Body>
<ns1:gcdXmlResponse xmlns:ns1="http://bowstreet.com/2002/03/models/xmethods/gcd">
<gcdreply><distance>2708.88</distance></gcdreply>
</ns1:gcdXmlResponse>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>You can specify the location from which Web Experience Factory retrieves the SOAP encoding schema with the property, which is by default set to: bowstreet.location.schemas
In Web Experience Factory 5.9, additional per-service call proxy settings are available in the Service Call builder's Advanced Inputs section.
You can control the Maximum Schema Cache size using the following property: bowstreet.schema.maxCacheSize= . The default max cache size is 50 schema Objects.
Two override properties files are available to take the place of property settings that are set in other property files.
The override feature is useful to replace a setting in another property file, such as bowstreet.properties or cluster.properties, typically logging settings. If you change the setting in the supplied property file, it is lost when you upgrade the product.
The override.properties file is used by IBM Web Experience Factory Designer to specify logging properties for Web Experience Factory Designer, and to override properties specified in the IBM server config directory.
The override property files are:
designer_core_version_number/configIf you change a property during development, use this preference to insure that your changes are correctly propagated across projects and throughout the IBM system.
Each time Web Experience Factory Designer is started, the following actions occur:
Designer Install Location/plugins/com.bowstreet.designer.core_x.y.z/config/override.properties
logging.driver.eventSink.directory=eclipseinstalldir
/workspace/.metadata/.plugins/com.bowstreet.designer.core/logs
logging.driver.eventSink.prefix=designer_event_
logging.event.flush.interval=1 This ensures that Web Experience Factory Designer logs are written to the appropriate place. All other properties in override.properties are unaffected.
You can configure the version of the Java runtime environment (JRE) that is used when you build your application.
Build path specifies execution environment J2SE-1.5.
There are no JREs installed in the workspace that
are strictly compatible with this environment.By default, the Web Experience Factory project settings specify that the project requires a Java 5 run time environment. The Web Experience Factory Designer compiles Java code in the project using the appropriate target parameters to ensure that the generated Java .class files are capable of executing under a Java 5 JRE. However, run time issues can still occur if the Java code refers to APIs that are new and only exist in Java 6. The Java 6 class libraries are on the compilation classpath for the project and are therefore used to generate the Java .class files. This situation can result in a Java .class file that has the correct version flag to indicate that it is capable of running on a Java 5 JRE, but requires APIs that are only available in a Java 6 JRE.
To eliminate the warning messages, perform one of the following procedures.
It is useful to send debug information to the Eclipse console window.
Information returned to the console can help you troubleshoot problems with models and applications.
To display a console window for Web Experience Factory Designer, perform the following steps.
These flags display a console window to which are sent all debug statements that occur during generation.
There are quite a few tasks that you can perform to configure your IBM Web Experience Factory development and runtime environment.
You can use the command consoles for both the application which IBM Web Experience Factory runs and for Web Experience Factory Designer. Command consoles let you view any System.out.println() statements used in your code. Any System.out.println() statements in a builder Java class appear in the Web Experience Factory Designer console. Any System.out.println() statements in the Linked Java Objects (LJOs) or methods in a model appear in the application server console.
You can using existing JAR files in the Web application that you are developing.
You can have APIs that need to be accessed at design time (for example, by a custom builder). Or you can have a JAR (for example, from third-party software) that you need to reference from a builder generation or builder coordinator class.
You can configure dynamic class loading by setting properties.
Dynamic class loading is enabled. Each time the Web Experience Factory servlet fields a service call, class file time stamps are examined. If a later time stamp exists, a new version of a class is loaded. Typically, for performance reasons, the checkTimestamp property is set to true in a development environment and false in production.
You can configure the IBM Web Experience Factory servlet to dynamically load linked Java object, profile set manager and regen classes.
In normal operating mode, class files in the classpath are loaded by the default ClassLoader of the JVM each time the application server is started. However, if the class file changes while the application server is running (for instance if you recompile a Java file) the default ClassLoader does not reload the class.
In a development environment, you may want to reload a class more frequently. However, you may not want (or be able) to restart the application server every time you make a change to a class file. This is when dynamic class loading can be useful.
Be aware that you incur a performance cost when dynamic class loading is enabled. When dynamic class loading is enabled, class file time stamps are checked for each call a model makes to a service or linked object class. Given this, you are wise to enable dynamic class loading only in a development environment and to disable it in a development or production environment.
It is possible to configure the Web Experience Factory servlet to dynamically load Java class files without requiring the application server to restart. You might want to do this if you share a development Web Experience Factory servlet and frequently update the Java classes used by your services.
Java classes may be dynamically loaded from the directory or directories specified in the bowstreet.dynamic.class.load.path property.
The default value of the bowstreet.dynamic.class.load.path property is the IBM Web Experience Factory WEB-INF/work/classes and WEB-INF/work/lib directories of your project.
The following directories are used for the storage of Java class and JAR files in the Web Experience Factory project and web archive (WAR) file system:
The Web Experience Factory dynamic class loader loads classes from the WEB-INF/work/classes and WEB-INF/work/lib folders.
On the server side, the Web Experience Factory dynamic class loader delegates loading to the J2EE WAR class loader. This class loader loads classes from the WEB-INF/classes and WEB-INF/lib folders of the WAR file and delegates loading to the class loader of the application server.
On the Web Experience Factory Designer side, the Web Experience Factory dynamic class loader delegates loading to a Web Experience Factory WAR class loader. Each Web Experience Factory project has its own Designer WAR class loader that loads classes based on the Eclipse Java Build Path for the current project. The Designer WAR class loader uses all entries in the Eclipse Java Build Path except for those which are under the WEB-INF/work/classes or WEB-INF/work/lib folders of the project. The Designer WAR class loader delegates loading to the Eclipse class loader.
The delegation of loading enables the Web Experience Factory project to function in the Designer in the same manner as it does on the server.
Java source code that is placed in the project WEB-INF/work/source/ tree is compiled, and the output is stored in the project WEB-INF/work/classes tree. The contents of this directory are loaded dynamically and do not require a Web Experience Factory Designer or a server restart for changes to take effect. Any Java source changes can thus be seen instantly in WEB-INF/work/classes. This arrangement is useful for development where source code changes frequently.
Where JAR files are concerned, the WEB-INF/work/lib directory is the functional equivalent of the WEB-INF/work/classes directory.
You can disable dynamic class loading by setting the following property to false in the WEB-INF\config\override.properties file:
bowstreet.dynamic.class.load.checkTimestampYou can access the Javadoc for objects in your Java code in your integrated development environment (IDE).
The IBM Web Experience Factory Designer is fully integrated in Eclipse-based development environments.
The Web Experience Factory Designer is a plugin in the following Eclipse-based integrated development environments (IDEs):
The table below describes the characteristics of Web Experience Factory projects:
| Project Characteristic | Description |
|---|---|
| Project Nature | Web Experience Factory projects use the Java project nature. |
| Project Contents | Web Experience Factory projects contain all the contents of the Web Experience Factory servable content root directory. For example, wpf.war and below. |
| Source Directory | Web Experience Factory projects use the Web Experience Factory installation WEB-INF/work/source directory as a source directory. You may designate other directories as Source Directories, but you must include this one. |
| Build Directory | Points to the WEB-INF/temp directory in which the project Java source files are compiled. An Ant script included as part of the Web Experience Factory Designer plugin copies the classes in this directory to the WEB-INF/work/classes directory. |
| Included Libraries | Web Experience Factory projects include all the JAR files in the Web Experience Factory WEB-INF/lib directory and the JAR files in WEB-INF/clientlibs/servlet.jar. |
| External Tools | An Ant script Copy Classes copies the compiled Java WEB-INF/work/classes directory. |
You can find the log file for the Web Experience Factory Designer in the following directory:
eclipse/plugins/com.bowstreet.designer.core/logYou can find the log file for the Web Experience Factory in the Web Experience Factory WEB-INF/logs directory.
To configure how Help is displayed, follow these steps.
You can configure the IBM Support site to notify you of current fix packs.
To perform this task, you need an IBM ID and password. You can register to create an ID and password during this procedure. If you already subscribe to fix pack notifications, you can view and manage your current subscriptions.
If you wish to change to another JRE version or vendor, you will need to perform these steps.
Many samples are provided to help you develop web applications.
http://www-10.lotus.com/ldd/pfwiki.nsf Follow this link http://www-10.lotus.com/ldd/pfwiki.nsf/xpViewCategories.xsp?lookupName=Media%20Gallery to see video demonstrations of different features, concepts, and "how to"s.
These topics below can help you learn more about developing and building web applications in the Web Experience Factory environment.
This quick start guides you through the steps to create a project and run an application using the WebSphere Application Server Community Edition (WAS CE).
You can use WebSphere Application Server CE to enable quick and easy development and testing of applications. You have the option of installing WebSphere Application Server CE when you install IBM Web Experience Factory.
The WebSphere Application Server Community Edition (WAS CE) is an open source Java 2 Platform, Enterprise Edition (J2EE) application server based on Apache Geronimo.
Follow these steps to create a basic project for use with WebSphere Application Server CE.
Follow these steps to run a sample application using the WebSphere Application Server CE project file you created in Creating a WebSphere Application Server CE project. You can now run a sample application on the server to test that everything is properly configured.
models\samples\gettingstarted\OrdersServiceConsumer If everything is configured correctly, you see a web application in the browser. It is not necessary to do anything with this application. Simply displaying the application in the browser confirms that the setup is correct and that WebSphere Application Server is running the application.
This is the first of four tutorials that introduce you to the many powerful features of IBM Web Experience Factory.
In this tutorial, you will learn how to create a Web Experience Factory project for WebSphere Portal. For a tutorial focused on creating a project for WebSphere Application Server Community Edition (WAS CE), see the Quick Start for using IBM Web Experience Factory with IBM WebSphere Application Server CE.
This set of tutorials are a great starting point for a new Web Experience Factory developer. Each of the four parts of this tutorial take between 30 and 45 minutes to complete. The tutorials should be completed in the following order, as each builds on knowledge obtained in the previous tutorial. In addition, we recommend visiting the Web Experience Factory Learning Roadmap on the Web Experience Factory wiki after completing these tutorials to further advance your Web Experience Factory learning experience.
| Tutorial order | Description |
|---|---|
 Creating a Web Application
Project |
In this tutorial you will learn how to create a web application project. |
| Creating an application | In this tutorial, you will build a simple "hello world" application and then create a portlet from that application. |
| Creating a database application | In this tutorial, you will use the SQL Table Create builder against a sample database to create a service provider model, and then use the Service Consumer builder and Data Services User Interface builder to create a user interface service consumer model. |
| Using profiling in your new application | Continuing from the "hello world" application tutorial, you add the power of profiling to your application. |
After installing IBM Web Experience Factory, the first step in creating a portlet is to create a Web Experience Factory project using Web Experience Factory Designer. The project serves as the foundation for your portlet or application and contains all the artifacts required to publish your portlet or application.
In this tutorial, you create a Web Experience Factory project, configure it for use with a IBM WebSphere Portal environment, and run a sample to ensure that the setup is correct. After completing these tasks, you are ready to complete other tutorials to learn the basics of developing web applications and portlets with Web Experience Factory.
The following setup is required to run the tutorial.
You will only need to create one server configuration. This server configuration will publish your project to both the Application Server for testing your project during development and will publish the portlets to WebSphere Portal for view there.
There are many different configurations a developer can set up. The most common types of configuration are described below.
| Configuration Type | Description |
|---|---|
| Locally installed WebSphere Portal and Application servers | You
have installed WebSphere Portal
Server and the embedded WebSphere Application
Server locally.
When you create new server configurations, references to critical
folders such as the application server installedApps folder
will point to your local hard drive. This configuration is very easy to use but requires a powerful development machine with a minimum of 2 GB of RAM in order to achieve acceptable levels of performance. |
| Remotely installed WebSphere Portal and Application Servers | WebSphere Portal server and the embedded WebSphere Application Server are installed on another machine accessible across the network. |
Use the online help to complete the configuration for your environment.
If you have trouble, check the publish logs for your server configuration in the /WEB-INF/logs directory.
If you are using a local installation of Web Experience Factory, 6.x, security for WebSphere Application Server is enabled by default. As a result, you may be prompted for credentials during the creation of the WAR files. Use the WebSphere Application Server administrator credentials and not the WebSphere Portal administrator credentials. Also, be sure to wait for this prompt before leaving the publishing process unattended. The prompt will time out if you ignore it and your WAR file will not be automatically published. In this case, you can still install and configure the WAR file manually by using the WebSphere Administrative Console.
Now that you have created the Web Experience Factory project, you will run a sample application on the server to test that everything is properly configured.
above the workspace. Select
the default run configuration that was created when the Web Experience
Factory Model project was
created. This is the current active model.Congratulations! You have successfully created a Web Experience Factory project and run a sample application to confirm your configuration. The Web Experience Factory project that you created will contain all the models you create plus all of the supporting code and artifacts needed to develop, publish, and test Web Experience Factory web applications and portlets.
Now you are ready to move forward to learn how to develop web applications and portlets with Web Experience Factory Designer. Start with the tutorial for Creating an application.
This is the second of four tutorials that introduce you to the many powerful features of IBM Web Experience Factory.
In this tutorial, you will build a simple "hello world" application.
This set of tutorials is a great starting point for a new Web Experience Factory developer. Each of the four parts of this tutorial take between 30 and 45 minutes to complete. The tutorials should be completed in the following order, as each builds on knowledge obtained in the previous tutorial. In addition, we recommend visiting the Web Experience Factory Learning Roadmap on the Web Experience Factory wiki after completing these tutorials to further advance your Web Experience Factory learning experience.
| Tutorial order | Description |
|---|---|
| Creating a Web Application
Project |
In this tutorial you will learn how to create a web application project. |
| Creating
an application |
In this tutorial, you will build a simple "hello world" application and then create a portlet from that application. |
| Creating a database application | In this tutorial, you will use the SQL Table Create builder against a sample database to create a service provider model, and then use the Service Consumer builder and Data Services User Interface builder to create a user interface service consumer model. |
| Using profiling in your new application | Continuing from the "hello world" application tutorial, you add the power of profiling to your application. |
Developers build applications by creating a model, adding builders to those model, running the application you had just created, and then create a portlet from that application.
The following setup is required to run the tutorial.
When you want to create a new application, you will create a new model, and then add the appropriate builder calls to the model.
Builders have easy-to-use, wizard-like user interfaces, which make it both fast and easy to develop applications. Builders, however, are much more powerful than wizards, since builders can be used iteratively throughout the entire development process. Unlike other IDEs which provide run-once Wizards, with Web Experience Factory you can always go back and change a builder's input values, and have the entire application update instantly.
Behind the scenes, a builder is made up of a Java class that performs the appropriate automation task (like creating the JSP for the button) and an XML document (builder definition) that defines the builder's inputs, and design time user interface characteristics.
from the row of icons immediately below the menu at the top
of the workspace. A browser launches and display this simple application
containing a simple page titled Default Test Page. If the Application Tree is not visible, be sure you have the MyFirstPortlet model open and selected. If it is not, find the MyFirstPortlet model in the Project Explorer window and double-click it
Try choosing different elements in the Application Tree and watch for the corresponding elements in the Source and Design views become highlighted.
to display a list of builders that can be added
to this model. This list shows all available builders and their builder
categories. Since there are many builders that can modify a page,
many choices are displayed.To this point, you have created an application but you have not yet enabled the model to be a portlet. Now, you will enable the model to run within the WebSphere Portal framework as a portlet. This task is easy to accomplish because there is a builder for this purpose: the Portlet Adapter builder.
We'll leave profiling for a more advanced tutorial, but point out here that the default user interfaces (UIs) for the Configure and Edit pages are fairly plain. Richer UIs for these pages can be created separately in individual HTML pages or Web Experience Factory models. These pages and models can be referred to in a Portlet Adapter builder call and the builder will automatically add them to the portlet.
You will add a Portlet Adapter builder call to the MyFirstPortlet model and test your work by adding the portlet to a portal page.
to add a new builder call to the model.
Choose the category All if not yet chosen.| Input name | Enter this value for the given input |
|---|---|
| Name | tutorial_basics |
| Portlet Title | Tutorial Basics – Portlet |
| Portlet Description | Simple example to demonstrate core concepts |
Some changes to a model, however, require that the portlet WAR be republished. 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. Republishing the existing portlet WAR in Web Experience Factory Designer also automatically publishes the new WAR replacing the old one.
Web Experience Factory is a powerful tool for developing portlets and J2EE-compliant web applications. Applications and portlets are constructed from builders. Each builder call in a model makes some contribution to the XML representation of the application Web Experience Factory is supposed to generate. Through the regeneration process, an application is produced.
Now, you are ready to complete the Tutorial - Creating a database application tutorial where you will create a service provider model against a sample database using the SQL Data Services builder, and then create a user interface service consumer model, using the Service Consumer and Data Services UI builder.
Continuing from the "hello world" application tutorial, you add the power of profiling to your application.
This set of tutorials are a great starting point for a new Web Experience Factory developer. Each of the four parts of this tutorial take between 30 and 45 minutes to complete. The tutorials should be completed in the following order, as each builds on knowledge obtained in the previous tutorial. In addition, we recommend visiting the Web Experience Factory Learning Roadmap on the Web Experience Factory wiki after completing these tutorials to further advance your Web Experience Factory learning experience.
| Tutorial order | Description |
|---|---|
| Creating a Web Application
Project |
In this tutorial you will learn how to create a web application project. |
| Creating
an application |
In this tutorial, you will build a simple "hello world" application and then create a portlet from that application. |
| Creating
a database application |
In this tutorial, you will use the SQL Table Create builder against a sample database to create a service provider model, and then use the Service Consumer builder and Data Services User Interface builder to create a user interface service consumer model. |
| Using profiling in your
new application |
Continuing from the "hello world" application tutorial, you add the power of profiling to your application. |
In this tutorial, you will add profiling to the application. Profiling allows Web Experience Factory to build several versions of an application dynamically by supplying sets of alternative values for various parts of the application.
One of the most powerful aspects of Web Experience Factory is that models can be used in conjunction with a concept called profiling to generate multiple versions of the same application by combining different sets of predefined parameters with the same code base. In this part of the tutorial, you will create a new profile set for a set of builder inputs. The profile set contains two different sets of values for the profiled builder inputs. One set of values makes the application behave one way and the other set of values makes it behave another way. When you have finished, you will have two versions of the application each of which can be invoked by flipping a switch and re-running the model.
to profile enable this builder input. You can see the two variations of your application in the Design view and the Application Tree view. As you switch between the two profiles and click the Apply button, you can see the changes in the application. For example, if you expand the Application Tree to and click on page1. To the right you will see a few of the <div> tags with their content replaced by static text, filenames, and JSP scriptlets and expressions.
In this step, you will add an Image builder and use profiling to determine when this builder should be enabled or disabled. Disabled builders do not make any contributions to the generated application. Associating a builder's enable/disable value to a profile entry allows builders to be added or deleted automatically by regeneration based solely upon which profile is applied at regeneration time.
| Input name | Enter this value for the given input |
|---|---|
| Location Technique | Relative to Named Tag |
| Page | page1 |
| Tag | namedTag |
| Placement | After |
| New Tag Name | imgTag |
| Image Source | Click to the right of this field to bring up a reference chooser.
Click the Choose File tab and choose /samples/tutorials/images/tutorial_basics_image.jpg and
click OK. |
to profile enable this builder input. As with the
other profile entry, use Create Entry, and
change the prompt to Display Image, and set the UI
type to "Checkbox" and edit the Label After Check Box field to My
Checkbox. Click OK. The UI types for profile
entries will show up when you customize (configure which profile to
use) in Portal.By profiling some of the builder call inputs in a model, several versions of the application can be generated by simply switching profiles. In Web Experience Factory Designer, profiles can be chosen from the Applied Profiles tab. Depending upon how a Portlet Adapter builder call is configured, portlet administrators and users can apply various profiles in WebSphere Portal by using the Configure and Edit modes of the portlet. Profiles can also be chosen programmatically through a process called profile selection handling.
Profiles can also be used for localization, and profiling to portal groups. See this wiki article for more information.
In this tutorial you will use the SQL Table Create builder to create a service provider model against a sample database.
The SQL Table Create builder creates a database table and provides full CRUD (create, retrieve, update and delete) capability, exposed as service operations. You will then create a user interface service consumer model, using the Service Consumer and Data Services UI builder.
This set of tutorials are a great starting point for a new Web Experience Factory developer. While most of the four parts of this tutorial take between 30 and 45 minutes to complete, you should set aside an hour to and hour and one half for this tutorial. The tutorials should be completed in the following order, as each builds on knowledge obtained in the previous tutorial. In addition, we recommend visiting the Web Experience Factory Learning Roadmap on the Web Experience Factory wiki after completing these tutorials to further advance your Web Experience Factory learning experience.
| Tutorial order | Description |
|---|---|
| Creating a Web Application
Project |
In this tutorial you will learn how to create a web application project. |
| Creating
an application |
In this tutorial, you will build a simple "hello world" application and then create a portlet from that application. |
| Creating
a database application |
In this tutorial, you will use the SQL Table Create builder against a sample database to create a service provider model, and then use the Service Consumer builder and Data Services User Interface builder to create a user interface service consumer model. |
| Using profiling in your new application | Continuing from the "hello world" application tutorial, you add the power of profiling to your application. |
You will create a service provider model against a sample database using the SQL Table Create builder and create a user interface service consumer model using the Service Consumer and Data Services User Interface builder. Your provider model will use the Table Create builder to create a database table from sample data provided in an XML file, and to generate the service operations that turn the model into a service provider. What you learn in this tutorial, including the consumer/provider paradigm and the Data Services User Interface usage, will give you knowledge you will need when using other data providers such as IBM Lotus Domino.
The following setup is required to run the tutorial.
to display a list of builders that can be added
to this model. 
You have completed the step to build a service provider! In the next steps you will create and use a service consumer to work with this provider.
to display a list of builders that can be added
to this model. to display a list of builders that can be added
to this model. from the row of icons immediately below the menu at the top
of the workspace. You will be prompted to save your model. Click Yes to
continue. You see the following page. 
You should see a generated web user interface displaying the first 5 rows of your database table with paging links and buttons and a create button. Try using the application at this point, paging through the rows, updating, creating and deleting records. The entire web application, including the database access, the operations that manipulate the data and the web based user interface including view, details and update pages were generated for you, as a result of the builder calls you created in the last steps. Unlike other wizard based frameworks where you would have to delete the artifacts and start over if you wanted a different variation on this application, you may reopen any of the previous builder calls and modify the inputs, and you may add and remove additional builder calls to customize the generated application.
In a later tutorial, you will also learn how to use profiling to allow for logic based customization of those builder inputs, resulting in automation of variations on the application based on user groups or roles or other custom logic or information available at runtime. Note that the default list user interface is fairly reasonable, but includes all rows and generated labels. We will show how to customize the generated user interface later in this tutorial.
to display a list of builders that can be added
to this model. | Name | Label | Hide | Sort | Field Type |
|---|---|---|---|---|
| EMPNO | [Employee Number] | [Show Always] | On | Integer |
| FIRSTNME | First Name | [Show Always] | [Off] | String |
| MIDINIT | Middle | [Show Always] | [Off] | String |
| LASTNAME | [Last Name] | [Show Always] | On | String |
| WORKDEPT | [Work Department] | Hide only in tables only | [Off] | String |
| PHONENO | [Phone Number] | [Show Always] | [Off] | String |
| GENDER | [Gender] | Hide only in tables only | [Off] | String |
| BIRTHDATE | [Birth Date] | Hide only in tables only | [Off] | Date: yyyy-MM-dd |
| SALARY | [Salary] | Hide only in tables only | [Off] | Currency: #,###.00 |
| [Email] | Hide only in tables only | [Off] | String | |
| COMMENTS | [Comments] | Hide only in tables only | [Off] | Rich Text |
from the row of icons immediately below the menu at the top
of the workspace. You will be prompted to save you model. Click Yes to
continue.Note that the initial view page showing a tabular list of records has a more manageable number of columns for a portlet user interface. At this point, try to edit, delete, and create items in each view.
In this tutorial, you created a service provider model against a sample database using the SQL Table Create builder, and then created a user interface service consumer model, using the Service Consumer and Data Services UI builder. You then customized the user interface with Data Field Settings builder. Again, if you already have a database table, then you would use the SQL Data Services builder directly, rather than the SQL Table Create builder (which wraps SQL Data Services, and adds table creation) as you had above.
Now, you are ready to complete the Using profiling in your new application tutorial where you will you add the power of profiling to an application.
This quick start guides you through the steps to create a widget.
You use IBM Web Experience Factory to run, test, and publish the widget on a locally-installed IBM Lotus Mashups server.
If you are unable to install a Lotus Mashups server on your local development machine, you can establish access to a remote installation of a Lotus Mashups server.
Follow these steps to setup a Mashup server.
If you are deploying to a remote Mashup Center, map a drive to the InstalledApps folder on the server to take advantage of the Auto Synchronize feature. If you do not setup a mapped drive, you will need to Publish your project for running it to see your changes.
Follow these steps to create a widget with Web Experience Factory to use with Lotus Mashups.
If you do not have a spreadsheet available, a default one is provided. The default file is available if your project includes the Tutorials And Samples feature set.
This quick start guides you through the steps to create and test a widget locally, then remotely upload the widget to IBM InfoSphere MashupHub.
You then publish the widget to IBM Lotus Mashups. It is good practice to develop and test against a locally-installed Lotus Mashups server before exporting to a remote server. Follow the steps in this document if you are unable to install a local Lotus Mashups server, or when you are done testing locally and ready to publish to a remote Lotus Mashups server.
IBM Web Experience Factory works in conjunction Lotus Mashups to create the widgets that become part of the mashups page. Typically, developers create the widgets on their local systems, publish them, and test them locally. However, in some cases, developers work in an environment in which they do not have the resources to run a local Lotus Mashups server or perhaps multiple members of the development team must publish widgets to a common Lotus Mashups server. When local development and testing is done, the team publishes the newly-created widgets to a remote server. The remote server could be a production server, an integration server, or quality assurance server.
Web Experience Factory installs an IBM WebSphere Application Server Community Edition (CE) application server. WebSphere Application Server CE is an open source Java 2 Platform, Enterprise Edition (J2EE) application server based on Apache Geronimo. WebSphere Application Server CE provides lightweight testing capabilities for Web Experience Factory. You can test and run the widgets in this environment.
In some development environments, many users must have access to a common server. As Web Experience Factory is integrated with Lotus Mashups and InfoSphere MashupHub, it supports publishing widgets to a remote server.
Follow these steps to setup a Lotus Mashups server.
If your Lotus Mashups server is local, keep localhost. If you are running Lotus Mashups remotely, enter a full DNS host name. In most cases, SOAP Connector Port can remain 8880.
If you are deploying to a remote Lotus Mashups server, map a drive to the InstalledApps folder on the server to take advantage of the Auto Synchronize feature. If you do not setup a mapped drive, you must publish your project before running it to see your changes.
Create a widget.
If you do not have a spreadsheet available, a default one is provided. The default file is available if your project includes the Tutorials And Samples feature set.
Follow these steps to upload the widget to the InfoSphere MashupHub.
Note: If you are already logged into , you must log out and log in again. The only time that Lotus Mashups refreshes the toolbox is at login.
Once you create a project and models, you are ready to start adding builders to your models.
Most well-designed Web applications implement the Service-Oriented Architecture (SOA). In an SOA application, you create models that either call backend services or present a user interface for invoking services. Developing Web applications topics introduce you to creating pages and forms for the user interface or creating the services for calling backend systems.
Building a service-oriented application involves creating a service provider model and a service consumer model.
There is one core builder for the presentation layer:
You can use the Service Definition and Service Operation builders to create a service provider model.
Multiple builders can be used to create a service layer.
To implement an SOA application, create models that are either Service Providers (back-end data access) or Service Consumers (front-end presentation) and then combine them (flexibly) both for application testing and for publishing.
It is often useful to define a service with multiple, related operations, even if the data sources represent more than one back-end system. For example, a customer information service might define operations to return a customer list (based on search criteria), customer detailed information, customer orders, customer complaints, and so on. A product service might define operations for products by category, products by price, product inventory, product costs, product sales performance, and so on.
This example uses a pair of simple service provider and service consumer (presentation) models.
Essentially only two steps are required to build the application:
Once these core pieces are in place, you can add other builders to enhance the service or consumer side as desired.
To further enhance the development of SOA (service-oriented architecture) applications, IBM Web Experience Factory provides additional features that simplify and speed development.
By pressing a button in the Service Definition builder, you can automatically create a stub service model. This completely generated model has an identical interface to the original Service Provider model, but includes an entirely self-contained snapshot of operations, schemas, and sample data. The stub service model eliminates the need for you to be connected to the data source, reducing the hassle of configuring your system and eliminating the need for connecting to a real system such as SAP, IBM Lotus Domino or PeopleSoft or ensuring the local presence of a "developer's" version of the system. If desired, the sample data can be automatically captured from actual result data obtained by invoking the service just once, and then using the disconnected support after that.
If your back-end system is slow in responding or has limited availability, you will save considerable time by using this disconnected development approach. Using a Stub Service model means that the generation process does not need to access the slow back-end for every regeneration cycle.
The Service Test builder lets you automatically generate the pages and code required for testing all the operations defined within a service, including the specification of default inputs for testing each operation. The Service Test builder allows you to easily validate your back-end functionality with complete independence from any presentation layer, and without having to build a separate test harness. You can also generate "headless" methods that call the service operations directly, a capability that is useful for establishing automated testing of services, without having to view browser pages.
The Service Documentation builder automatically generates services documentation on both sides of this dual architecture. It will create information about the service and its operations, including inputs and results, for services created by a Service Provider Model or for services used by a Service Consumer model. Alternatively, a separate documentation model can be used to generate the doc for any services within the WebApp.
To facilitate swapping of Service Provider models, Data Service builders support the notion of a Service interface, similar in concept to a Java interface. The Service Definition builder allows you to specify the name of another Service Provider model that you want to use as the Interface definition. The Interface concept is very useful when you want to develop alternate Service Provider implementations that all work with a common set of presentation (Service Consumer) models. It ensures that you can swap between Service Provider models without breaking the presentation models.
The Service Definition and Service Operation builders automatically provide assistance and verification for accurately implementing the specified Service Interface (the alternate implementation is not automatically generated). The service name, operation names and the number and names of operation parameters are verified. Since input and result types are not included in the verification, you could leverage the adaptive features of Web Experience Factory to implement the service with alternate formats.
You can use IBM Web Experience Factory to develop client-side applications.
The initial page of a client-side web application is loaded from the server and then subsequent requests can be limited to JSON data which is uses to render an updated view on the client mobile device. This development technique typically allows for at least some of the business logic to be done on the client, such as application flow or client side validation.
The advantages of using a client-side approach to developing your mobile web application:
Important requirements and restrictions
The basic architecture for Web Experience Factory client side web application development is to generate and render JSPs that will use HTML, JavaScript, and REST services where the UI and data are joined together on the client device.
Dojo Mobile and Data layout templates
Customizing the Dojo Mobile Theme
To customize the Dojo Mobile theme for your Client Mobile Application, make a copy of the client_dojo_mobile.uitheme (instead of editing the file directly) and then edit the theme values as necessary, paying attention to the inline XML comments in the theme describing what each theme property does and whether it can be changed for a Dojo Mobile Client Application
A project is the foundation of an application in Web Experience Factory.
A project contains all the artifacts required by Web Experience Factory to build the web application, portlet application or widget.
Web Experience Factory Designer wizards are available to help you perform any project operations, such as creating a project, adding Web Experience Factory artifacts to and removing Web Experience Factory artifacts from a project, and modifying project settings.
Most wizards are accessible from a project right-click menu and wizards usually provide default settings that you can change according to your development environment.
The following characteristics describe a typical Web Experience Factory project.
By default, Web Experience Factory projects are located in the Eclipse /workspace directory. However, you can locate a Web Experience Factory project anywhere in your file system. On Windows systems, due to constraints on path name length, there are benefits to locating the project at or near the top of the file system.
The first step in building an application is to create a project.
The created project contains all the artifacts and features required by the application.
/WEB-INF/config/override.propertiesWhen used in a Web Experience Factory project, the Eclipse build operation performs multiple actions.
For example, compiling Java sources into class files and copying property files from source directories to class directories.
For example, to an output location on the application server or to a WAR file.
Web Experience Factory Designer works best if the automatic build setting is enabled (Build automatically under ). Although this setting is enabled by default, sometimes a developer disables it if there are other active projects in the workspace that have large numbers of sources or otherwise take a long time to build.
If it is necessary to run with this setting disabled, a manual build might be necessary in the following circumstances.
When you finish creating the project, you can choose whether to publish a development WAR file or export a production WAR file.
Web Experience Factory can generate two WAR files for you. The Web Experience Factory development WAR file is used when running your application standalone on an application server. The portlet WAR file is used when running your application as a portlet within a portal.
If you have not chosen the Publish Application function, you need to publish the WAR files manually after this process completes. If you have chosen the Publish Application function, the WAR files are publish to the servers specified in your server configuration for your project for you. There is a large amount work being done here, so the publishing process could take from two to three minutes to complete.
If you are using a local installation of WebSphere Portal, security for WebSphere Application Server is enabled by default. As a result, you may be prompted for credentials during the creation of the WAR files. Use the WebSphere Application Server administrator credentials and not the Portal administrator credentials. Also, be sure to wait for this prompt before leaving the publish application function unattended. The prompt times out if you ignore it and your WAR file is not automatically published. In this case, you can still install and configure the WAR file manually with the WebSphere Application Server Administrative Console.
When the process completes, Web Experience Factory displays README editors for the feature sets that you have installed. Read through these files and close them when you are finished. You should be left with an empty (gray) work area.
If the Websphere Administration Server or the WebSphere Portal Server servers are remote, you see an error message below the informational panel. This message states that the development WAR and the EAR that contains it have not been publish. If you have chosen not to publish the portlet WAR automatically or if the portal server was not available, you need to publish that WAR manually with the WebSphere Portal Administrative console.
The development WAR file contains utilities that help speed your development time. A development WAR is built based on the inputs provided in your server configuration. If the server configuration is configured for Publish Application, the widget is published for you when you build a development WAR. If a Mashup server is installed on your system when you install Web Experience Factory, a server configuration named MashupServer is generated automatically, and is configured to automatically publish the widget, as long as the correct credentials are supplied during installation.
To build a development WAR, right-click the project name in the Project Explorer panel. Click to publish the widget. Select the widgets you want to publish and click OK.
The production WAR file is used when your application is ready to be exported to a production environment. The production WAR does not contain the development utilities and is smaller than the development WAR. The production WAR must be manually exported to the server. To build a production WAR, right-click on the project name in the Project Explorer panel. Click and choose the WAR specific to your environment.
If you have not chosen the Publish Application function, you need to publish or export the WAR files manually after this process completes. If you have chosen the Publish Application function, the WAR files are published to the servers for you. There is a large amount work being done here, so the publishing process could take from two to three minutes to complete.
If you are using a local installation of Lotus Mashups, security is enabled by default. As a result, you may be prompted for credentials during the creation of the WAR files. Use the WebSphere Application Server administrator credentials. Also, be sure to wait for this prompt before leaving the publishing process unattended. The prompt times out if you ignore it and your WAR file is not automatically publsihed. In this case, you can still install and configure the WAR file manually with the WebSphere Application Server Administrative Console.
When the process completes, Web Experience Factory displays README editors for the feature sets that you have installed. Read through these files and close them when you are finished. You should be left with an empty (gray) work area.
If the Lotus Mashups server is remote, you see an error message below the informational panel. This message states that the development WAR and the EAR that contains it have not been pub. If you have chosen not to publish the WAR automatically or if the server was not available, you need to publish or export that WAR manually.
You can modify a Web Experience Factory project in a variety of ways.
For example, you can add a feature set to it, or even publish the project to a totally different type of application server. You might also modify a project by creating a WAR from the project. All these options are available from the project popup menu and are accessed by right-clicking the project in Project Explorer.
In the popup menu, you add a feature set by clicking . In the Feature Info pane, you can select the feature set that contains the builders to use in your project.
You can build various types of WARs. In the popup menu, click Publish Application and the choose the appropriate item from the submenu.
By clicking , you can view or change the server configurations that are available to the project.
You can work on a project that is located on a remote machine if you follow some simple guidelines.
Remote projects support team development, where several developers can share access to the same project.
A remote project stores the location of IBM Web Experience Factory in the J2EERoot\.bowstreet configuration file. As a result, if two or more people are trying to work on the same remote project, they must all use the exact same directory location to the project. If you try to import an existing remote project into your workspace and your path is not identical to the path specified in the remote project .bowstreet config file, you can see errors in Web Experience Factory Designer.
You can change the location in which a folder appears in the project tree in Project Explorer or Model Navigator.
To move an item in the Project Explorer tree, follow these steps:
You can rename builders and profile entries and, in some cases, you can edit their definitions as well.
Another point to consider before renaming a builder or profile entry is this: In reconciling references, the renaming process internally performs a simple text search for those references. If, for example, you have a builder named Page2 and another named Page20, and you rename Page2 to Pagex, references to both Page2 and Page20 will be found. In order to weed out references to Page20, you need to preview the changes that the renaming would make (by clicking >Next), deselecting the items that you do not want to change.
To rename a profile entry or builder call, follow these steps:
You can rename a folder, a model, or a profile set.
To rename a resource in the Model Navigator, right click the resource, choose Rename from the resulting popup, and enter the new name.
IBM Web Experience Factory offers extended support for refactoring through the Project Explorer and the Java Package Explorer.
Refactoring through the Project Explorer is recommended because when you move or rename a resource in Project Explorer, all internal references are reconciled. This is not the case if you attempt refactoring in the standard Navigator.
You can take advantage of IBM Web Experience Factory Designer's refactoring capabilities from the Project Explorer to move or rename project folders or the resources they contain.
To move a resource in the tree, click the item in the Project Explorer, and then click Refactor, click Move, and then click the folder to which you want to move the item in the resulting dialog box. Alternatively, you can right click the item and choose from the menu, and then click the folder to which you want to move the item in the resulting dialog box..
Use the Eclipse Export function to create an IBM Web Experience Factory archive file that contains artifacts to be shared in development.
When you create a Web Experience Factory archive, select only models and supporting files. This includes files such as HTML pages, .css files, JavaScript files, profiles, resource bundles, and any Java source files that you create for LJOs.
Do not include any files that are added to a new project by default. If you include other project files in a Web Experience Factory archive, that archive may cause problems when it is imported into another project. The problems occur because some of the project files can be project-specific. A good rule of thumb is to include only files that you create.
You can use the Web Experience Factory Archive Import wizard to incorporate resources from an external source into a project.
Feature sets provide a convenient way of packaging functionality for use by the members of a development team.
A feature set is a set of the necessary files for a builder or set of builders. A feature set may contain models, profile sets, builders, and classes. Feature sets do not add overhead in your application and in the WAR file unrelated to features you are trying to implement. You can add feature sets to or remove feature sets from the project at any time.
Follow this procedure to add a feature set to an IBM Web Experience Factory project.
You can remove a Web Experience Factory feature set from a project.
When you remove a feature set, all files related to the feature set are removed from the project.
You can set the character encoding for certain files used by builders.
A wizard is available to help you create a variety of models.
This wizard populates the models with all the builders required to get a basic application running. The wizard is designed to be self-documenting and easy to use. The choices that you see in the wizard depend on the feature sets that you add to your project. The progression of wizard steps that you see depends on the type of model you choose to create.
Use a IBM Web Experience Factory Designer wizard to create a new model.
)
in the toolbar and click Web Experience Factory
Model. ] in the toolbar, and, in Select a Wizard,
click and Next. You can open a model from Project Explorer or the Model Navigator.
All existing models are stored in the IBM Web Experience Factory WEB-INF/models directory. The Model Navigator presents a subset of the Project Explorer and facilitates easier access to your models and profiles.
When you open a model, Web Experience Factory Designer typically displays the following model-related panels.
Follow these steps to test a service provider.
You can add builder calls to an open model.
] .The builder picker window opens.
You can run a builder call editor for an existing builder in your model.
The editor for the selected builder call opens in the model tab in the builder call editor view.
Follow these steps to convert a builder of one type to another type.
The steps use as an example a Button builder being converted to a Link builder.
The builder is converted to the selected type and the builder call list is updated to reflect the conversion.
Inputs of the original builder are preserved and, where appropriate, intelligently applied to the new builder. In the example cited, the Button Label input value is applied to the Link Text input. All inputs of the original builder are added to the new builder edit page.
You can convert a builder from one type to another type using Convert to in the builder call pop-up menu.
Conversion works for certain builders that are similar and have equivalent inputs. A typical example is provided by the Button and Link builders. These builders are similar and have almost identical inputs. As a result, they are ideal candidates for conversion. Another pair of builders ideally suited for conversion is the Page and Imported Page builder.
In general, builder conversions should involve builders in the same category. For example, convert from one type of builder to another within the Page Controls category or within the Page Modifiers category. Do not attempt to convert builders that are radically different in nature or design.
Sorting the list is useful when you want to organize the list in non-numeric fashion.
Closing models removes their corresponding tab from the model workspace.
Deleting a model removes it from the project.
You should also remove the model from the published application.
To rename a model, choose one of the following:
Saving models commits all builder call changes and model property changes to the model file on the disk.
] in the toolbar.Before you can run (launch) a model, you must have created at least one IBM Web Experience Factory Model launch configuration.
Depending on how you defined the launch configuration, you can:
You can also run a model by entering its URL into a browser window.
Running the model by specifying the URL allows you to call specific actions in the model and pass explicit profiles to the model.
http://localhost:7001/mymodels/CustomerModel/Action!GetCustomersIf your project has been published, you can run the current model in the active model editor.
Use one of the following methods.
Eclipse keeps a history of the launched programs. To rerun a previously launched model, click and click the name in the list.
You can run a model by entering its URL into a browser window.
You can specify the profiles to apply to a model in the URL.
Alternatively, you can use the Applied Profiles view to apply a combination of profiles to the model in the active model editor and then run the active model.
You can run a named model from the IBM Web Experience Factory Designer.
You can use the Eclipse compare editor to compare models in your IBM Web Experience Factory project.
The model compare editor is launched when a model file is compared with another model file, or with a different version of the same model from the local workspace history or from a repository. The model compare editor functions in the same manner as the standard Eclipse compare editor.
The compare editor uses settings from the Compare/Patch preference page. Click to view and change your settings.
The comparison uses the Eclipse structure viewer and compare editor to display the differences between two models in your project.
When model files are compared, the model compare editor opens in the editor area. The model compare editor consists of the Model Structure Compare view and the Model Compare editor.
When you select the top level node in the Model Structure Compare view, the Model Compare editor shows a comparison of builder calls similar to the Outline view when the model editor is active. If you select a builder call node or a builder input node in the tree, the Model Compare editor shows a comparison of the selected nodes as XML text.
In the Model Compare editor, you can browse through all the differences in the builder call lists and copy highlighted differences between the compared resources. You can save changes to resources that are made in the model compare editor. Using the toolbar of the compare editor, you have available the following commands in the toolbar buttons.
Place a model within a container to allow the model to be inserted into a web page.
A model is a collection of builder calls that you can make self-contained.
You can use a Model Container builder to make a model self-contained and allow it to be inserted into a web page. Using multiple models with model containers provides two main advantages:
Using container builders, multiple developers can develop a portion of a page and add their separate models to the page. Each model is assigned to a container, which is a placeholder for the model to be displayed. Models can also contain containers, allowing for unlimited nesting of models within containers. From the point of view of someone accessing the page, the page is displayed as a seamless whole, offering a mosaic of content. However, as a user clicks down into each model, to view details, the overall context of the page remains constant, with only the specific model segment of the page changing.
If you are using a version of IBM Web Experience Factory Designer prior to 6.1.2, to have the addition of the model with the Cooperative Portlet Source builder recognized, open any existing models in Web Experience Factory Designer, regenerate them, and save them.
Each model should declare its own error page and error data.
Follow these guidelines when possible:
Also, the Model Container builder lets you specify a model to load when an error occurs. This model could display an error message and perhaps links to other pages.
You can generate a report for the models that are used in your project.
The Model Inspection tool generates a report about the models in your project. This report summarizes how models are constructed and whether the models follow some of the documented best practices.
If you have a project open in the Web Experience Factory Designer, you can generate and view a summary report and analysis of the models that are used. The output consists of an HTML file and multiple CSV files. The HTML file provides hints and tips about best practices that could be used to improve your models.
The contents of the generated model reports are determined by the defined inspections.
All reports are written to the Reports directory for the project. The report file is named with the following standard format.
Model Report for project name – time.html The name value indicates the project name. The time value indicates the date and time on which the report was generated. Several of the default inspections also generate CSV files that contain builder usage statistics from the report. Using these CSV files, you can sort and rearrange the data to suit your own needs. All the report files have the same time so that you can identify those generated during the same run.
The inspections help you quickly identify models that may not be following best practices or that are built so that they can be hard to maintain and understand. The set of default inspections focus on some of the most common problems the Web Experience Factory engineering team encounters when it reviews customer models. For example, a common problem is the mixing of user interface (UI) and data access builders in a single model rather than separating those types of builders into provider (data access) and consumer (UI) models.
The default set of inspections is based upon the best practices documented in Web Experience Factory product wiki.
\Designer\eclipse\plugins\com.bowstreet.designer.core_7.0.1\configFor more information about creating custom inspections, refer to the Web Experience Factory product wiki.
The pages and forms in your application provide for the viewing of data and the interaction between the user and the application logic and data.
In IBM Web Experience Factory applications, these pages are not typically static, but acted upon by a variety of builders that determine the user interface (UI) for the page directly as well as other builders that affect the page contents indirectly.
Forms and pages are distinct because their development follows different paths. Developing forms primarily involves using two high level builders (for example, Data Page builder and Data Field Modifier builder) to implement UIs that display and prompt for data.
Developing content pages involves a larger number of low level builders that implement different aspects of HTML functionality (for example, Page builder).
You can implement the user interface for your web application by importing existing HTML or JSP pages into the model.
In IBM Web Experience Factory Designer, to do this, use either the Imported Page or Imported Directory builder. For prototyping purposes, you can use the Page builder to create simple HTML or JSP pages.
For any parts of those pages that are to interact with other parts of your model or be made variable for different types of users, you assign calls to the corresponding builders to the named <input /> or <span /> tags in your pages. For example, you could replace an HTML select list with a call to the Select builder. Doing so allows you to determine the selectable options, and other characteristics of the select list from a method, variable, or user input defined elsewhere in the model.
You can incorporate existing HTML and JSP pages into your model.
Use one of the following ways
The Imported Directory builder only adds the HTML and JSP files in the specified directory to the model.
In Web Experience Factory applications, you can display data using one of several techniques, some of which are targeted to the intended server environment and employ varying amounts of automation.
As a general rule, try using the Data Page and Data Field Modifier builders. If they seem to unwieldy for the data or if you find that you need to add many Data Field Modifier builder calls to implement the display and behavior you want, then use the lower-level builder calls.
You can modify the layout of data page elements in multiple ways.
On most pages, you can use drag and drop operations to reorder columns and rows. Using Layout Tools in the Web Experience Factory Designer palette, you can also drag a layout pattern and drop it on your page in the Design panel.
Using a Data Layout builder, you map data page fields in your model to targets in a data layout template and set field types. With the data layout template, you establish support for reusable custom patterns.
Using this feature, you are taking complete control of the HTML page layout and are effectively disabling the automatic generation of the page and losing the benefit of page automation support in your model. Use this capability only when you have some unusual layout and you really need to control the display precisely.
You can use drag and drop operations in the Design panel to modify page automation elements.
You can use a data layout template to modify the layout of pages created by a Data Page builder or builders that use Data Page.
The specified data layout template and layout field mapping are used by a Data Layout builder to modify a layout generated by a Data Page builder. You can use one of the data layout templates that are provided in the product or your own templates to provide reusable custom pattern support.
With a popup command in the model editor, you can directly edit the layout of elements created by a Data Page builder.
In the model editor, the export function is made available on elements created by a Data Page builder or a builder that uses the Data Page builder (for example, View and Form or Data Services User Interface). Elements that can be changed are pages, tables, groups, and fields.
If you used the Data Layout command, an HTML Data Layout builder is added to the model to provide the customizations that you specified in the exported HTML file. The builder uses the exported file to be displayed as this part of the data page.
If you used the Complete Page command, an Imported Page builder is added to the model. The existing page is replaced with the contents of the customized HTML file.
To remove the customizations, you can disable or delete the builder. To make additional customizations, you can edit the exported HTML file.
Follow these steps to add or modify the classes or styles for any named element on a page.
You can manage the validation of user input on a data entry page created by Data Page builder or builders that use the Data Page builder.
These techniques also apply to pages created by any of the builders that use the Data Page builder.
A data entry page is managed by the Data Page builder, on which any of the fields are set to Data Entry, even if the overall page is set to Display Only. (This could happen if you used a Data Field Modifier builder to modify one of the fields to be data entry, even if the overall page is not set that way.)
The Data Page builder can manage presenting a data entry page to the end user and collecting and validating the user responses. It will generate the JSP for the page, according to your settings. It will generate a SaveData method which will collect the values from RequestInputs (where the J2EE server has put them) and save them in your variable. Finally, it will create for you validation operations for the individual fields, and it will add the validation error messages to the JSP page.
In the process of validating fields and displaying the results to the end user, you can control the following aspects:
First, edit the page to add a span where the Full Error text will go. Open the Imported Page builder, click Edit Page. Find the span named data and duplicate that entire line of HTML so it appears twice. Change the word data to be fullError in one of them and click OK on the builder call.
Open the Data Page builder for the inputPage and scroll down to Required Field and Input Validation Settings. Change the error placement to be Separate Column Left of Field and select fullError for the Full Error Placement. Now run the model again, and enter some nonnumeric text in two of the fields and click submit. Note that the placement of the error message has moved, plus the error messages are duplicated in the "Full Error" location. Before you continue, change the error placement back to the right of the field, where it makes more sense.
Generally, when the user completes filling out a Data Entry page and submits it, some action will run. Sometimes you also have a different action that you want to run if there were validation errors. In the Data Page builder, there are two inputs, Success Action and Failure Action. These entries are used in creating the method inputPage_NextAction, which you can see in the WebApp view. If you look at this method, you can see that all it does is test to see whether there were any validation errors for the page and then calls the appropriate action.
If you leave Failure Action empty, as in the sample, then the default failure action is to return to the same page.
The individual field validators by default are generated based on the types of the fields as defined by the schema, WSDL document, or other mechanism. You can disable this behavior in the Data Page builder using the Validate From Schema setting, and the validators will not be automatically created. However, even if you disable it, you still can use Data Field Modifiers to manually set individual validators.
Create a new Data Field Modifier and select just one of the fields on the inputPage. Open the Formatting group and select the formatter com.bowstreet.builders.webapp.pageautomation.StandardFormatter. This should cause some additional inputs to appear, including Validate Expression. Select your own validators (but remember that the service call being invoked is expecting a number for this field). Note that, if you choose RegularExpression(RegExString), then you are given a new input in which to enter a regular expression string. This setting will override the Required/Optional value for the field, since that choice is available here. Change the validator and run the model again to see the new validation strings.
You can control the behavior of a Post-Save method and use it to perform cross-field validation. Sometimes you have additional work that you want your code to do after the data is saved from RequestInputs to your variable. The input Post-Save Method is the hook to use to add your Java code for this process. Also, if the work to do is additional validation of the data entry or perhaps something more complex than individual field validation, there is a way for your Post-Save method to cause validation to fail (forcing the failure action to run) and to include an error message which will be displayed to the user.
Create a new Method builder, and give it the name TestLatitudes. Set the return type to String and fill the method body with these contents:
{
double lat1 = webAppAccess.getVariables().getDouble("MyServiceCall_arg1_lat1");
double lat2 = webAppAccess.getVariables().getDouble("MyServiceCall_arg3_lat2");
if (lat1 == lat2)
return "Make the latitudes different.";
else
return null;
}
The code gets the value of the two latitude inputs from the variable (where they will already have been saved by the Data Page builder) and checks to see if they are the same. (The exact name of those variables is known by looking in the WebApp view and selecting (not opening) the Service Call builder which created them.)
If the two values are the same, the code returns some text, which will be interpreted as an error message by the inputPage_SaveData method. If the two values are different, the code returns a null, which the SaveData method will know means that your Post-Save method did not find any errors. Run the model and try setting the two values the same, and you will see the error message appear. Because this error is not associated with a specific field, the message will only show in the Full Error section.
If you just want to make a Post-Save method that does some work and never returns errors, you can set its return type to void. Also, you may want your Post-Save method to be called only if the individual field validations have executed without error, or you may want it to be called regardless. In the Data Page builder, you can control this behavior with the input Post-Save Method Behavior.
For every Data Entry page, the Data Page builder creates a linked Java object which acts as the error message manager. If you select the LJO inputPageError in the WebApp view, you can see the methods that are available. You can use these methods to set an individual field error message in your Post-Save method. Some developers set this in the Post-Save method since the case was too complex for an individual validator, or because they were planning to use a Post-Save method.
You can also get the individual messages directly to manage the display of the error messages yourself rather than let the Data Page builder manage the display. You can also clear the messages if you are returning to the page with fresh data, and you want to clear the messages that might be left over from the last time the page was visited by the end user.
You can modify some of the settings that are used for validation of a data entry field.
In the model editor in IBM Web Experience Factory, you use the Pages and Design panels to view the form or page to be changed. To change a field validation setting, for example, the error string, use the Data Field Settings builder.
You can use the right-click menu in the model editor to modify some of the settings that are used for displaying a column or a field.
In the model editor in IBM Web Experience Factory, you use the Pages and Design panels to view the form or page to be changed. To change a field display setting, for example, the label, use the Data Field Settings builder.
Data definitions are read from an XML file called a rich data definition (RDD) file.
Rich data definitions are used to clean up a portlet or a widget, for example, by hiding columns that do not need to be displayed. Rich data definitions are associated with a schema in your model. For each field in the selected schema, you can specify labels, control types, lookup tables, formatting, validation, and much more.
A data definition file works by associating user interface (UI) descriptions with a schema. When the schema is used to generate page elements (with Data Page builder or View and Form builder, for example), all of the UI characteristics are automatically applied to the page. By using the functionality of the Data Field Modifier builder, you can learn about specific settings, for example, validation and formatting.
/WEB-INF/factory/data_definitions/bowstreet.baseRddFileYou can use the Default RDD File input in the Data Field Settings builder to override the base RDD file for the project in your model.
You can use builders to modify the data definition information that is associated with a schema in a WebApp for columns and fields on page automation forms and pages. Data definition is one of the internal data structures of the Data Page builder. When Data Page is used with a schema-typed variable, it looks for any data definition information attached to the schema in the WebApp. Those data definition properties become the defaults for any pages based on the schema. However, you can still use other builders such as Data Field Settings, Data Column Modifier, and Data Field Modifier to override the properties specified in the data definition that is associated with the schema.
The association of data definitions to schema elements is done using the element name. A data definition file typically stores a set of structures, with a child data definition for each field in the structure. The parent (structure) name in the schema must match the parent name in the data definition file, and then the individual fields are also matched by name.
Various automatic mappings and data definition properties are used in a rich data definition file.
<SchemaTypeMappings>
<SchemaTypeMap type="date">base_Date</SchemaTypeMap>
<SchemaTypeMap type="boolean">base_CheckBox</SchemaTypeMap>
<SchemaTypeMap type="string">base_String</SchemaTypeMap>
<SchemaTypeMap type="string_enumeration">base_Select</SchemaTypeMap>
<SchemaTypeMap type="char">base_ShortString</SchemaTypeMap>
<SchemaTypeMap type="integer">base_Integer</SchemaTypeMap>
<SchemaTypeMap type="int">base_Integer</SchemaTypeMap>
<SchemaTypeMap type="byte">base_Integer</SchemaTypeMap>
<SchemaTypeMap type="short">base_Integer</SchemaTypeMap>
<SchemaTypeMap type="long">base_Integer</SchemaTypeMap>
<SchemaTypeMap type="double">base_FloatingPoint</SchemaTypeMap>
<SchemaTypeMap type="float">base_FloatingPoint</SchemaTypeMap>
<SchemaTypeMap type="decimal">base_Integer_Internal</SchemaTypeMap>
</SchemaTypeMappings>The type is a schema type to be matched. This is the value that appears for a Field Type for a field in the Data Field Settings builder. The text in the SchemaTypeMap declaration is the data definition to use when a match is found. The string_enumeration type is special. The leaf of a node uses this type if its real schema type is string and it has an enumeration or select choices defined.
Some of the common properties for field settings (and validation settings for data entry fields) are exposed in the Data Field Settings builder and in the Properties view of the Web Experience Factory Designer. Other of these properties are not exposed in any builder call editor, however. To use these properties, you must add them directly to the project base data definition file dojo_base_datadef.xml or base_datadef.xml.
<Attributes>
<Attribute>
<Name>color</Name>
<Value>black</Value>
</Attribute>
<Attribute>
<Name>size</Name>
<Value>${Variables/CurSize}</Value>
</Attribute>
</Attributes>A typical data definition element using some of the above properties to set column width, alignment, sorting status and style might look as follows:
<DataDefinitionElement name="DATE_SHIPPED" base="base_SAPDate">
<Label>Date Shipped</Label>
<Required>false</Required>
<ColumnWidth>400</ColumnWidth>
<ColumnAlignment>right</ColumnAlignment>
<ColumnSorting>Case Sensitive String</ColumnSorting>
<Attributes>
<Attribute>
<Name>style</Name>
<Value>color:red</Value>
</Attribute>
</Attributes>
</DataDefinitionElement>This property takes a number that represents the width of the column in characters.
<ControlElementModifiers>
<BuilderCall use_modifier_dataentry="true" use_modifier_display="true">
<BuilderDefID>com.bowstreet.builders.webapp.AttributeSetterBuilderBuilderDefID>com.bowstreet.builders.webapp.AttributeSetterBuilder></BuilderDefID>
<Inputs>
<Input name = "BuilderCallEnabled">true</Input>
<Input name = "HandleExisting">Skip</Input>
<Input name = "HandleMissingValue">Ignore</Input>
<Input name = "Separator">;</Input>
<Input name = "Attributes">
<top>
<Attribute>
<Name>style</Name>
<Value>color:red</Value>
</Attribute>
</top>
</Input>
</Inputs>
</BuilderCall>
</ControlElementModifiers> <DataEntryControl>com.bowstreet.builders.webapp.TextAreaBuilder</DataEntryControl>
<DataEntryInputs>
<Inputs>
<Input name = "Wrap">off</Input>
<Input name = "Cols">80</Input>
<Input name = "Rows">5</Input>
</Inputs>
</DataEntryInputs>This property is similar to Data Entry Control, but for view-only pages. The corresponding element name for builder inputs is called <DisplayInputs>.
Additional values for container fields include:
You can use this property to set the choices for a field that has a set of possible values. This property does not provide for separate text/values such as lookup table does.
See note below regarding localization of enumeration values.
A typical use this property might look as follows:
<EnumerationValues>
<Value>Shipped</Value>
<Value>Out of Stock</Value>
<Value>Returned</Value>
<Value>In Process</Value>
</EnumerationValues>You can add this property to the rich data definition file. This property takes a string that is used to override an error message for a field that fails validation.
You can use this property to specify a custom formatter class in a rich data definition file. The formatter class uses the same mechanism and interface as the Data Field Modifier builder.
The name of the formatter class is specified with a FormatterClass element as shown below.
<DataDefinition name="AMOUNT" base="base_Currency">
<Label>Amount</Label>
<ColumnSorting>Case Sensitive String</ColumnSorting>
<ColumnWidth>100</ColumnWidth>
<ColumnAlignment>right</ColumnAlignment>
<FormatterClass>com.bowstreet.builders.webapp.pageautomation.StandardFormatter</FormatterClass>
<FormatExpr resource_key="BaseDate_FormatExpr">Format(yyyy-MM-dd$MM/dd/yyyy)</FormatExpr>
<TranslateExpr resource_key="BaseDate_TranslateExpr">Translate(yyyy-MM-dd$MM/dd/yyyy)</TranslateExpr>
<ValidateExpr>Date(yyyy-MM-dd)</ValidateExpr>
</DataDefinition>Substitute the specification of your class for the StandardFormatter. If you omit a FormatterClass element, the StandardFormatter class is used.
Substitute the FormatExpr, TranslateExpr, and ValidateExpr elements appropriate for your data definition.
This can be used to define a default initial value for a field. It is equivalent to setting the Initial Value input of the Data Field Modifier builder.
You can use this property to create a lookup table and associate it with a field. To create a new lookup table, you must specify the builder's ID, and the builder must be one that creates a lookup table in the WebApp (Lookup Table, Domino Keyword Lookup, or SAP Help Values). Specify all the required builder inputs in the Inputs element as shown below.
This example code creates a lookup from XML data using the Lookup Table builder. This functionality has also been used to automatically create and apply an SAP Help Values lookup.
<DataDefinitionElement name="BILLING">
<Label>Billing</Label>
<LookupTable>
<BuilderID>com.bowstreet.builders.webapp.LookupTableBuilder</BuilderID>
<Name>billing</Name>
<Inputs>
<Input name = "DataType">NewXmlData</Input>
<Input name = "GetDataFrom">BuilderInput</Input>
<Input name = "TablePosition">InFront</Input>
<Input name = "Name">billing</Input>
<Input name = "NewXmlData">
<lookup>
<entry>
<name>Purchase Order</name>
<value>1</value>
</entry>
<entry>
<name>Credit Card</name>
<value>0</value>
</entry>
</lookup>
</Input>
<Input name = "ValueElementName">value</Input>
<Input name = "LabelElementName">name</Input>
</Inputs>
</LookupTable>
</DataDefinitionElement><PotentialColumnSorting>Case Insensitive String</PotentialColumnSorting><DataDefinition name="AMOUNT">
<Label>Amount</Label>
<Properties>
<Property name="ColumnWidth">100</Property>
<Property name="ColumnAlignment">right</Property>
</Properties>
</DataDefinition>In this property, specify a value of true to remove a field. The field is not visible, nor is it displayed in other builders, such as the Data Column Modifier or Data Field Modifier.
If you want to define a lookup where the values come from a builder that does not itself create a lookup, you can specify an additional builder to call.
The end result is that the data definition file will cause any number of fields (in every model that references the data def) to be automatically populated with a drop-down lookup, where the values are dynamically retrieved by calling a service. For example, the following XML can be used to invoke a Service Consumer builder to dynamically get lookup values, and then reference the results value in the Lookup Table builder:
<LookupTable>
<Name>companyLookup</Name>
<BuilderID>com.bowstreet.builders.webapp.LookupTableBuilder</BuilderID>
<Inputs>
<Input name = "DataType">XmlData</Input>
<Input name = "VariableType">ValueTagLabelTag</Input>
<Input name = "GetDataFrom">BuilderInput</Input>
<Input name = "TablePosition">InFront</Input>
<Input name = "Name">companyLookup</Input>
<Input name = "XmlData">${MethodCall/companiesGetCompanyList}</Input>
<Input name = "ValueElementName">Value</Input>
<Input name = "LabelElementName">Name</Input>
</Inputs>
<ServiceInfo>
<BuilderID>com.bowstreet.builders.webapp.ServiceConsumer2Builder</BuilderID>
<Inputs>
<Input name = "UseAllOperations">true</Input>
<Input name = "OverrideInputs">false</Input>
<Input name = "Name">companies</Input>
<Input name = "ProviderModel">services/CompanyListService</Input>
<Input name = "OperationName">getCompanyList</Input>
</Inputs>
</ServiceInfo>
</LookupTable>In a rich data definition file, you can create groupings of fields.
<DataDefinitions>
<GroupDefinitions>
<GroupDefinition name="Personal">
<Label>Personal Information</Label>
</GroupDefinition>
<GroupDefinition name="Address">
<Label>Address</Label>
</GroupDefinition>
</GroupDefinitions>
<DataDefinition name="Members">
<Required>true</Required>
<Children>
<DataDefinition name="first">
<GroupName>Personal</GroupName>
<Label>First Name</Label>
<Required>true</Required>
<DataType>string</DataType>
</DataDefinition>
<DataDefinition name="last">
<GroupName>Personal</GroupName>
<Label>Last Name</Label>
<Required>true</Required>
<DataType>string</DataType>
</DataDefinition>
<DataDefinition name="states" base="base_US_States">
<GroupName>Address</GroupName>
<Label>States</Label>
<Required>false</Required>
</DataDefinition>
<DataDefinition name="birthdate" base="base_date">
<GroupName>Personal</GroupName>
<Label>Date Of Birth (MM/DD/YY)</Label>
<Required>false</Required>
</DataDefinition>
<DataDefinition name="birthtime" base="base_time">
<GroupName>Personal</GroupName>
<Label>Time Of Birth (HH:MM AM/PM)</Label>
<Required>false</Required>
</DataDefinition>
<DataDefinition name="salary">
<GroupName>Business</GroupName>
<Label>Salary</Label>
<Required>false</Required>
</DataDefinition>
</Children>
</DataDefinition>
</DataDefinitions>The <GroupDefinitions> elements set up individual groups of fields under corresponding <GroupDefinition> elements.
In a rich data definition file, the base attribute can be used to inherit properties from other data definitions.
For example, here are two of the definitions for typical data fields (QUANTITY and DATE_ORDERED ).
<DataDefinitionElement name="QUANTITY">
<Label>Quantity</Label>
<Required>false</Required>
<ValidateExpr>Optional integer</ValidateExpr>
</DataDefinitionElement>
<DataDefinitionElement name="DATE_ORDERED" base="base_SAPDate">
<Label>Date Ordered</Label>
</DataDefinitionElement>
The definition for DATE_ORDERED is derived from the value in the base attribute. The base_SAPDate definition used for DATE_ORDERED might look something like the following code.
<DataDefinitionElement name="base_SAPDate">
<DataEntryControl>com.bowstreet.solutions.wfm.builders.CalendarPickerBuilder</DataEntryControl>
<DataEntryInputs>
<Inputs>
<Input name = "Format">MM/dd/yyyy</Input>
</Inputs>
</DataEntryInputs>
<FormatExpr>Format(yyyy-MM-dd$MM/dd/yyyy)</FormatExpr>
<TranslateExpr>Translate(yyyy-MM-dd$MM/dd/yyyy)</TranslateExpr>
<ValidateExpr>Optional Date(yyyy-MM-dd)</ValidateExpr>
</DataDefinitionElement>You can hide a column or field that currently displays on a form or page.
If the column or field currently does not display, you can also arrange for it to be shown on the form or page. In the model editor in IBM Web Experience Factory, you use the Pages and Design panels to view the form or page to be changed.
If the model does not contain a related builder for this form or page, a recommended builder is added to the model. If a related builder resides in the model for this form or page, the related input in that builder is updated with your change.
You can modify whether a column can be sorted.
In the model editor in IBM Web Experience Factory, you use the Pages and Design panels to view the form or page to be changed.
If the model does not contain a related builder for this form or page, a recommended builder is added to the model. If a related builder resides in the model for this form or page, the related input in that builder is updated with your change.
You can merge fields so that they are presented as a single field and merge columns so that they are presented as a single column.
You typically have a situation in which your data needs to be in multiple fields. However, when you display the data, you would like these multiple fields to line up on the display as fields that they occupy only one column. For example, a person's address could consist of separate city, state, and ZIP code fields. You can use the Data Field Merge builder to treat separate fields as a single field on a details page or as a single display column.
In the model editor in IBM Web Experience Factory, you use the Pages and Design panels to view the form or page to be changed.
A Data Field Merge builder is added to the model with the settings. You can open the builder call editor and specify a separator character to displayed between the merged fields. You can also rearrange the order of the fields by dragging and dropping them in the builder call editor.
Follow these steps to change the format of a date or other type of field.
Follow these steps to create a data definition file for reuse.
Pages in IBM Web Experience Factory models can be obtained from outside the model or created as you work in the model.
Other builder calls can act on these pages and modify or add to the HTML controls that they display.
The Data Page builder, along with the other builders that use Data Page, can automatically generate HTML for displayed pages. We call this feature “Page Automation”. You can control the look and feel of this generated HTML by using Page Automation HTML Templates.
For more information and real world applications, see this IBM Web Experience Factory wiki article.
The On Named Tag technique is the simplest of the three page location methods and is meant to replace a named element on the page with the JSP code that implements the builder control.
To place a control builder call on a page using the On Named Tag technique:
In placing a control builder call on a page, the relative to named tag technique is a little more complex than the on named tag method.
If you use Relative to Named Tag in the builder Page Location input, you can choose to replace the contents of a named tag, insert a new tag inside the specified tag, or insert a new tag oriented in some way near the named tag. To use the relative to named tag technique, take the following steps.
Each page location technique results in the generation of a Page Location string that determines on what pages, and where on those pages, the control builder calls are added.
The Advanced page location technique allows you to create complex page location strings to locate control builder calls on multiple pages in multiple ways.
The following page location examples are meant to show the flexibility of the page location syntax:
The firstBuilder tag on the StartingPage page.
All locations named firstBuilder on all (non-generated) Pages
In StartingPage, search for an element named firstBuilder. If it is found, that is the node. If not found, search for the XPath "HTML/BODY" and use InsertInsideBottom to insert a new node and name it firstBuilder.
In StartingPage, search for an element named theBody. If it is not found, search for the XPath "HTML/BODY." In either case, use InsertInsideBottom to insert a new node and name it "firstBuilder."
In all pages, just inside the BODY tag insert a new node at the bottom and name it Foo
In all public pages and in Page named Extra, use XPath to search for a FORM tag, then insert a new node inside it at the top. Name the new node Header.
At the three elements named (the element named OKButton on Pages A and B, and the element named OK on Page C), create a new element to the right, and name it Cancel.
For all pages with the property TopLevel set to true, search for a node with the name "AdvancedButton."
For all pages with the property TopLevel set to true, or the property AddAdvanced set to true, search for a node with the name AdvancedButton.
You can profile the individual fields of the Page Location section of builder input, as well as the entire Page Location section.
Coding your model defensively prevents script errors.
Before accessing the element, check whether it exists in the document. Do this by testing whether or not the element is null. If the element is null, it does not yet exist in the object model.
To implement this fix, create a simple function that takes and tests an object. If the test fails, the user receives an error message, and if the test succeeds the code continues to execute as expected. For example:
function isTheObjectAroundYet(object) {
var passed = (object!=null)
if (!passed)
alert("The page is not completely loaded.
Please wait a moment and try again.")
return passed
}
function exampleFunction() {
var theformneededtobeprocessed = document.forms["myForm"]
if (isTheObjectAroundYet(theformneededtobeprocessed)) {
// it's okay to script to the form
}
}This test is appropriate for small, localized tests. However, it may be easier just to test whether the page is loaded. Remember that the onload event does not fire until after the content and all the images on your page have been downloaded. If a user has a slow connection, this means the event may not fire for quite some time. The onload event is necessary in some cases (for example, you want the images to be loaded or you are doing dynamic content in Internet Explorer). However, many times only knowing whether the elements are ready for scripting is required (images that are not yet loaded can still be scripted).
Rather than use the onload event, make the script the last item on your page. For example:
<SCRIPT>
function doLoad() {
// This is the script that will
// execute when the page content is
// loaded
}
</SCRIPT>
<BODY>
...body content...
<SCRIPT>
// The last element in your document
// is a script calling the doLoad()
// function
doLoad()
</SCRIPT>
</BODY>
</HTML>You can create a flag variable for tracking whether the page content is available. This approach can be used instead of testing each individual element.
<SCRIPT>
var isLoaded = false
function doSomething() {
if (isLoaded) {
// run script
}
}
</SCRIPT>
<BODY>
...body content...
<SCRIPT>
// The last element in your document
// is a script that sets the isLoaded
// flag
isLoaded = true
</SCRIPT>
</BODY>In summary, script defensively. Do not discount how different timing can affect your scripts since events and scripts can start executing before a page is completely loaded. Test for the existence of objects, and be careful with the onload event and images.
You can use certain builders to incorporate JavaServer Pages (JSPs) into your models.
The following builders can be used.
In addition to these JSP-specific builders, you can also hand code JSP or use existing JSP in any IBM Web Experience Factory pages (for example, Imported Page builder, Page builder, and Imported Directory builder), as long as they do not perform the following actions.
Web Experience Factory pages are always invoked using include, disallowing these actions.
The Imported Directory builder can often work quite well for bringing in a set of existing JSPs, including inter-page actions and links, provided that they adhere to the caveats above.
If any of the JSP pages that you import for use in a model contain any redirection code, you will need to re-implement this behavior with a method in your model.
<%
response.sendRedirect(response.encodeRedirectURL("http://127.0.0.1:7001/MyApp/results/success.html"));
%>The action that processes this page needs to be altered to include any logic contained in the JSP page and to process the success.html page. You should import the success.html with a call to the Imported Page builder. For example, the method in your model would contain code similar to the following:
...
// incorporate any logic in JSP here.
webAppAccess.processPage("SuccessPage");
...Once you import your pages into a model, you can replace some or all of the HTML controls with calls to the corresponding builders.
To replace an HTML control with a corresponding builder call:
If you do decide to create your own forms, you will need to perform the following steps:
You can define form element style and specify those styles in the Data Page and Data Field Modifier builders.
You can modify the generated HTML page, specifying your own CSS classes in the HTML page and creating the appropriate CSS file.
To confirm that your changes are getting propagated to the model, open the Imported Page builder that imports the page into the model and click OK in the builder call editor.
If you generate a sample HTML page from within the Data Page builder call (from the Advanced group in the builder call editor), the HTML page uses the following CSS class names.
You could use the following CSS style definitions as a starting point. Copy them into an empty CSS file or embed them into a <STYLE /> element in the generated HTML page.
.label { font-family: Arial, Helvetica, sans-serif; font-size:10pt;
font-weight: bold; color: #004E8E}
.sectionLabel { font-family: Arial, Helvetica,
sans-serif;font-size: 14pt; font-weight: bold; color: #000000}
.outputData { font-family: Arial, Helvetica, sans-serif;font-size:
10pt; font-weight: bold; color: #000000}
.entireTable { background-color: #e0e0e0}
.tableHead {background-color:#404040;color: #ffffff;font-family:
Arial,Helvetica,sans-serif; font-size: 10pt;font-weight: bold; }
.tableRow {background-color: #e0e0e0; color: #000000;font-family:
Arial, Helvetica, sans-serif; font-size: 10pt; }
.tableRowEven {background-color: #e0e0ff; color:
#000000;font-family: Arial, Helvetica, sans-serif; font-size: 10pt;
}
.tableRowOdd {background-color: #e0e0e0; color:
#000000;font-family: Arial, Helvetica, sans-serif; font-size: 10pt;
}
.Required {font-family: Arial, Helvetica, sans-serif;
font-size:10pt; font-weight: bold; color: #ff0000}
.ErrorMessage {font-family: Arial, Helvetica, sans-serif;font-size:
10pt; font-weight: bold; color: #ff0000}This topic describes how to add the Style Setter builder to add classes or styles to any named element on the page.
Use the Data Page builder to create forms that prompt the user for input.
You can create forms in IBM Web Experience Factory applications in several ways.
In many cases, the framework provided by the Data Page and Data Field Modifier builders offers enough extensibility to implement sophisticated forms. If you have requirements that cannot be implemented with these builders, you can create your own forms using individual builder calls or even your own forms framework. Forms that you implement with the Data Page and Data Field Modifier builders provide a much more robust framework for handling form display and for validating inputs, processing inputs, and handling errors.
You can use the Data Page builder to create forms that prompt the user for input and to automate the display of input controls and the processing of inputs.
Use the Input Form Builder when you want to create an input page for my data service operation, which does not return result data. This builder creates an input page for a data service operation or a method. It is much like View & Form input page support, but the next action after submitting the input form is a user-specified action. This builder is suitable for operations that do not have result data to display.
Because the Data Page builder uses a schema to control its behavior, you can change the form simply by altering the schema that defines the form input.
The Data Page builder inserts the input form at a named location on a page in the model. This page can be as simple as the page1 page included in the Main and Page base model or it can be an imported page that has been created by an HTML designer. If the page contains input elements, the Data Page builder can map the elements in an XML variable to these inputs. You can also configure the Data Page builder to determine the input fields to display based on a schema associated with the variable or a combination of the input fields defined on the page and the elements defined by the schema.
Use the Data Field Modifier builder to override form behavior.
For any given element in the data, you can override the behavior the Data Page implements by using Data Field Modifier builder call, specifying the builder you'd like to use to control the element's behavior. In general, you override the default behavior for an element if you cannot adequately determine the elements behavior in the HTML page or in the schema associated with the data.
Some specific use cases that call for overriding the Data Page functionality include:
To override an element default behavior with a form created using the Data Page builder, add a Data Field Modifier builder to your model and specify the element whose behavior you want to change.
You can determine the appearance of your display or input form.
Supply your own HTML page that implements the layout and display you want. The Data Page builder reconciles the named <input /> and <span /> tags in the HTML you provide with the element names in the data. In the Data Page builder call, choose to have the form be determined solely by the HTML page, solely by the associated data schema, or by both the HTML and schema. If the HTML page contains tables to display repeated elements, either specify the table completely or just with a table and row name. Deriving table appearances with both the HTML page and schema is not good practice.
Just as you can limit the data shown in a table by limiting the named <span /> or <input /> tags used, you can display additional data to the table by adding a named <span /> or <input /> tag to the table and using some other builder call to display data from another source. For example, if you want to display the email address for each customer in the sample data, you add another <td /> element to the customer row and populate this column from a variable containing the email addresses for each customer.
Use various builders and CSS styles to modify an input form.
You can alter the layout of a form generated by the Data Page builder.
Use a Data Field Modifier builder to hide or control the display of an element of the data. You can hide an element of the form data by using a Data Field Modifier builder call, specifying the element you want to hide, and enabling the Hide Element input.
By default, the Data Page builder vertically displays non-repeating elements, such as the <street />, <city />, <state />, and <zip /> elements in the sample data. To display these elements horizontally, set the Fields input to the element that contains the non-repeating elements (in this case, <address />) and enabling the Horizontally option for the Container Display Direction.
By default, the Data Page builder displays repeating elements in a table. To display repeated elements vertically, set the Fields input to the element that contains the repeating elements and enabling the Vertically option for the Container Display Direction input.
You can create a form from multiple variables generated by the Profiled Web Service Call builder.
Service calls often define several inputs for a particular service call operation. You can configure the Profiled Web Service Call builder to generate variables from which it gets the value for the corresponding input to the service call. (Use the Web Service Call builder if you have the operation defined in a WSDL document.) To generate an input form for these inputs, you can use a Data Page builder call, specifying all the input variables generated by the service call.
The following steps outline the process of configuring the service call to generate variables and setting the Data Page builder call to generate a form based on those variables.
You can redisplay a form page, resetting the form values to their initial values.
To initialize a form, perform the following steps.
In a simple form in which you access the contents of an XML variable, you can display the data based on the contents of the XML variable.
You can create a model that you can use to experiment with the Data Page builder and its various features.
The form resulting from the model is basic, but serves to provide a context for other form-related tasks, for example, altering the layout of a form, specifying CSS styles for form elements, and setting input labels.
This is a sample XML form.
<customers>
<customer>
<name>Joe</name>
<id>1122</id>
<address>
<street>416 Lowell St.</street>
<city>Andover</city>
<state>MA</state>
<zip>01810</zip>
</address>
</customer>
</customers>You can create a "View Only" form that displays the contents of an XML variable.
You can use the input controls on a generated page to specify elements that the user can change.
Use the Button builder, the Link builder or HTML event action for form submittal.
To add a control that allows the user to submit the form:
If the model has a page on which the Data Page builder can place (or work with) a form, configure the Data Page builder call to implement the form behavior you want.
The Data Page builder can operate on input forms, view-only forms, or forms that mix input and view-only fields. These instructions pertain to creating an input form. To configure the Data Page builder call to create an input form:
Use the Data Page builder to create a sample HTML page for the input form.
To create a sample HTML page using the Data Page builder:
Use the the Data Page builder to modify all labels in a form.
To generate a properties file for all the form fields:
To alter the label for just one element in the data, use a Data Field Modifier builder.
You can override default labels that are generated by the Data Page builder.
The Data Page builder generates the labels for each form field according to element names defined in the schema associated with the data being displayed on the form. For example, the input label for an element <customer /> is "customer". Typically, you set your own label for each form field.
You can override the default input labels by using a properties file that lists each element name and the label to use for each. For example, <customer=Customer Name> could be one entry in the properties file. In the form, the field corresponding with the <customer /> element in the data would be Customer Name.
You can use the Data Page builder to generate a properties file containing an entry for each element on the form. You can then specify this properties file as the resource bundle for the Data Page builder to use.
You can configure the Data Page builder call to generate an HTML page based on the data.
If you create the HTML page for use with a Data Page builder, you can control how the Data Page creates this table.
This technique uses an empty <table name="ContainerElement "/> node in your HTML page on which the Data Page constructs the table for you.
This technique applies if you want to control more precisely the layout of the table.
Follow these steps to allow the HTML page to determine the elements to display in the table and the table's appearance.
The Data Page builder provides you with the ability to display the results of a service call, SQL statement, or any other builder call that provides data.
To display data with the Data Page builder:
Regardless of the source of the data, the Data Page builder operates on a variable in the model.
Service calls store their results in the ServiceCallName_reply variable and you store the results from an SQL statement in a variable by using the SQL Transform to XML builder call.
If you want to display all the data in a variable, set the Data Page builder call's Variable input to the name of the variable that contains the data you want to display.
If you want to display a portion of that data, use the reference chooser to "walk" down the XML structure to the node that you want to display.
Use the Date / Time Formatter builder to control the display of date and time values in a specific format.
This builder changes the default date and time format of the server so that all date and time variables in a model are assigned the same format. To specify a particular date and time format for the server, perform the following steps.
When you run a model that includes this builder, you see dates and times in the formats you specify. Remember, the formats that you select are overriding the formats set by the server and apply to the contents of all Date, Time, and DateTime variables in the model.
The Data Field Modifier builder can be used to validate dates and times.
The Date/Time Formatter builder can be used to validate dates and times.
Use the steps in this description to do specialized, detailed formatting of fields.
To perform limited changes to settings that are used for displaying fields, used the Data Field Settings builder.
com.bowstreet.methods.IInputFieldFormatterIBM Web Experience Factory Designer provides several builders you can use to control the formatting of date, time, and datetime values.
In most cases these values are stored in variables, and their formats can be controlled individually or globally throughout the model or application. You can customize date and time formats for display, and also perform validation of user input of date and time values. The IBM Web Experience Factory Designer includes a StandardFormatter class that is used to control date and time formatting operations.
There are two ways you can validate Data or Time input data.
A formatter class provides formatting and validation functionality for the fields and inputs controlled by a Data Field Modifier builder call.
The formatter takes raw phone number data (for example, 2075558487) and formats it to either a dot-separated format (for example, 207.555.8487) or a dash-separated (for example, (207)555-8487) format. It also makes sure that the user enters only numeric characters with its validate method.
You can implement any number of format, translation, or validation operations in a single formatter class.
As you begin development of your formatter class, implement the IInputFieldFormatter interface.
import java.util.List;
import java.util.ArrayList;
import com.bowstreet.methods.IInputFieldFormatter;
import com.bowstreet.webapp.WebAppAccess;
public class SimpleFormatter implements IInputFieldFormatter
{
}The imported classes are used to build the expression lists and to interact with the webAppAccess object.
The format method examines the expression it receives and calls the appropriate operation, passing the value as an argument to that operation.
public String format(String value, String expression) {
String result = null;
if(getErrorMessage() == null) {
if (expression.equals(PHONEDOTS)) {
result = phoneWithDots(value);
}
else if (expression.equals(PHONEDASHES)){
result = phoneWithDashes(value);
}
}
else {
result = value;
}
return result;
}In this case, the format method checks to see if the expression equals one of the expression constants defined earlier. The following code snippets show the phoneWithDots and phoneWithDashes methods.
String phoneWithDots(String value) {
String dotvalue = value.substring(0,3)+ "." + value.substring(3,6) +
"." + value.substring(6,value.length());
return dotvalue;
}
String phoneWithDashes(String value) {
String dashvalue = "(" + value.substring(0,3)+ ") " + value.substring(3,6) +
"-" + value.substring(6,value.length());
return dashvalue;
}Before adding the code that does the formatting, translating, and validating, you need to facilitate the creation of the various expression lists and some error message text.
private String errorMessage;
private WebAppAccess webApp;
protected static List formatExpressionList = null;
protected static List translateExpressionList = null;
protected static List validateExpressionList = null;
// Set constants for format expressions
public final static String PHONEDOTS = "Phone # with Dot Separators";
public final static String PHONEDASHES = "Phone # with Dash Separators";
// Build up array of format expression constants
private static final String[] formatExpressions =
{
PHONEDOTS, PHONEDASHES
};
// Use the makeList method to build up the expression lists
static
{
formatExpressionList = makeList(formatExpressions);
//translateExpressionList = makeList(translateExpressions);
//validateExpressionList = makeList(validateExpressions);
}
// You can create your own way to build up the expression lists or copy this one
protected static List makeList(String[] array)
{
List list = new ArrayList(array.length);
for (int i = 0; i < array.length; i++)
list.add(array[i]);
return list;
}Also, the IInputFieldFormatter interface declares methods to get and set these resources. The following code shows simple implementations of these methods:
/* These methods are quick implementations of those defined in the IInputFieldFormatter
*/
public void setErrorMessage(String msg) { errorMessage = msg; }
public String getErrorMessage() { return errorMessage;}
public void setWebAppAccess(WebAppAccess webApp) { this.webApp = webApp; }
public WebAppAccess getWebAppAccess() { return webApp; }
public void setTranslateSuccessFlag(boolean parm1) { }
public boolean getTranslateSuccessFlag() { return true; }
public List getFormatExpressionList() { return formatExpressionList; }
public List getTranslateExpressionList() { return translateExpressionList; }
public List getValidateExpressionList() { return validateExpressionList; }When the users enter a phone number, they may enter it without any separators or use some sort of separator such as dots or dashes.
public String translate(String value, String expression) {
String result = null;
if (expression.equals(PHONEDATA)) {
result = stripPhoneNumber(value);
}
return result;
}As in the case for the format method, the translate method checks to see if the expression equals one of the pre-defined expression constants and calls a method supplying the value as its argument. The following code example shows the stripPhoneNumber method:
private String stripPhoneNumber(String value) {
String result = value;
String temp = value;
if(value.indexOf('.') > -1) {
temp = value.trim();
StringBuffer sb = new StringBuffer(temp);
for(int i= sb.length() - 1;i > -1;i--){
char c = sb.charAt(i);
if (c == '.'){
sb.deleteCharAt(i);
}
}
result = sb.toString();
} //end if
else if (value.indexOf('-') > -1) {
StringBuffer sb = new StringBuffer(temp);
for(int i= sb.length() - 1;i > -1;i--){
char c = sb.charAt(i);
if (c == ' ' || c == '(' || c == ')' || c == '-'){
sb.deleteCharAt(i);
} //end if
}
result = sb.toString();
}
return result;
}The validate method follows the process of analyzing an expression and calling the appropriate method to perform the actual operation; in this case validating that the user used only numeric characters for the phone number input.
public boolean validate(String value, String expression) {
boolean result = false;
if(expression.equals(VALIDATEPHONE)) {
result = validatePhoneNumber(value);
}
return result;
}The validatePhoneNumber method checks to see if the value argument is only made up of numeric characters:
boolean validatePhoneNumber(String value) {
boolean result = true;
char ch;
for(int index = 0; index < value.length(); index++) {
ch = value.charAt(index);
if (ch<48 || ch>57) {
result=false;
setErrorMessage("Phone numbers cannot include letters.");
}
}
return result;
}In the code example above, notice that if a character was found to be outside of the ASCII range of numeric characters, the code calls the setErrorMessage method, setting the message string with an appropriate error message.
package doctest.datapage;
import java.util.List;
import java.util.ArrayList;
import com.bowstreet.methods.IInputFieldFormatter;
import com.bowstreet.webapp.WebAppAccess;
public
class SimpleFormatter implements IInputFieldFormatter
{
private
String errorMessage;
private WebAppAccess webApp;
protected static
List formatExpressionList = null;
protected static List translateExpressionList
= null;
protected static List validateExpressionList = null;
public
final static String PHONEDOTS = "Phone # with Dot Separators";
public
final static String PHONEDASHES = "Phone # with Dash Separators";
public
final static String PHONEDATA = "Translate Phone # to Data Fromat";
public
final static String VALIDATEPHONE ="Validate Phone #";
private static
final String[] formatExpressions =
{
PHONEDOTS, PHONEDASHES
};
private
static final String[] translateExpressions =
{
PHONEDATA
};
private
static final String[] validateExpressions =
{
VALIDATEPHONE
};
static
{
formatExpressionList
= makeList(formatExpressions);
translateExpressionList = makeList(translateExpressions);
validateExpressionList
= makeList(validateExpressions);
}
/**
* @see com.bowstreet.methods.IInputFieldFormatter#format(String,
String)
*/
public String format(String value, String expression)
{
String result = null;
if(getErrorMessage() == null) {
if
(expression.equals(PHONEDOTS)) {
result = phoneWithDots(value);
}
else
if (expression.equals(PHONEDASHES)) {
result = phoneWithDashes(value);
}
}
else
{
result = value;
}
return result;
}
/**
*
@see com.bowstreet.methods.IInputFieldFormatter#translate(String, String)
*/
public
String translate(String value, String expression) {
String result =
null;
if (expression.equals(PHONEDATA)) {
result = stripPhoneNumber(value);
}
return
result;
}
/**
* @param value The input value to be validated.
*
@param expression The description of the validation method to be performed.
*
*
@see com.bowstreet.methods.IInputFieldFormatter#validate(String, String)
*/
public
boolean validate(String value, String expression) {
boolean result =
false;
if(expression.equals(VALIDATEPHONE)) {
result = validatePhoneNumber(value);
}
return
result;
}
/* These methods are quick implementations of those
defined in the IInputFieldFormatter
*/
public void setErrorMessage(String
msg) { errorMessage = msg; }
public String getErrorMessage() { return
errorMessage;}
public void setWebAppAccess(WebAppAccess webApp) { this.webApp
= webApp; }
public WebAppAccess getWebAppAccess() { return webApp; }
public
void setTranslateSuccessFlag(boolean parm1) { }
public boolean getTranslateSuccessFlag()
{ return true; }
public List getFormatExpressionList() { return formatExpressionList;
}
public List getTranslateExpressionList() { return translateExpressionList;
}
public List getValidateExpressionList() { return validateExpressionList;
}
String phoneWithDots(String value) {
String dotvalue = value.substring(0,3)+
"." + value.substring(3,6) +
"." + value.substring(6,value.length());
return
dotvalue;
}
String phoneWithDashes(String value) {
String
dashvalue = "(" + value.substring(0,3)+ ") " + value.substring(3,6) +
"-"
+ value.substring(6,value.length());
return dashvalue;
}
/**
*
Method stripPhoneNumber.
* @param value
* @return String
*/
private
String stripPhoneNumber(String value) {
String result = value;
String
temp = value;
if(value.indexOf('.') > -1) {
temp = value.trim();
StringBuffer
sb = new StringBuffer(temp);
for(int i= sb.length() - 1;i > -1;i--){
char
c = sb.charAt(i);
if (c == '.'){
sb.deleteCharAt(i);
}
}
result
= sb.toString();
} //end if
else if (value.indexOf('-') > -1)
{
StringBuffer sb = new StringBuffer(temp);
for(int i= sb.length()
- 1;i > -1;i--){
char c = sb.charAt(i);
if (c == ' ' || c ==
'(' || c== ')' || c== '-'){
sb.deleteCharAt(i);
} //end if
}
result
= sb.toString();
}
return result;
}
boolean validatePhoneNumber(String
value) {
boolean result = true;
char ch;
for(int index =
0; index < value.length(); index++)
{
ch = value.charAt(index);
if
(ch<48 || ch>57)
{
result=false;
setErrorMessage("Phone
numbers cannot include letters.");
}
}
return result;
}
protected
static List makeList(String[] array)
{
List list = new ArrayList(array.length);
for
(int i = 0; i < array.length; i++)
list.add(array[i]);
return
list;
}
}</p>You can create a table that uses a button to add a row.