Version 4 Changes
Dockable
Designer Tree and References Panels
FPL
Access to Control Properties
Programming
With Table Row Numbers
Browser
Selection When Running Forms
Single
Namespace per Component
Styling
Individual Table Columns
Default
Template and Style Sheet
Changed
Or Removed Functionality
Row
Striping Of Non-Tabular Fields
Designer
Copy For Table Feature
UFSFormInterface
deprecated methods
Validation
Events On Label Fields
Vertically
aligned lists in table columns
Messages
for hidden fields or buttons
Version
3 Features: How They Work In Version 4
Page
Header, Page Info, Page Trailer Texts
This document is intended to be read by developers who have a good understanding of Ebase Version 3. It describes new and changed functionality in Version 4, and discusses how features of Version 3 are implemented in this new version. The document is arranged in the following sections
|
describes major architectural or conceptual changes |
|
|
describes major changes in the designer |
|
|
describes other changes in both designer and runtime |
|
|
describes Version 3 functionality that has been changed or removed. READ THIS SECTION
WHEN UPGRADING FROM VERSION 3. |
|
|
discusses various features in Version 3 and explains how these work in Version 4 |
Note that the upgrade process automatically converts a Version 3 system to Version 4. All upgraded forms should continue to operate without the need for modification except where they rely on functionality that has been changed or removed. There may also be small changes in the display of some form pages.
This section describes major architectural or conceptual changes in Ebase Version 4.
In Version 3, a page consisted of a number of displayed fields and tables. These fields and tables could be arranged into groups or into a two column display, and a number of options were provided to configure presentation, but the basic building blocks were limited to just fields and tables; buttons were treated as a special kind of field.
In Version 4, a page consists of a number of controls a control can be anything that can appear on a page. Version 4.0 introduces lots of new controls (click here for details), and more controls will be introduced in later releases. For example, the fields and tables of Version 3 become Field Controls and Table Controls respectively; some new controls added are: Text Control, Button Control, Image Control, Tab Set Control, Menu Controls, Grid Control and many more. In a future release, the ability for customers to write their own controls will also be introduced.
Some of these controls are containers meaning that they can contain other controls as children; this results in each page consisting of a tree structure of controls. Each container control has a layout which determines how the child controls are laid out; five layouts are supplied with Version 4.0 (click here for details). For example, a Field Grid Layout provides the tabular layout of fields used in Version 3.
For more information, follow these links:
In Version 3, styling was implemented using Presentation Templates where a limited number of options were available.
In Version 4, the full power of CSS is available to form designers. Style sheets can be created using a new Style Sheet Editor or links can be created to external style sheets, and these are then linked to forms. Presentation Templates still exist, but now provide new functions:
While style sheets can be used in any manner, it is anticipated that for the most part, styling will be achieved using CSS classes, and that these classes will then be associated with individual controls. Nearly all controls have styling properties, with some controls supporting many of these. With a few exceptions, these properties allow style to be applied in two ways: using CSS classes as just described, or as inline style.
For more information, follow these links:
In Version 3, a table could only be defined by adding it to a page.
In Version 4, a clear distinction is made between:
It is no longer necessary to place tables on a page, except when they are to be displayed to the user. A new Tables View panel provides the ability to create and maintain tables.
For more information, click here.
In Version 3, texts could only exist as part of another object e.g. a field had a label text and a help text, a group had a header text, info text and trailer text. These texts could not be used outside of the context of the object that owned them.
In Version 4, texts exist in their own right; new texts can be created and can then be used anywhere throughout a form or component. Many controls make use of these texts e.g. header texts, help texts, button texts, alternate texts etc the simplest of these is a Text Control which allows a text to be placed anywhere on a page. All these texts, together with all the Version 3 texts field texts, group texts, page texts etc form a single texts pool within each form/component. Any text from the pool can be used anywhere within the form/component.
In addition, shared texts have also been introduced. These form a central pool of shared texts that are available to all forms/components. This can be used interchangeably with the form/component texts described in the previous paragraph.
For more information, follow these links:
New support for tables within a workflow process has been added.
This section describes major changes in the Ebase Designer.
A new Form/Component Editor has been introduced that completely replaces the corresponding Version 3 editor. This has the following major features:
The new editor has the following dockable panels:
For more information, click here.
A new Style Sheet Editor has been introduced that supports the creation of new style sheets plus linking to external style sheets.
See also How Style Is Applied.
A new Presentation Template Editor has been introduced. This supports the creation of default style sheets and default properties for all controls, layouts and some form properties.
See also How Style Is Applied.
This has been re-designed to provide support for tables. The editor has the following new panels:
The above panels are all dockable.
The Designer Tree Panel and Reference Panel on the left of the initial designer display - are both dockable. These panels can be hidden or relocated. Hiding these panels temporarily increases the effective space available for the form designer.
The Integration Service Editor and System Service Editor have been changed. These are effectively the same as the Form Editor except that only the Fields View, Tables View and Properties View are shown.
Almost all control properties can be read or set from an FPL script; this greatly increases the amount of dynamic behaviour available to the designer. See Accessing Control Properties from FPL.
Many new controls have been added that provide new functionality. Follow the links below for details of each control.
|
Add an image (can optionally be clickable) |
|
|
Includes an external HTML or JSP file |
|
|
Acts as a location for error and warning messages |
|
|
Horizontal line |
|
|
Allows HTML to be added |
|
|
Hyperlink, either internal (runs FPL script) or external |
|
|
Text |
|
|
Clickable button |
|
|
Tab Set |
|
|
Horizontal dropdown menu |
|
|
Vertical menu |
|
|
A grid layout control |
A new feature has been introduced to stop the screen from jumping when a browser page is refreshed. In particular, if the user has scrolled the browser display (either vertically or horizontally), the system will attempt to maintain the same position so the screen does not appear to jump. Note that there are some circumstances that can still cause the screen to jump: if the system needs to scroll to make error and warning messages visible, or to honour an FPL set focus command. See scrolling.
The internal row numbers of a table are now available to application programmers and can be used by an application to perform specific operations on a row e.g. make it visible, delete, highlight etc. Click here for further details.
New options for date and time fields and table columns have been introduced. These are configured in the Field Properties dialog and include the ability to specify the degree of accuracy used when displaying time values, and the ability to configure the value pattern text e.g. hh:mm:ss, dd/mm/yyyy.
A tool to compile the FPL.jj syntax file to create the UfsLanguage.jar has been introduced. This is of interest to customers who have added their own functions or commands to the FPL language. The new tool is distributed in the LanguageBuilder directory of the product installation. Refer to the readme file in this directory for instructions.
A form can be rendered to a browser using either HTML or XHTML. This option can be set globally for all forms using parameter Ufs.outputDocumentType in UFSSetup.properties or can be set for each individual form on the Presentation tab of Form Properties. These properties also support setting the transitional or strict standard within each protocol.
It is now possible to choose where error and warning messages are displayed. A new Message Control has been introduced that represents a location on a page where messages are to be displayed. Each control has message option properties that specify that messages should be shown either locally meaning local to the control they are linked to - or by a Message Control. The local option is equivalent to the Version 3 functionality where messages are shown above the field or table column that they relate to. See Control Message Options.
The following changes have been made to the display of error and warning messages:
When running a form from the designer, it is now possible to select which browser to open. Browsers are added using the Form Options tab of Designer Preferences Dialog. Option Display options panel when launching forms in the same tab also needs to be checked.
All container controls have a Display only property. Setting this option on a container control sets all of its children as display only. This option can be used to make sections of a page, or even an entire page, display only, in a single command.
In Version 3, there were limitations associated with these commands: they could not be used in all events, resuming execution when returning to the calling form did not always work correctly. These problems have been resolved in Version 4.
All names within each component or form must now be unique. This includes all fields, tables, pages, texts, controls.
The Print Form Designer within the Form Editor has been changed so that it shares many view panels with the Form Editor. The central editor is largely unchanged, except that it is no longer possible to include a text from a table or group.
When a form is run from the designer, it will only be saved if there are unsaved changes. In Version 3, the form was always saved.
In Version 3, there were a number of FPL commands that manipulated a field as displayed on a page. This included:
In Version 4, these commands will continue to operate without problem. However the syntax has changed slightly in that <fieldname> has now become <controlname> and the commands are applied to a control. To ensure compatibility with version 3, the system checks first whether a field exists named <controlname> and only checks for a control with this name if a field is not found.
In Version 3, many of these commands accept an optional field on page id parameter to distinguish between multiple occurrences of a field on a page. These commands will continue to operate correctly on Version 4 but only for legacy (upgraded) forms; in Version 4, these ids no longer exist: FPL commands that target a specific control should use the control name instead.
In Version 4, a certain result can sometimes be achieved in more than one way e.g. the following commands all hide a field (where the field name is F1 and the field control name is FIELDCONTROL1):
The following new options can be configured for the display of a field using a Field Control:
The hide group and show group commands are supported only for legacy (upgraded) forms and should not be used for new forms as groups no longer exist with Version 4. Instead the new hide/show <controlname> commands should be used or alternatively set the controls hidden property directly e.g.
set GROUPCONTROL1.hidden = true;
The loop at table FPL command now ignores the maximum loop counter set in parameter maxLoopCount of UFSSetup.properties. A loop at table will always loop through all rows in a table unless terminated by a break.
When JavaScript is enabled, the check for mandatory fields is performed on both the client and server; in Version 3, this check was only performed on the client. This change should not affect existing applications.
Style can now be applied to individual table columns. This makes it possible for columns to have different alignments. Width and style can also be set for the special Select and Delete table columns.
A Version 3 Control Field has been renamed as an Event Field in Version 4. The functionality provided is unchanged.
New system variable $BROWSER_IP_ADDRESS has been added. This contains the browser IP address.
In Version 3, the display of a page was skipped if it contained no visible fields, buttons or tables. In Version 4, a page can contain many other elements e.g. texts, images, menus etc and skipping pages in this way no longer makes sense. To provide compatibility with Version 3, option Skip display of pages with no visible fields or tables is provided on the General Tab of Form Properties; this option is set by the upgrade process for all upgraded forms. When this option is not selected, a page is always displayed, even when it is empty.
Function gettext() function can be used to read a text.
Function settablerowvisible() can be used to scroll a table to make a certain row visible.
An application is supplied to compile the UFSLanguage.jar file when additions have been made to the FPL language e.g. new functions. Click here for details.
The system is supplied with a built-in template and style sheet both named EBASE_DEFAULT, and these two are linked together. The EBASE_DEFAULT template is the default template associated with new forms and all components. This default setting can be overridden with the following properties in UFSSetup.properties:
Ufs.defaultFormPresentationTemplate default template for new forms
Ufs.defaultComponentPresentationTemplate default template for all components
This section describes Version 3 functionality that has been changed or removed. Upgraded forms may need to be modified if they depend on functionality listed here.
The Zoom and Black and White accessibility buttons are no longer available. Corresponding methods in UFSFormInterface have been deprecated.
This has been removed with no replacement.
The option to stripe the display of fields has been removed with no replacement. Note that the option to stripe the display of table rows is unaffected.
This Version 3 feature allowed fields from a deployed component to be copied and included as table columns; when changes to the source component were subsequently deployed, these changes were propagated to the copied table columns. This feature is no longer supported with Version 4.
In Version 3, print buttons provided a quick way to add a button to a form that invoked the PDFPrint FPL command. This option has been removed. In Version 4, The PDFPrint command must be added to script and the script linked with the button.
In Version 3, this field property designated a field as being a workflow priority list and automatically associated the field with the static list configured in workflow preferences. This feature is no longer supported with Version 4. Any fields required to display workflow priority lists must be manually associated with an appropriate list.
The use if id to qualify a table with the set table command is no longer supported.
The following methods in UFSFormInterface have been deprecated: isDisplayInColour(), getZoomAmount(), isUseStylesheets().
A change has been made to the break command when issued inside a loop at table construct:
This is a change of behaviour that can affect forms that display table columns as individual fields on a page and also use loop at table/break constructs. In this circumstance, table column values from a different table row may be displayed.
In Version 3, validation events are executed for label fields; in Version 4, these events are not executed.
In Version 3, it was possible to specify standard and error focus styles for each individual page by using template sheets. In Version 4, these can only be specified at form level, with a default in the presentation template.
In Version 3, a list displayed as radio buttons or checkboxes in a table column was displayed so that it filled the available width of the table column; this often resulted in a significant gap between the button/checkbox and the associated text for each item. In Version 4, the button/checkbox for each item is always displayed immediately next to the associated text with no intervening gap. This change means that vertically aligned lists appear the same when displayed as a single field or in a table column.
In Version 3, it was possible to hide a field or button and issue a message attached to the field/control, and the message was displayed. In Version 4, the message will not be displayed. Forms that depend on this behaviour should be changed to use a Message Control. Click here for further details of message options.
This section discusses various features in Version 3 and explains how these work in Version 4.
In Version 3, all fields were displayed in a tabular format with labels on the left, the editor portion in the middle and help on the right (with an additional option to display help underneath the editor). There was also an option to display a field on the same line as its predecessor. In Version 4, the same functionality is provided by a Field Grid Layout, which is one of the possible layouts that can be applied to a container control. The upgrade process creates Field Controls and places these in either a Panel Control or a Group Panel Control and applies a Field Grid Layout to these. The same line functionality is provided by the New line property which is available for many controls, but only has meaning when the control is placed inside a container with a Field Grid Layout.
In Version 3, a two column layout was provided which allowed groups and fields to be placed in either the left or right column of a table. In Version 4, this functionality is provided by a Grid Control which is much more flexible. The upgrade process will automatically create a Grid Control when appropriate.
In Version 3, fields could be grouped together and each group had three texts that could be configured: header, info and trailer. In Version 4, groups no longer exist and have been replaced by a Group Panel_Control which supports the same three texts and options to configure styling of these texts. The group and ungroup functions in the designer no longer exist; instead the same result is achieved by moving controls into or out of a Group Panel Control.
In Version 3, a form header text, if configured, was displayed at the top of each page. Small navigation images could also be configured in the presentation template and these were displayed to the right of the form header text. In Version 4, this functionality is unchanged, but is configured in the Presentation tab of Form Properties and more options are provided: the form header can be disabled for all pages in a form, the navigation images can be disabled, the image locations can be configured. In addition, default values for all these properties can be configured in the new Presentation Template Editor.
In Version 3, these page level texts provided an opportunity to insert texts at the top or bottom of the page. In Version 4, this same functionality is provided by a Page Panel Control which also provides the ability to style these texts. However, this control is now entirely optional: it could be deleted and any required texts could be added by using a Text Control. A Page Panel Control can be automatically added to all new pages created in the designer to provide equivalent functionality to Version 3 this option is specified in Designer Preferences Page Editor tab.
In Version 3, forwards and backwards paging buttons and a finish button are displayed at the bottom of pages automatically unless the display of these buttons has been suppressed. In Version 4, this same functionality is provided by a Legacy Button Panel Control and one of these controls is added to each page by the upgrade process. If these page navigation buttons are not required, this control can simply be deleted. Note that this control can also appear any number of times on each page and can be located anywhere. Individual paging buttons can also be added. See Page Sequencing for more information. A Legacy Button Panel Control can be automatically added to all new pages created in the designer to provide equivalent functionality to Version 3 this option is specified in Designer Preferences Page Editor tab.
The option to position four JSP or HTML pages top, left, right, bottom around a form, is provided unchanged in Version 4. These JSPs can be configured on each page, on each form, or in the presentation template see JSPs for more details. In addition, JSP or HTML pages can be placed anywhere on a page using the new Include Control. Please note that the WYSIWYG View in the designer does not attempt to display JSP or HTML pages.
In Version 3, error and warning messages are shown above the field that the message relates to. In Version 4, more flexible layouts are supported, and it is not possible to always place a message above the control to which it relates. Therefore a new capability has been introduced that allows the designer to set up message areas and direct messages to these areas; this is implemented using a Message Control. Version 3 messaging is implemented in Version 4 as local messaging and this option is set for upgraded forms by the upgrade process. See also Control Message Options.
In Version 3, template sheets were used to invoke different styling parameters within a presentation template for a page, group or table. In Version 4, styling is done differently as described above. Template sheets no longer exist; the upgrade process converts the styling parameters in template sheets into Version 4 Style Sheets.
In Version 3, a button was implemented as a special type of field. In Version 4, these button fields are supported only for upgraded forms and cannot be created. Instead, buttons are inserted by adding a Button Control or a Button Column Control (when the button is a table column). Version 3 buttons had an option of being displayed as an image; this is achieved in Version 4 by using an Image Control or an Image Column Control (when the image is a table column).
In Version 3, a table could only be created by placing it on a page; in Version 4, this functionality is split into two parts: create the table, and then add it to a page (using a Table Control). See Tables above for more details.
Horizontal pages are handled in Version 4 by using Table Page Controls, fixed columns are handled by placing columns as direct children of a Table Control, instead of children of a Table Page Control. See Table Display Features for more details.
In Version 3, a black inset border was applied to the page content of each page beneath the form header text, but including the rest of the page. This was implemented using a CSS class rule named mainblock which was generated automatically. Parameter Ufs.presentationBorderSurround in UFSSetup.properties could be used to suppress this border; in some cases this border was suppressed by overriding the mainblock rule in the HTML++ tab of Form Properties for each form.
In Version 4, the style applied to the page content is configured using the Page content style property of Page Control and can be changed as required. The upgrade process sets the default class for this property to be mainblock and this rule can also be configured as required. Use of parameter Ufs.presentationBorderSurround in UFSSetup.properties is deprecated. Upgraded forms should be unaffected by this change and any overriding CSS specified in HTML++ should continue to work.