Bean Master Detail Builder

Bean Master Detail Builder

In this topic ...

Quick Tips
Specifying Inputs
Building Views
Objects this Builder Creates

Related Topics ...

Data Page Builder
Lookup Table Builder

Use this builder to access data and information stored in the form of a Java Bean. The builder will introspect a bean to discover any getters and setters on the bean. This builder will accept a reference to a collection of beans or an iterator on a collection of beans. This builder supports create, edit, update and delete operations on beans. We can use methods generated by this build to call other methods you've written to operate on the back-end database.
If you have a single bean object that you want to interact with, use the Data Page Builder to access it directly.
The Bean Master Detail Builder takes a reference to a collection of Java Beans and creates a table view that includes create and edit forms for that Bean, the navigation mechanisms between those views, and hooks for tying in user-provided methods at significant stages of the flow.
We can place multiple Bean Master Detail builders on a single page allowing an object and its associated collections to be displayed together. For example if the application has a collection of "Offices" and an Office has an associated collection of "Departments," the Bean Master Detail builder responsible for showing Departments can draw its view from the currently selected Office. When the page renders the view of the selected Office the correct associated Departments will be displayed as well.

How this Builder Works

The significance of "Bean" in the builder name is that the class name provided to the Builder follows a Bean coding convention. Specifically that it follows the pattern whereby if the class has a float attribute called "amount" then it will have a getter of style public float getAmount() and optionally a setter of style public void setAmount(float newvalue). This allows the Builder during regeneration to introspect the class, determine the available attributes and build up forms with those attributes.
Depending on the functionality chosen for the builder instance (to optionally generate/ not generate view, delete, create, edit functions) this builder will add and configure four Data Page Builders into the model one for the table view, and three others for the view, create and edit functions. Since this Builder rests on top of Data Page builder functionality, the Bean Master Detail output can be customized if desired by adding Data Field Modifiers and Data Column Modifiers and the Data Page validation mechanisms are available.
The attributes shown in the main collection are any of the following Java simple and Object types for which a public getter is supplied: boolean, Boolean, byte, Byte, Character, double, Double, float, Float, int, Integer, long, Long, String.
Placement of the views on a page and the navigation (buttons and links) between views is configurable by overriding a set of default span tags that are listed in the builder. Also, since the generated Data Page objects are visible in the model, we can architect a custom flow if desired.

Locating Your Java Classes Files

When working with builder you will be using your own Java classes. For your classes to be visible to the Designer and at runtime place the classes in the WEB-INF/work/classes directory or place a jar file containing your classes in the WEB-INF/work/lib directory.
When the generated Java methods are compiled by the application server the Java compiler needs to be able to access the bean classes. If you added your bean classes to /work/classes or /work/lib then you need to add "${bowstreet.rootDirectory}/work/classes;" (or /work/lib) to the bowstreet.methods.classPath in WEB-INF/config/cluster.properties.

Quick Tips

Locating Class Files - When the generated Java methods are compiled by the application server the Java compiler needs to be able to access bean classes. If you added your bean classes to WEB-INF//work/classes or WEB-INF//work/lib directory, we need to add "${MyApp.rootDirectory}/work/classes;" (or /work/lib) to the bowstreet.methods.classPath property in WEB-INF/config/cluster.properties file.
If you select "Make UI from Bean attributes" you can manipulate column appearance and behaviour by applying Data Field Modifier builders to the columns.

Edit and Delete columns are automatically added to the Table if "Make UI from Bean attributes" is selected. If you choose "Use existing tags on page, " then for the Edit / Delete links to show up on the table we need to also add those tags to your HTML. This sample HTML illustrates this technique:

<TABLE name="fred" class="entireTable">
<TR class="tableHead">
<TD>name</TD>
<TD>logo</TD>
<TD>version</TD>
</TR>
<TR name="repeat">
<TD><SPAN name="OrgChart__name" /></TD>
<TD><SPAN name="OrgChart__logoURL" /></TD>
<TD><SPAN name="OrgChart__version" /></TD>
<TD><SPAN name="Edit" /></TD>
<TD><SPAN name="Delete" /></TD>
</TR>
</TABLE>

Specifying Inputs

The Bean MasterDetail builder takes the inputs described in the table below. For help on inputs common to many or all builders such as those in the Properties and HTML Attributes input groups, see "Using the Builder Call Editor."

Input Name Description
Name Required. Typically if the objects being displayed are com.acme.Offices the name supplied would be "offices" for consistency.
The name provided will be used as a prefix to many of the generated model artifacts. In particular (if the name supplied is "offices") "offices_viewObject" is the "currently selected" object when rendering the view or edit pages.
To place another Bean MasterDetail builder on the same page showing the associated Departments, we can do so by referencing the "offices_viewObject" in that other Builder
Master / Table View
Collection Required. Object in the WebApp that will be the source of the data at runtime. This content is under the user s/application control and the collection is examined when the page is rendered.Changes made to the set of objects in the collection will be reflected in the rendered page.
The object being returned must be an instance of java.util.Collection or java.util.Iterator.
The Builder does not take a copy of the collection, it maintains a reference to it.
Example:
${Variables/orgcharts}
Bean class name Required. Class (or Interface) that is examined at regen time and from which the WebApp artifacts are generated.
The class (and its superclasses) MUST be visible to the Eclipse plugin at Design time, as well as the J2EE context at runtime.
To make the class visible to the Eclipse plugin you can place the class in a jar that is registered in the WebSphere Portlet Factory Designer ("com.bowstreet.designer.core_5.12.0") plugin.xml file. But, the simplest way is to place the class files in the "WEB-INF/work/classes" directory of the J2EE context that the Designer is looking at it will then be visible to both Design time and runtime regen actions.
Example:
"com.bowstreet.qa.beans.Office
Imported page URL Optional. If the "Page in model" is not supplied this input is required.
Page on which the table view of the collection will be placed. The page will be added to the model as "offices_mainPage" (if the BuilderName is "offices") and the table view will be added at the span tag called "data". (Overrideable in the Tag location mappings section).
Example:
/factory/pages/beancurds_dataviewpage.html
or Page in model Optional . If the "Imported Page URL" is not supplied this input is required.
Page on which the table view of the collection will be placed. The table view will be added at the span tag called "data". (Overrideable in the Tag location mappings section).
Example:
"mainpage".
Paged data display Optional. When checked, paging buttons are added below table.
Rows per page Optional. Number of rows per page of data.
General UI Options
Auto-generate UI Required. This input carries interacts with an underlying Data Page builder for the View and Edit pages and specifies whether the attribute names and values are shown at specific named (matching) locations on the HTML page, or if the names and values are generated automatically into the HTML page starting at a particular tag location.
Navigation Style Required. The navigation style between pages is selectable, as either Buttons or Links.
The span tags on which these navigation buttons/links are placed (and their labels) are configurable in the Tag location mappings section.
View Detail Options
Allow View Detail Required. This checkbox determines if a "view detail" page is generated. If it is generated, a link will be placed on a selectable column in the main collection table. At runtime when that link is clicked the page showing the detail view for that chosen object will be rendered.
If the Builder is called "accounts", when the link is clicked the Linked Java Object in the WebApp called "accounts_viewObject" will be set to reference the chosen object in the main collection. Anything else on the rendered page that is sourced from "accounts_viewObject" in some way will show the correct related data.
Column for link Required if Allow View Detail is selected. When the Bean classname is specified in the Builder UI this Builder input is automatically populated by introspecting the specified class.
The only attributes shown in this selection are those that are valid for the main collection view (see list in "How Does This Builder Work").
Imported page URL Optional. If the "Page in model" is not supplied this input is required. This is the page onto which the detail view of the object will be placed. The page will be added to the model as "offices_viewPage" (if the BuilderName is "offices") and the view will be added at the span tag called "data". (Overrideable in the Tag location mappings section).
Eg, "/factory/pages/beancurds_dataviewpage.html"
or Page in model Optional. If the "Imported Page URL" is not supplied this input is required. This is the page on which the detail view of the object will be placed. The view will be added at the span tag called "data". (Overrideable in the Tag location mappings section).
Eg, "officepage".
Use Detail-specific class Optional. This checkbox enables some advanced functionality in this builder. (See Building Views below for more detail and examples). If the object you wish to display in the detail view is a physically different object from the one in the collection, ie, a "thicker" version with much more detail (more attributes), this checkbox enables the additional inputs needed to allow that detail object to be displayed when the "thin" object in the collection view is clicked.
Detail class name Optional. Required if Use Detail-specific class is selected. The classname or Interface of the detail object.
Eg, com.bowstreet.qa.beans.OfficeDetail
Accessor class Optional. (Required if Use Detail-specific class is selected.)
When the object in the main collection table is clicked, the generated runtime logic is to invoke the static method (named below) on the classname provided here.
Eg, com.bowstreet.qa.beans.Office
Accessor method Optional. (Required if Use Detail-specific class is selected.)
When the object in the main collection table is clicked, the generated runtime logic is to invoke this static method on the classname named above, passing in as arguments the values (named below) from the selected object.
Eg, fetchDetailByName
Field names Optional. (Required if Use Detail-specific class is selected.)
When the object in the main collection table is clicked, the generated runtime logic is to invoke the static method named above on the classname named above, passing in as arguments these attributes from the selected object.
Eg, name
Edit Options
Allow Edit Required. This checkbox determines if an "edit" page will be generated.
If edit page is generate,d an Edit link/button will be placed on the view page, and optionally an Edit column will be added to the main collection table. At runtime when that link is clicked the page showing the chosen object in edit mode will be rendered.
Only the attributes for which public setters exist will be opened up for edit, the other attributes will be display-only. As with the view detail, if the Builder is called "accounts", then when the link is clicked the Linked Java Object in the WebApp called "accounts_viewObject" will be set to reference the chosen object in the main collection.
When the edit page is submitted a generated action list called "offices_doSave" (if the BuilderName is "offices") will be invoked.
Imported page URL Optional.( If the "Page in model" is not supplied this input is required.)
This is the page on which the edit view of the object will be placed. The page will be added to the model as "offices_editPage" (if the BuilderName is "offices") and the view will be added at the span tag called "data". (Overrideable in the Tag location mappings section).
Example: "/factory/pages/beancurds_dataviewpage.html"
or Page in model Optional. If the "Imported Page URL" is not supplied this input is required. This is the page onto which the edit view of the object will be placed. The view will be added at the span tag called "data". (Overrideable in the Tag location mappings section).
Example: "officepage".
PreApply Method Optional. At runtime when the page containing the edits is submitted this method (if supplied) will be invoked from the "<name>_doSave" method. The method supplied must take a single Object argument. When the method is called the object passed to it will be the edited object BEFORE any changes have been applied (ie, the "<name>_viewObject" as it was when it was rendered on the edit page.
Calling this method provides a hook to start a transaction,acquire a JDO persistence manager, or even apply validation additional to that occurring in the object setters.
PostApply Method Optional. After the PreApply Method has occurred the "_doSave" method will invoke "<name>_editPage_saveData" which will apply the submitted values (for all of the editable attributes on the page) to the "<name>_viewObject". If no errors occurred (either detected by the DataPage validation or in the object s own setter methods by way of throwing an Exception) this PostApply Method will be invoked.
As with the PreApply Method, this method is expected to take a single Object argument which will be the "<name>_viewObject" AFTER the updates have been applied to it.
Calling this method provides a hook to commit a transaction.
Save Error Action Optional. If Validation style selected is to perform validation and/or to catch Exceptions, the page specified here will be called.
Validation Optional. This determines the level of validation and error handling to be included in the Edit mechanism (within the generated "<name>_editPage_saveData" method). The available options are:

Do not add validation or catch exceptions from setters - Causes eceptions thrown in the PreApply, "<name>_editPage_saveData" or PostApply methods to drive the Save Error Action. If no Save Error Action is specified the Default Error page will be rendered, or the error handler specified in the model.
Perform field type validation before applying setter - Invokes the regular DataPage validation mechanism to populate a "<name>_editPageError" Variable in the webapp with any datatype errors identified in the inputs. When an error occurs the edit page will be re-rendered and the detected errors will be displayed on the page next to the fields that caused them.
Catch exceptions thrown from the setter - Omit the initial DataPage type validation but will catch any exceptions thrown from the setters, populate the "<name>_editPageError" and re-render the edit page
Perform validation prior to setter and catch any exceptions thrown - Invokes DataPage type validation and catch exceptions thrown from the setters and populate the error variable. If an error is determined to have occurred the edit page is re-rendered.

Allow Edit From Table Optional. If selected an Edit column will be added to the main collection table
Delete Options
Allow Delete Required. This checkbox determines if "delete" functionality will be generated
If Delete is generated, a Delete link/button will be placed on the view page, and optionally, a Delete column will be added to the main collection table
At runtime when that link is clicked, a user-supplied Delete method in the model will be invoked.
Delete method Required. This is the method invoked when a delete link/button is clicked.
The method is expected to accept a single object as argument, which will be the object selected for deletion. Typical user action in this delete method might be to invoke a SQL call and/or to remove the object from the collection.
Delete Error Action Optional. If an exception occurs in the Delete method this error action will be invoked.
Allow Delete From Table Optional. If selected a Delete column will be added to the main collection table.
Add Delete Confirmation Dialog Optional. If selected will generate a JavaScript popup into the Delete HTML to confirm the delete.
Create Options
Allow Create Required. This checkbox determines if "create" functionality will be generated.
The impact of selecting Create functionality will be to place a "Create" button/link on the main collection page which will invoke a user-supplied instantiate method and then invoke a save mechanism similar to that generated for Edit.
Instantiate Method Required. When the create button/link is clicked this method will be invoked.
This method is expected to take no arguments, and to return a single object of the specified Bean classname (or detail classname if different). The returned object reference will be passed through to the "<name>_doSaveForCreate" action list, which will invoke the PreApply, "<name>_createPage_saveData", and PostApply methods.
Imported page URL Optional. If the "Page in model" is not supplied this input is required.
This is the page onto which the create view of the object will be placed. The page will be added to the model as "offices_createPage" (if the BuilderName is "offices") and the view will be added at the span tag called "data". (Overrideable in the Tag location mappings section).
Example: "/factory/pages/beancurds_dataviewpage.html"
or Page in model Optional. If the "Imported Page URL" is not supplied, this input is required.
This is the page onto which the create view of the object will be placed. The view will be added at the span tag called "data". (Overrideable in the Tag location mappings section).
Example: "officepage".
PreApply Method Optional. At runtime when the page containing the edits is submitted this method (if supplied) will be invoked from the "<name>_doSaveForCreate" method.
The method supplied must take a single Object argument. When the method is called the object passed to it will be the edited object BEFORE any changes have been applied (ie, the "<name>_viewObject" as it was when it was rendered on the create page.
Calling this method provides a hook start a transaction, acquire a JDO persistence manager, or even apply validation additional to that occurring in the object setters.
PostApply Method Optional. After the PreApply Method has occurred the "_doSaveForCreate" method will invoke "<name>_createPage_saveData" which will apply the submitted values (for all of the editable attributes on the page) to the "<name>_viewObject". If no errors occurred (either detected by the DataPage validation or in the object s own setter methods by way of throwing an Exception) this PostApply Method will be invoked.
As with the PreApply Method this method is expected to take a single Object argument which will be the "<name>_viewObject" AFTER the updates have been applied to it.
Calling this method provides a hook to commit a transaction.
Save Error Action Optional. If the Validation style selected is to perform validation and/or to catch Exceptions the page specified here will be called.
Validation Optional. This determines the level of validation and error handling to be included in the Create mechanism (within the generated "<name>_createPage_saveData" method). The available options are:

Do not add validation or catch exceptions from setters - Causes eceptions thrown in the PreApply, "<name>_editPage_saveData" or PostApply methods to drive the Save Error Action. If no Save Error Action is specified the Default Error page will be rendered, or the error handler specified in the model.
Perform field type validation before applying setter - Invokes the regular DataPage validation mechanism to populate a "<name>_editPageError" Variable in the webapp with any datatype errors identified in the inputs. When an error occurs the edit page will be re-rendered and the detected errors will be displayed on the page next to the fields that caused them.
Catch exceptions thrown from the setter - Omit the initial DataPage type validation but will catch any exceptions thrown from the setters, populate the "<name>_editPageError" and re-render the edit page
Perform validation prior to setter and catch any exceptions thrown - Invokes DataPage type validation and catch exceptions thrown from the setters and populate the error variable. If an error is determined to have occurred the edit page is re-rendered.

Tag Location Mappings
Tag on page for collection display location Required. Tag on page for collection display location
Tag on page for paging buttons location Required. Tag on view page for paging buttons location
Tag on page for view display location Required. Tag on page for view display location.
back (from view) button tag Required. Tag on View page for back button/link location.
back (from view) button/link label Required. back (from view) button label.
Tag on page for edit display location Tag on page for edit display location
Tag on page for create display location Tag on page for create display location
edit (from view) button tag Required. Tag on View page for edit button location.
edit (from view) button label Required. edit button label.
delete (from view) button tag Required. Tag on View page for delete button location
delete (from view) button/link label Required. delete (from view) button/link label.
Tag on edit page for edit display location Required. Tag on page for edit display location.
save (from edit) button tag Required. Tag on Edit page for save button location.
save (from edit) button label Required. save button text.
back (from edit) tag Required. Tag on Edit page for back button location.
back (from edit) button label Required. back (from edit) button text.
cancel (from edit) tag Required. Tag on Edit page for cancel button location
cancel (from edit) button label Required. cancel (from edit) button text
create button tag Required. Tag on Main page for create button location
create button label
Required. Create button text

Tag on create page for create display location

Required. Tag on Create page for create button location
back (from create) tag Required. Tag on Create page for back button location
back (from create) button label Required. back (from create) button text
cancel (from create) tag Required. Tag on Create page for cancel button location
cancel (from create) button label Required. cancel (from create) button text
save (from create) tag Required. Tag on Create page for save button location
save (from create) button label Required. save (from create) button text

Building Views

To show an Office and its associated Departments on one page add two Bean MasterDetail builders. The first one ("offices") will reference the variable holding the Offices collection. The second ("departments") would have as its collection the value "${MethodCall/offices_viewObject.getDepartments}" where getDepartments() is the method in the Office object that returns a collection of Departments. The offices "View Detail Options" "Page in Model" and the departments "Master/Table View" "Page in Model" would specify two different tags on the same page in the model. When that page is rendered the current "offices_viewObject" will be used to populate the offices view and its getDepartments method will be invoked to get the collection of Departments to display in the departments collection view.
There are several ways to show different information in the table and the view. If "Use Detail-specific class" is NOT used we can use DataFieldModifiers to make certain columns or fields invisible. If Use Detail-specific class" IS used then we can instantiate a physically different object. A third less obvious but more efficient method is to use "Use Detail-specific class" but to have the object implement a (thin) Interface and specify the Interface name for the table view. The "Accessor class/method" would then return the same physical object, no need for instantiating a new object. The advantage with this is also that the object in the main collection is being updated automatically with values from the "detail" object.

Objects this Builder Creates

This builder creates a variety of objects within the WebApp. They include the following items

Variables

bmd_viewObject "Currently selected" object, populated automatically when a link or button is clicked. It is identified by the Bean object s Java hashCode. When a significant button or link is clicked, the hashCode is passed in and the object is fetched from the user-specified collection. A reference to the object is placed in this Variable

Methods

Methods are prefixed by the Bean Master Detail builder name. In these examples "bmd" is used.

bmd_deleteActionList Action list generated to delete an object. Calls a user-provided delete method.
bmd_doCreateFromButton Action list that invokes the user-provided instantiate method and then the create (edit) page
bmd_doEditFromButton Displays the edit page against the viewObject
bmd_doEditFromLink Populates the viewObject based on the object id passed in on the link and displays the edit page against the viewObject
bmd_doSave Save (after edit) method that invokes the user s pre-apply and post-apply methods and the generated save method that applies the updates to the bean
bmd_doSaveForCreate Save (after create) method that invokes the user s pre-apply and post-apply methods and the generated save method that applies the new values to the bean
bmd_doView Fetches the specified object (by hashCode) from the user s collection and presents it on the view page

Pages

If the imported page option is used rather than using an existing page in the model, the builder will create the following pages below. Pages are prefixed by the builder name. In these examples "bmd" is used:

bmd_createPage Edit page for an object being created, reached via a button from the main table page
bmd_editPage Edit page for an existing object, reached via the button/link on the view page or from the link on the main table view
bmd_mainPage Main table view showing the collection (with optional paging)
bmd_viewPage Read only view of a single bean, reached from a link on the main table view

Input Name	Description
Name	Required. Typically if the objects being displayed are com.acme.Offices the name supplied would be "offices" for consistency. The name provided will be used as a prefix to many of the generated model artifacts. In particular (if the name supplied is "offices") "offices_viewObject" is the "currently selected" object when rendering the view or edit pages. To place another Bean MasterDetail builder on the same page showing the associated Departments, we can do so by referencing the "offices_viewObject" in that other Builder
Master / Table View
Collection	Required. Object in the WebApp that will be the source of the data at runtime. This content is under the user s/application control and the collection is examined when the page is rendered.Changes made to the set of objects in the collection will be reflected in the rendered page. The object being returned must be an instance of java.util.Collection or java.util.Iterator. The Builder does not take a copy of the collection, it maintains a reference to it. Example: ${Variables/orgcharts}
Bean class name	Required. Class (or Interface) that is examined at regen time and from which the WebApp artifacts are generated. The class (and its superclasses) MUST be visible to the Eclipse plugin at Design time, as well as the J2EE context at runtime. To make the class visible to the Eclipse plugin you can place the class in a jar that is registered in the WebSphere Portlet Factory Designer ("com.bowstreet.designer.core_5.12.0") plugin.xml file. But, the simplest way is to place the class files in the "WEB-INF/work/classes" directory of the J2EE context that the Designer is looking at it will then be visible to both Design time and runtime regen actions. Example: "com.bowstreet.qa.beans.Office
Imported page URL	Optional. If the "Page in model" is not supplied this input is required. Page on which the table view of the collection will be placed. The page will be added to the model as "offices_mainPage" (if the BuilderName is "offices") and the table view will be added at the span tag called "data". (Overrideable in the Tag location mappings section). Example: /factory/pages/beancurds_dataviewpage.html
or Page in model	Optional . If the "Imported Page URL" is not supplied this input is required. Page on which the table view of the collection will be placed. The table view will be added at the span tag called "data". (Overrideable in the Tag location mappings section). Example: "mainpage".
Paged data display	Optional. When checked, paging buttons are added below table.
Rows per page	Optional. Number of rows per page of data.
General UI Options
Auto-generate UI	Required. This input carries interacts with an underlying Data Page builder for the View and Edit pages and specifies whether the attribute names and values are shown at specific named (matching) locations on the HTML page, or if the names and values are generated automatically into the HTML page starting at a particular tag location.
Navigation Style	Required. The navigation style between pages is selectable, as either Buttons or Links. The span tags on which these navigation buttons/links are placed (and their labels) are configurable in the Tag location mappings section.
View Detail Options
Allow View Detail	Required. This checkbox determines if a "view detail" page is generated. If it is generated, a link will be placed on a selectable column in the main collection table. At runtime when that link is clicked the page showing the detail view for that chosen object will be rendered. If the Builder is called "accounts", when the link is clicked the Linked Java Object in the WebApp called "accounts_viewObject" will be set to reference the chosen object in the main collection. Anything else on the rendered page that is sourced from "accounts_viewObject" in some way will show the correct related data.
Column for link	Required if Allow View Detail is selected. When the Bean classname is specified in the Builder UI this Builder input is automatically populated by introspecting the specified class. The only attributes shown in this selection are those that are valid for the main collection view (see list in "How Does This Builder Work").
Imported page URL	Optional. If the "Page in model" is not supplied this input is required. This is the page onto which the detail view of the object will be placed. The page will be added to the model as "offices_viewPage" (if the BuilderName is "offices") and the view will be added at the span tag called "data". (Overrideable in the Tag location mappings section). Eg, "/factory/pages/beancurds_dataviewpage.html"
or Page in model	Optional. If the "Imported Page URL" is not supplied this input is required. This is the page on which the detail view of the object will be placed. The view will be added at the span tag called "data". (Overrideable in the Tag location mappings section). Eg, "officepage".
Use Detail-specific class	Optional. This checkbox enables some advanced functionality in this builder. (See Building Views below for more detail and examples). If the object you wish to display in the detail view is a physically different object from the one in the collection, ie, a "thicker" version with much more detail (more attributes), this checkbox enables the additional inputs needed to allow that detail object to be displayed when the "thin" object in the collection view is clicked.
Detail class name	Optional. Required if Use Detail-specific class is selected. The classname or Interface of the detail object. Eg, com.bowstreet.qa.beans.OfficeDetail
Accessor class	Optional. (Required if Use Detail-specific class is selected.) When the object in the main collection table is clicked, the generated runtime logic is to invoke the static method (named below) on the classname provided here. Eg, com.bowstreet.qa.beans.Office
Accessor method	Optional. (Required if Use Detail-specific class is selected.) When the object in the main collection table is clicked, the generated runtime logic is to invoke this static method on the classname named above, passing in as arguments the values (named below) from the selected object. Eg, fetchDetailByName
Field names	Optional. (Required if Use Detail-specific class is selected.) When the object in the main collection table is clicked, the generated runtime logic is to invoke the static method named above on the classname named above, passing in as arguments these attributes from the selected object. Eg, name
Edit Options
Allow Edit	Required. This checkbox determines if an "edit" page will be generated. If edit page is generate,d an Edit link/button will be placed on the view page, and optionally an Edit column will be added to the main collection table. At runtime when that link is clicked the page showing the chosen object in edit mode will be rendered. Only the attributes for which public setters exist will be opened up for edit, the other attributes will be display-only. As with the view detail, if the Builder is called "accounts", then when the link is clicked the Linked Java Object in the WebApp called "accounts_viewObject" will be set to reference the chosen object in the main collection. When the edit page is submitted a generated action list called "offices_doSave" (if the BuilderName is "offices") will be invoked.
Imported page URL	Optional.( If the "Page in model" is not supplied this input is required.) This is the page on which the edit view of the object will be placed. The page will be added to the model as "offices_editPage" (if the BuilderName is "offices") and the view will be added at the span tag called "data". (Overrideable in the Tag location mappings section). Example: "/factory/pages/beancurds_dataviewpage.html"
or Page in model	Optional. If the "Imported Page URL" is not supplied this input is required. This is the page onto which the edit view of the object will be placed. The view will be added at the span tag called "data". (Overrideable in the Tag location mappings section). Example: "officepage".
PreApply Method	Optional. At runtime when the page containing the edits is submitted this method (if supplied) will be invoked from the "<name>_doSave" method. The method supplied must take a single Object argument. When the method is called the object passed to it will be the edited object BEFORE any changes have been applied (ie, the "<name>_viewObject" as it was when it was rendered on the edit page. Calling this method provides a hook to start a transaction,acquire a JDO persistence manager, or even apply validation additional to that occurring in the object setters.
PostApply Method	Optional. After the PreApply Method has occurred the "_doSave" method will invoke "<name>_editPage_saveData" which will apply the submitted values (for all of the editable attributes on the page) to the "<name>_viewObject". If no errors occurred (either detected by the DataPage validation or in the object s own setter methods by way of throwing an Exception) this PostApply Method will be invoked. As with the PreApply Method, this method is expected to take a single Object argument which will be the "<name>_viewObject" AFTER the updates have been applied to it. Calling this method provides a hook to commit a transaction.
Save Error Action	Optional. If Validation style selected is to perform validation and/or to catch Exceptions, the page specified here will be called.
Validation	Optional. This determines the level of validation and error handling to be included in the Edit mechanism (within the generated "<name>_editPage_saveData" method). The available options are: Do not add validation or catch exceptions from setters - Causes eceptions thrown in the PreApply, "<name>_editPage_saveData" or PostApply methods to drive the Save Error Action. If no Save Error Action is specified the Default Error page will be rendered, or the error handler specified in the model. Perform field type validation before applying setter - Invokes the regular DataPage validation mechanism to populate a "<name>_editPageError" Variable in the webapp with any datatype errors identified in the inputs. When an error occurs the edit page will be re-rendered and the detected errors will be displayed on the page next to the fields that caused them. Catch exceptions thrown from the setter - Omit the initial DataPage type validation but will catch any exceptions thrown from the setters, populate the "<name>_editPageError" and re-render the edit page Perform validation prior to setter and catch any exceptions thrown - Invokes DataPage type validation and catch exceptions thrown from the setters and populate the error variable. If an error is determined to have occurred the edit page is re-rendered.
Allow Edit From Table	Optional. If selected an Edit column will be added to the main collection table
Delete Options
Allow Delete	Required. This checkbox determines if "delete" functionality will be generated If Delete is generated, a Delete link/button will be placed on the view page, and optionally, a Delete column will be added to the main collection table At runtime when that link is clicked, a user-supplied Delete method in the model will be invoked.
Delete method	Required. This is the method invoked when a delete link/button is clicked. The method is expected to accept a single object as argument, which will be the object selected for deletion. Typical user action in this delete method might be to invoke a SQL call and/or to remove the object from the collection.
Delete Error Action	Optional. If an exception occurs in the Delete method this error action will be invoked.
Allow Delete From Table	Optional. If selected a Delete column will be added to the main collection table.
Add Delete Confirmation Dialog	Optional. If selected will generate a JavaScript popup into the Delete HTML to confirm the delete.
Create Options
Allow Create	Required. This checkbox determines if "create" functionality will be generated. The impact of selecting Create functionality will be to place a "Create" button/link on the main collection page which will invoke a user-supplied instantiate method and then invoke a save mechanism similar to that generated for Edit.
Instantiate Method	Required. When the create button/link is clicked this method will be invoked. This method is expected to take no arguments, and to return a single object of the specified Bean classname (or detail classname if different). The returned object reference will be passed through to the "<name>_doSaveForCreate" action list, which will invoke the PreApply, "<name>_createPage_saveData", and PostApply methods.
Imported page URL	Optional. If the "Page in model" is not supplied this input is required. This is the page onto which the create view of the object will be placed. The page will be added to the model as "offices_createPage" (if the BuilderName is "offices") and the view will be added at the span tag called "data". (Overrideable in the Tag location mappings section). Example: "/factory/pages/beancurds_dataviewpage.html"
or Page in model	Optional. If the "Imported Page URL" is not supplied, this input is required. This is the page onto which the create view of the object will be placed. The view will be added at the span tag called "data". (Overrideable in the Tag location mappings section). Example: "officepage".
PreApply Method	Optional. At runtime when the page containing the edits is submitted this method (if supplied) will be invoked from the "<name>_doSaveForCreate" method. The method supplied must take a single Object argument. When the method is called the object passed to it will be the edited object BEFORE any changes have been applied (ie, the "<name>_viewObject" as it was when it was rendered on the create page. Calling this method provides a hook start a transaction, acquire a JDO persistence manager, or even apply validation additional to that occurring in the object setters.
PostApply Method	Optional. After the PreApply Method has occurred the "_doSaveForCreate" method will invoke "<name>_createPage_saveData" which will apply the submitted values (for all of the editable attributes on the page) to the "<name>_viewObject". If no errors occurred (either detected by the DataPage validation or in the object s own setter methods by way of throwing an Exception) this PostApply Method will be invoked. As with the PreApply Method this method is expected to take a single Object argument which will be the "<name>_viewObject" AFTER the updates have been applied to it. Calling this method provides a hook to commit a transaction.
Save Error Action	Optional. If the Validation style selected is to perform validation and/or to catch Exceptions the page specified here will be called.
Validation	Optional. This determines the level of validation and error handling to be included in the Create mechanism (within the generated "<name>_createPage_saveData" method). The available options are: Do not add validation or catch exceptions from setters - Causes eceptions thrown in the PreApply, "<name>_editPage_saveData" or PostApply methods to drive the Save Error Action. If no Save Error Action is specified the Default Error page will be rendered, or the error handler specified in the model. Perform field type validation before applying setter - Invokes the regular DataPage validation mechanism to populate a "<name>_editPageError" Variable in the webapp with any datatype errors identified in the inputs. When an error occurs the edit page will be re-rendered and the detected errors will be displayed on the page next to the fields that caused them. Catch exceptions thrown from the setter - Omit the initial DataPage type validation but will catch any exceptions thrown from the setters, populate the "<name>_editPageError" and re-render the edit page Perform validation prior to setter and catch any exceptions thrown - Invokes DataPage type validation and catch exceptions thrown from the setters and populate the error variable. If an error is determined to have occurred the edit page is re-rendered.
Tag Location Mappings
Tag on page for collection display location	Required. Tag on page for collection display location
Tag on page for paging buttons location	Required. Tag on view page for paging buttons location
Tag on page for view display location	Required. Tag on page for view display location.
back (from view) button tag	Required. Tag on View page for back button/link location.
back (from view) button/link label	Required. back (from view) button label.
Tag on page for edit display location	Tag on page for edit display location
Tag on page for create display location	Tag on page for create display location
edit (from view) button tag	Required. Tag on View page for edit button location.
edit (from view) button label	Required. edit button label.
delete (from view) button tag	Required. Tag on View page for delete button location
delete (from view) button/link label	Required. delete (from view) button/link label.
Tag on edit page for edit display location	Required. Tag on page for edit display location.
save (from edit) button tag	Required. Tag on Edit page for save button location.
save (from edit) button label	Required. save button text.
back (from edit) tag	Required. Tag on Edit page for back button location.
back (from edit) button label	Required. back (from edit) button text.
cancel (from edit) tag	Required. Tag on Edit page for cancel button location
cancel (from edit) button label	Required. cancel (from edit) button text
create button tag	Required. Tag on Main page for create button location
create button label	Required. Create button text
Tag on create page for create display location	Required. Tag on Create page for create button location
back (from create) tag	Required. Tag on Create page for back button location
back (from create) button label	Required. back (from create) button text
cancel (from create) tag	Required. Tag on Create page for cancel button location
cancel (from create) button label	Required. cancel (from create) button text
save (from create) tag	Required. Tag on Create page for save button location
save (from create) button label	Required. save (from create) button text