Version 5.0 Changes

 

Documentation home

 

Introduction. 2

Major Changes 2

Workspace, projects and entity files 2

Team Working. 2

Web Resources 3

Form Names and URLs, workflow process names 4

Separation of Designer and Server Components 4

Integrated Test Server 4

Server Administration Application. 4

Deployment 5

Improved Referencing in the designer 5

Changes by functional area. 6

Case sensitive names 6

Forms 6

Scripts 7

Business Views 9

Messages/Texts 9

Translation. 9

Components 9

Static Lists 10

Dynamic Lists 10

Email 10

Other Resources 10

Database Connections 11

Web Services and Integration Services 11

System Services 11

Presentation Templates 11

Client Javascript and Style Sheets 11

Print Master Pages 12

Workflow. 12

FPL Functions 12

Global Metadata. 12

System Texts 12

Languages 13

Security. 13

Scheduled Tasks 13

Batch. 14

Sequences 14

Calendar 14

Snapshots and Save/Restore. 14

Designer Changes 15

Miscellaneous 15

References, Uses, Deletion and Refactoring. 16

Import/Export 17

Upgrade. 17

 

Introduction

This document is intended to be read by developers who have a good understanding of Ebase Xi Version 4. It describes new and changed functionality in Version 5.

Major Changes

Workspace, projects and entity files

In V5.0, all objects created in the designer are saved to a folder within the local file system called a workspace instead of to the Repository Database as was the case with V4.0.

 

The workspace can contain both entities and web resource files. The term entity means anything that can appear in the designer tree and is saved in XML format as a .eb file e.g. a form, script, list, resource, template etc. A web resource file can be an image, style sheet, HTML file etc., and these files differ from entities in that their full name including the file type is shown in the designer tree, and that they exist as simple files with no additional attributes. Entity and web resource files can be saved anywhere in the workspace with the only restriction being that everything must exist within a project.

 

A workspace is just a folder. The user specifies the workspace to use when the designer is started. Similarly the workspace is specified to a server system via a property at server start up. In a development environment, both designer and server must point to the same workspace; if the integrated test server option is used, this is enforced.

 

At the root level of the workspace, it is only possible to create projects. Within a project you can create folders, entities and web resource files and organise these in any way. Projects can be linked together: this makes the contents of the linked project available to the linking project. Any number of projects can be linked to a single project and nested linkages are also supported.

Team Working

In V4.0, all developers within a team signed on to a single server and all work was saved in the repository database attached to the server. This has completely changed in V5.0: each developer works on their own personal system consisting of a designer and a local test server; it is recommended that synchronization with other team members is done using a version control system e.g. SVN or CVS. All aspects of designer security have been removed including the ability to specify which entities are visible and editable to each designer; designers now have full access to all the files in their workspace. If necessary a development team test server can be set up to act as a single consolidation point.

 

Web Resources

Web resource files (images, style sheets, html files etc) can be added, created and edited in the workspace. The system recognises all common web resource file types but additional types and their corresponding editors can also be added via the Web Content tab of Designer Preferences.

 

There are 4 categories of web resource file that can be referred to at some point within the designer:

 

·         Image files e.g. for the URL of an Image Control

·         HTML or JSP files: from form properties/JSPs or for an Include Control

·         Style sheet files: from a template, form or page

·         Client javascript files:  from a template, form or page

 

When configuring a URL reference to a web resource, the designer user can choose to configure this:

 

·         From the workspace: the designer can browse the workspace looking for files of the appropriate type. When a link to workspace web resource has been configured, the URL path begins with $ws.

·         By browsing on the server: this is the same functionality as in V4.0.

·         By typing in the URL e.g. to an external system, this is also the same functionality as in V4.0.

 

V4.0 style sheet and client script entities are converted as part of the upgrade process to web resource files and saved in the workspace.

 

Click here for further details.

Form Names and URLs, workflow process names

In V5.0 forms and workflow processes can be created anywhere in the workspace, but both form names and workflow process names must be unique within a workspace i.e. it is not possible to have two forms with the same name at different locations within the workspace; ditto workflow processes.

 

In V5.0, two URL formats are supported to request a form:

 

  • New V5.0 format: hostname:port/webapp/formname.eb

e.g. www.mysite.com/ufs/PortalApp.eb

 

  • Old V4.0 format: hostname:port/webapp/ufsmain?formid=formname

e.g. www.mysite.com/ufs/ufsmain?formid=PortalApp

 

Click here for further details.

Separation of Designer and Server Components

In V4.0 the designer and server components were closely linked and the designer could not operate without the server. In V5.0, these two components are designed to operate independently. The designer can be started without a server and uses the server only where necessary. All server configuration has been moved to the server, mostly using the Server Administration Application.

 

When the designer is connected to a server, both systems must be configured to use the same workspace.

Integrated Test Server

This is a cut-down Tomcat server that is distributed as part of the designer. It runs an embedded Tomcat instance and is largely invisible to the developer. The server uses an embedded Derby instance as its runtime database (though it is possible to change this). This server can be configured in the same way as a standalone Tomcat server e.g. to configure database resources, add JDBC drivers, change memory allocation etc.

 

The server is started automatically when the designer is started and shut down when the designer is shut down. The developer has the ability to:

 

  • Start, stop or restart the server
  • Display the server log
  • Start the server admin application

 

Use of the Integrated Test Server is optional and each developer can also choose to operate with an external server in the same way as with V4.0. This choice is configured using the Test Server tab of Designer Preferences.

 

Click here for further details.

Server Administration Application

This consists of a number of Ebase Xi forms that act as portal for all configuration and administration tasks on the server. The application has its own security properties file which controls access to the application and supports any combination of userids and/or roles.

 

It provides the following functionality:

 

·         Scheduled Tasks: all tasks and task logs can be displayed. Failed tasks are highlighted. Tasks can be executed on demand.

·         Security: ability to edit users, roles, groups within the provided Ebase security system. This is the same functionality as provided in V4.0 in the designer Tools > Security.

·         Deployment Center: ability to view all inbound deployments into a server, ability to roll back or re-install deployments.

·         Sequences: ability to create, edit and delete sequences. This replaces the V4.0 Sequences entity.

·         Batch: this replaces the V4.0 designer functionality available via Tools > Batch. It is no longer possible to edit batch documents.

·         License:  replaces the V4.0 designer functionality available via Help > License. Shows licensing information and helps with the application for a new license.

·         Locks: provides ability to remove server locks, replacing the V4.0 designer functionality available via Tools > Maintain Locks. Note that designer locks no longer exist in V5.0.

·         Languages: provides ability to configure server languages. See also languages.

·         Server Properties: almost all of the properties from UFSSetup.properties and other property files used by the Ebase Xi server can be edited here. For most properties, the change takes effect immediately; an icon is shown against a property that requires a server restart.

·         Database Connections: ability to create, edit and delete database connections. This replaces the V4.0 Database Connection entities.

·         Web Services: ability to enable and redeploy a Web Service (really an Integration Service) and to display the WSDL.

·         Calendar: ability to configure holidays within the calendar. This replaces the V4.0 Tools > Calendar functionality.

·         System Texts: ability to edit System Texts in any language. This replaces the V4.0 Tools > System Texts functionality.

·         FPL Functions: ability to create, edit and delete FPL functions. This replaces V4.0 Tools > Maintain Functions.

·         Monitor: not yet implemented.

 

Click here for further details.

Deployment

A new deployment capability has been introduced that allows a developer to deploy directly to any target server; this includes the ability to deploy an application, a single entity file or an entire workspace. Click here for further details.

 

Improved Referencing in the designer

Version 5.0 includes a new Data Dictionary within the designer and this makes it possible to improve the display of information about the relationships of designer entities e.g. a form refers to a script. This includes improved cross referencing, automatic refactoring, better handling of deletions etc. Click here for more details.

 

Changes by functional area

Case sensitive names

Names of all elements throughout the system can now be entered in mixed case. This has implications for FPL scripts and other elements that may refer to an element using a name in a different case e.g. a script can refer to a field with a true name of FIRST_NAME as first_name or a text contains a substitutable variable &&first_name. Javascript scripts are unaffected by this change.

 

The FPL language remains case insensitive even though the names of the fields, pages, controls etc are now case sensitive e.g. if a field is named FirstName or firstname or FIRSTNAME or any other combination of case, it can be referred to as any of the following:

 

set firstname = 'xyz ';

set FirstName = 'xyz ';

set FIRSTNAME = 'xyz ';

 

Field names used as substitutable variables are also treated as case insensitive i.e. &&field_name used in texts, resources etc.

Forms

Library Forms

The ability to declare that a form is a library form is dropped with no replacement.

 

Text associations

Form Properties > Texts provides the ability to specify any number of Texts entity files to be associated with this form. This makes the texts within these files available to the form for use as texts and/or messages. Upgraded forms will show three files here:

·         Local project messages file (upgraded from the V4.0 Messages entity for the project)

·         Global messages file (upgraded from the V4.0 Messages entity in the GLOBAL project)

·         Shared texts file (upgraded from the V4.0 Shared texts – Tools > Shared Texts)

 

Texts editor

The texts editor has been changed to make it easier to use. It supports the keyboard up and down keys plus has an improved process for translating texts into additional languages. This same editor is also used to edit Texts and Static List entities.

 

Designer Preferences

A number of form-related designer preferences have been added to the Form Options tab in V5.0. These replace options specified in UFSSetup.properties on the server in V4.0.

 

·         HTML document type: replaces server property Ufs.outputDocumentType. The default for this has changed from HTML4 Transitional to HTML5.

·         HTML form tag position: replaces server property Ufs.globalHtmlForm

·         Browser back button support: replaces server property Ufs.browserBackButtonSupport

·         Legacy print form page orientation: replaces server property Ufs.defaultPrintPageOrientation

·         Legacy print form page size: replaces server property Ufs.defaultPrintPageSizeName

 

Server and Client event view panels, References and Uses panels

In V4.0, these panels are displayed as tabs within a single containing panel in the bottom left of the designer. In V5.0, these are all independent dockable panels and can be moved to any desired location.

 

New fields/columns/texts dialogs

These dialogs have been changed to be easier to use: they support the keyboard up and down keys and show new name validation errors immediately.

 

Validation of list input fields removed

The feature to validate an input text field against a list has been removed with no replacement.

 

Security when submitting a form from the designer

In V4.0, when a form was submitted from the designer, the userid from the designer was transferred to the server. This is no longer the case in V5.0. If server property Enable Authentication of New Users is configured, the authentication mechanism will be used for all new sessions including test forms submitted from the designer.

Scripts

A new Outline View panel has been added to the Javascript editor, with icons to show/hide the display of variables, functions and classes.

 

The dialog to configure a Javascript script’s owner using the change hyperlink at the top of the script editor has changed. In V5.0 this allows the selection of any form, component, integration service or workflow process which can “see” this script i.e. which exists in a project which is linked to this script’s project.

 

There are a few places where a script can make a reference to another entity by name. These are implemented in V5.0 as follows:

 

callscript

An FPL callscript statement treats the script name as a path relative to the current script’s folder e.g. callscript S2 will search for that script in the same folder as the current script. An absolute path (from the root of the project) can also be specified: e.g.

callscript /Scripts/script3;

set template

In V5.0 this works by first searching for the template name as a path relative to the folder containing the owning form; then searching all directories within linked projects for a template with the specified name (this is to support upgraded forms). The first template found is used. Commands can also use an absolute path e.g.:

FPL: set template /housing/template/TEMPLATE1;

Javascript: form.setPresentationTemplateName("/housing/template/TEMPLATE1");

 

 

 

Script wizard

The script builder wizard can now build scripts in either FPL or Javascript (previously this was only available for FPL). Scripts generated using the wizard are now saved immediately. In V4.0 these generated scripts were saved when the form was next saved.

 

FPL changes

  • The message command now takes a string as the message id (though integers can also be specified). In V4.0 the message id was an integer.
  • The set template command can accept a path as well as a template name.
  • The callscript command can accept a full path as well as a relative path.

 

Javascript API changes

  • The addxxxMessage() methods in MessageContainer now take a string instead of an integer. The corresponding int methods have all been deprecated (but still work).

 

  • New invalidate() methods have been added to FormSession and can be used to release memory for a form session. This is particularly useful when you know that a form session cannot be used by the end user any more e.g. when closing a popup dialog containing a new form.

 

client.getFormSession().invalidate();

 

  • A new texts variable has been added to the API and shows all texts available to a form, both the form’s internal texts and any Texts entities added via form properties. This works the same as the fields, controls etc variables, and the texts can be used for either messages or texts:

 

event.owner.addErrorMessage(texts.Message10);

 

  • System texts are now accessible via the system object. The getText() method returns a Text object, as for all other text accesses in the API.

 

system.texts.getText(21);

 

  • The working day calendar (in V4.0 referred to as the Workflow Calendar) can now be used by all applications and is accessed by new methods in DateServices:

 

DateServices.getWorkingDay(date, numDaysAhead);

DateServices.isWorkingDay(date);

 

          Non-working days are configured using the Server Administration Application.

 

  • Access to the context of a nested component has changed. If component C1 is nested within component C2 and then C2 is inserted into FORM1, a field within C1 can be accessed from the form as:

 

components.C2.C1.fieldxxx...

 

In V4.0, this nesting of components was not possible.

 

  • New SchedulerServices class has been added containing the runBackgroundForm() method which provides the ability to execute a form - the before and after form events – in a background thread and pass in parameters. This can be useful to execute long-running tasks which the user does not need to wait for.

 

Business Views

Business Views have been removed. They are replaced with a Resources View panel which exists for all entities that used to support Business Views – forms, components, workflow processes, integration services.

 

Business View input/output checkboxes have been removed with no replacement.

 

The Create Resource dialog – available from Fields View and Tables View – now always adds the resource to the resources panel and creates mappings. In V4.0, this only happened when the add to Business View option was checked.

 

It is only possible to create a resource via the Create Resource dialog in a path which is accessible to the owning entity i.e. in the entity’s project or one of its dependent projects.

Messages/Texts

Messages and Shared Texts from V4.0 have been merged together to create a single new V5.0 Texts entity. It is possible to create one of these entities anywhere in the workspace. Each form/component can be explicitly linked with any number of Texts entities via form properties which specify a path location to a Texts file and an order. These entities are searched in order any time there is a reference to a message or a text – the first one found will be used. These external Texts entities are in addition to the internal texts defined within a form/component which can also be used to provide either a text or a message.

 

The designer dialogs that support the changing of a text reference have been changed to show all texts in the linked Texts entities.

 

In V4.0, a message id is an integer and the Messages Editor in the designer automatically created the next numbered message. In V5.0, this key has changed to a String and the designer is free to enter any value they like. This also means that the Javascript API has changed to accept a String instead of an int, and all the int methods have been deprecated.

Translation

In V5.0 all texts are saved in language specific files e.g. each form contains a texts folder which will contain one file for each language for which texts have been configured e.g. EN.properties, SP.properties. These files are saved in the format of standard Java properties files and can be used as input to external translation tools to create additional language specific files. These additional files are then dropped back into the workspace. Alternatively, translations can be provided using the tools in the Ebase Xi Designer.

Components

In V5.0, components can be created anywhere – not just in the GLOBAL project. Upgraded systems will contain a GLOBAL project and this will be linked to all other upgraded projects; however in V5.0, there is nothing special about this project – it is treated the same as all other projects.

 

In V4.0 a component script can be “overridden” in a deployed form by creating a script of the same name in the form’s project. Additionally if this is an FPL script, the execution context changes from the component to the form i.e. the script can access form elements. This behaviour is still maintained in V5.0, but the rules are slightly different to allow for the possibility that a component and its deploy target are in the same project:

 

·         Any component script can be overridden by placing a script of the same name in the form’s project or a project higher in the search path than the original component script.

 

·         The execution context of an FPL script is changed only if the component and the form are in different projects (for upgraded forms this is always true since all components are in the GLOBAL project, but this is not the case for new components in V5.0).

 

In V4.0 components could only be deployed to target forms or components if the target was not currently being edited. This restriction has been removed.

Static Lists

This has a new editor which is the same editor used for all texts. It supports using the up/down keys to quickly create new list entries, and supplies a new way of building multi-lingual lists.

Dynamic Lists

The validation mode feature – checking user input in a text box against the list – has been removed with no replacement.

 

The editor will highlight SQL keywords in the SQL boxes.

Email

Configuration of email servers including authentication details has been changed. In V4.0 only one email server could be specified and this was configured in UFSSetup.properties. In V5.0 any number of email accounts can be configured where each account represents a connection to a specific email server including authentication details. Email accounts are created and maintained using the Server Administration Application. Each Email Resource is then configured to use a specific email account. Configuration of an email account has been extended to include options to use SSL and TLS, plus the ability to add any additional properties supported with the javamail API. These changes are intended to make it possible to connect to any email server that supports the SMTP protocol.

 

The ability to specify a reply to address has been added to Email Resources. When specified this replaces the from address as the reply address.

Other Resources

For all resource types(excluding Custom and XML based resources): new fields can be added using the up/down keys.

 

Database Resources

·         the editor will highlight SQL keywords in the SQL boxes

·         the import wizard and create Dynamic List wizards have been re-written

 

Custom Resources

·         classes missing from the classpath are shown in red

 

Wizards to create Database Resources and Stored Procedure Resources by importing from database schema are now available from the Tools menu.

Database Connections

These have been removed from the designer in V5.0. They are now created and maintained using the Server Administration Application and are saved to file ebaseConf/databases folder within the Ebase web application on the server.

Web Services and Integration Services

The Web Services editor panel has been removed from the designer in V5.0. Its functionality has been split between the Integration Service Editor and the Server Administration Application:

 

·         Integration Service Editor: in V4.0, the main panel (containing the page editor for forms) is empty. In V5.0, this now contains a web services panel which allows creation of one or more web services, specification of the Soap version, and configuration of security headers.

 

·         Server Administration Application: supports enabling/disabling, redeploying (when an Integration Service has changed) and WSDL display.

 

The Integration Resource wizard has been re-written.

System Services

In V4.0, two System Services LOGON_SERVICE and WORKFLOW_ASSIGNMENT_SERVICE were supplied as part of the Ebase Xi distribution on the System Services project; these supplied services could be modified but could not be created or deleted. In V5.0, the same two services are supplied and these act as the default services; but it is now possible to create any number of additional services anywhere in the workspace.

 

Logon Service

The default Logon Service to be used is specified using the Server Administration – Security Properties. In addition, the system.securityManager.logon() Javascript function has been extended to allow the specification of which Logon Service should be called. Click here for more details.

 

Workflow Assignment Service

The default workflow Assignment Service to be used is specified using the Server Administration – Workflow Properties. In addition, each workflow process can now override this default and specify the assignment service that should be used. Click here for more details.

Presentation Templates

·         The implementation of a default presentation template has been changed. Designers need to reset this using Designer > Preferences. The project containing the default template is automatically linked to all new projects to make the template accessible.

·         The set template command and Javascript equivalent have been changed to support paths (see Scripts).

Client Javascript and Style Sheets

In V4.0, both client Javascript scripts and Style Sheets were entities, and client scripts provided the ability to configure an external script. Style sheets also provided an external configuration option but this was done in a different way - inside the Style Sheet editor.

 

In V5.0, both of these have been converted to be web resource files (see Web Resources). This means that they appear in the designer tree as xxx.js and yyy.css and are saved as simple files, but otherwise are very much the same as in V4.0. The option to configure external links is still available, but this is now configured in the same way for both javascript and style sheet files.

 

URL’s to javascript and style sheet files configured within the workspace begin with $ws as described earlier.

Print Master Pages

The default print master page no longer exists.

Workflow

The ability to release a workflow process or an activity is no longer available. Instead, the current version of all entities will be used for new workflow jobs and these same entity versions will be used for the duration of the workflow job – this is the same behaviour as V4.0 including the release mechanism.

 

A scheduled task to archive or delete completed jobs from the workflow runtime database has been added. This can be used to control the size of the runtime database; a very large runtime database can adversely affect performance of the workflow system including the response time of the tasklist application. Click here for more details.

 

Workflow processes can no longer be activated or quiesced – they are always active. The corresponding methods in the workflow API have been deprecated.

 

Deletion of a workflow process in the designer has changed. In V4.0, a deleted process was flagged but not deleted, and it was then possible to later “reinstate” it. In V5.0, workflow processes are treated the same as all other entities and are physically deleted.

 

The polling interval of the workflow database can now be configured in Workflow properties within the Server Administration Application. In V4.0 this was fixed at 100ms, the default in V5.0 is 250ms.

 

The workflow runtime database tables in the repository database are still used in V5.0.

FPL Functions

These are maintained using the Server Administration Application and are saved to file ebaseConf/userFunctions.xml within the Ebase web application on the server.

Global Metadata

Global metadata is maintained using the Server Administration Application and saved to file ebaseConf/metadata.xml within the Ebase web application on the server.

System Texts

These are maintained using the Server Administration Application and are saved to directory ebaseConf/systemTexts within the Ebase web application on the server.

 

In the designer, system texts are hardly used, the only exception probably being the “Please Select” text that appears at the top of static lists. So there isn’t much need to configure these texts. However, they can be configured if required by editing the individual text language files in preferences/systemTexts within the designer file system. The systemTexts directory can also be copied from the server to the designer.

Languages

Languages and server language options are maintained using the Server Administration Application, and are saved to files ebaseConf/languages.xml and ebaseConf/languageOptions.xml within the Ebase web application on the server.

 

Languages must be configured on the server before they can be used (same as for V4.0).

 

Languages on the designer do not need to be explicitly configured; all languages are automatically available and shown in all dropdown lists. This is different from V4.0 where designer languages were explicitly configured and shared with the server. The designer can specify their default language in Designer Preferences (same as for V4.0).

Security

Maintenance of the supplied Ebase security system – users, roles, groups – has moved from the designer to the Server Administration Application. Security is no longer used by the Ebase Designer. The Ebase security system is used to control access to the Server Administration Application and to implement deployment security. Customers may also choose to use it for their server-side security requirements.

 

As there is no designer user, a userid is not passed into the server when testing a form (as with V4.0). If the server property Enable Authentication of New Users is configured, the logon exit will be invoked when testing a form i.e. this is treated the same as running a form from any user.

 

There is now only one set of LDAP configuration properties (in V4.0 there were two) and these are in ebaseConf/security.properties. LDAP security properties in UFSSetup.properties are no longer used.

Scheduled Tasks

In V4.0, Scheduled Tasks were maintained and displayed using Tools > Scheduled Tasks within the designer. In V5.0, Scheduled Tasks are now entities and can be created anywhere in the workspace.

 

New Scheduled Task options (compared to V4.0):

·         Ability to specify form URL parameters for form runner task

·         Ability to run any task at any time (using Server Administration Application)

·         More scheduling options

·         Ability to create a PDF from a form running as a Scheduled Task

·         Ability to schedule a form to run in background via the API SchedulerServices.runBackgroundForm()

 

Execution failures are highlighted when displaying task logs using the Server Administration Application.

 

Scheduled task execution uses tables in the repository database.

Batch

Maintenance of the batch system has been moved from the designer (Tools > Batch in V4.0) to the Server Administration Application in V5.0. It supplies the same functionality except it is no longer possible to edit batch input documents to correct errors.

Sequences

In V4.0, sequences were implemented as a single entity within IT Elements in the designer and this could be exported/imported, which could occasionally cause problems. In V5.0, sequences have been removed completely from the designer. Instead, a sequence is created automatically when it is referenced by a form on the server: it is created using the maximum possible number range and numbering starts from 1.

 

If required, sequences can be maintained using the Server Administration Application.

Calendar

This calendar provides the ability to configure non-working days within an organisation and can then be used to calculate the next working day at some point in the future. In V4.0, this was only used by workflow escalators; in V5.0 it has been promoted and can be used by any application. It is accessed using new methods in DateServices. It’s maintained on the server using the Server Administration Application and is saved in the repository database.

 

Click here for more details.

Snapshots and Save/Restore

! It is not possible to restore a snapshot created in V4 into V5. The same restriction applies to save/restore. However, starting from V5.0 both snapshots and save/restore have been changed to be release independent so this restriction will not apply in the future.


Designer Changes

Miscellaneous

This section lists designer changes that have not already been mentioned.

 

·         Designer security has been removed

 

·         Locking of opened elements has been removed

 

·         The ability to open an entity as read-only has been removed

 

·         Many of the icons have been replaced.

 

·         On all occasions where a name can be entered e.g. new entity, new field, new table, validation of the name is performed as you type and any error messages are shown immediately.

 

·         Most of the dialogs that display a table of entries supporting addition of a new entry have been changed so that new lines can be added and deleted using the keyboard up and down keys. This includes new fields, new columns, new texts and many other dialogs.

 

·         The References Panel, Uses Panel, Client and Server Event Map Panels, Refactor Panel and Search Results Panels in V5.0 are all separate dockable panels and they can be dragged to different locations, minimised, hidden etc.

 

·         Search dialogs (Ctrl Q and Alt Ctrl F) have been changed. Alt Ctrl F now shows a dialog that can be used to search the content of all files in the workspace that have textual content. This includes scripts (all types), style sheets, text, properties, JSP, HTML, SQL files etc – click here for details.

 

·         Entity Chooser Dialog: this is a new dialog which is shown whenever there is a need to choose something from the workspace – usually to configure a relationship. This dialog has a number of ease of use features:

o        Search box at the top accepts a regex string to filter names displayed; search string can be cancelled via icon at r-h side of search box

o        Use of up/down keys to quickly navigate

o        Press enter key to select an item

o        Open items shown in bold

 

Click here for more details.

 

·         The Tools menu has been changed – many items have been removed (and are mentioned elsewhere in this document).

 

·         Unsaved entities are now flagged with an * in the open items toolbar

 

·         When navigating to a field’s properties by clicking on a field name in the Field Control’s properties, the Fields Panel will now scroll to show the selected field and select it. The same is true when navigating to a table or table column from the appropriate controls.

 

·         The Tables panel now opens to show all tables initially closed.

 

·         Documentation notes can be specified for all entities. In V4 this existed only for selected entities: forms, components, scripts etc.

 

References, Uses, Deletion and Refactoring

References between entities and web resources or between sub-entities (e.g. fields, tables, property sets are all examples of “sub-entities”) are stored in the designer in a new Data Dictionary which is implemented as an embedded Derby database. In the initial release of V5.0 this includes most, but not all, relationships – in particular, relationships from scripts and relationships to/from individual texts are excluded; these will be added in a later release. This referential information is used for a variety of purposes including:

 

  • Display References: right-click on any referenceable entity or sub-entity to display anything that references it in the References Panel: this panel shows the referencing entity and sub-entity e.g. it might be a form or a presentation template or a control on a page. Double clicking on any leaf item (lowest level within the tree display) will attempt to open the item to show the referencing item. 

 

  • Display Uses: this is the reverse of Display References: it displays all the entities and sub-entities used by the selected item in the Uses Panel. Double clicking on leaf items opens them in the same way as for the Display References Panel. Typically a form will use many other entities – scripts, template, client javascript etc.

 

  • Deletion: if an attempt is made to delete an entity or sub-entity that is referenced, a popup dialog shows the number of references and provides options to display these references in a Refactor Panel. Double clicking on leaf items in this panel opens the corresponding item. This panel also contains a Rerun button at the bottom which will attempt to re-execute the delete operation. This provides the opportunity for users to manually correct any entities that are affected by the delete, and then re-run it.

 

  • Refactoring: refactoring includes: rename, move and drag and drop. Refactoring works in a similar way to deletion. If an attempt is made to refactor an entity or sub-entity that is referenced, a popup dialog shows the number of references and provides options to display these references in a Refactor Panel. Double clicking on leaf items in this panel opens the corresponding item. This panel also contains a Rerun button at the bottom which will attempt to re-execute the refactoring operation. Clicking Rename in the popup will perform the operation, adjust any references and save the entities containing these references.

 

  • Missing items: when a referenced entity or sub-entity is missing, the reference to it is displayed in red – this is at the point where the reference is configured e.g. if a script is missing, the error will be shown in the events dialog, if an image is missing, the error will be shown in the control or field properties where the URL is configured. Also, when the referencing entity is opened, its icon in the open items toolbar (at the top of the designer) is shown with a small red x in the bottom left-hand corner; at the same time, the Uses Panel is displayed containing a Missing Entities section at the bottom which provides details of exactly what is missing, also displayed in red.

 

Click here for more details on all aspects of references.

 

Import/Export

A new ability has been added to export one or more entities from the workspace into an archive file and similarly to import from an archive file. This replaces the V4.0 import/export functionality. Note that there is no ability to import a V4.0 XML export file into V5.0 – instead V4.0 systems must be upgraded.

Upgrade

The upgrade process extracts all entities from the Repository database and saves them in the workspace. All references to other entities and web resources are adjusted at the same time. Here are some of the details:

 

·         A Shared project is created in the workspace which contains:

·         External Resources

·         Lists

·         Templates

·         Print Master Pages

·         Shared Texts

·         Web Resources: Client Javascript files and Style Sheet files

 

·         A GLOBAL project is created in the workspace which contains:

·         All Components

·         All global scripts

·         A GLOBAL_Messages Texts entity (corresponds to the GLOBAL messages of V4.0)

 

·         Both the Shared and GLOBAL projects are linked with all converted business projects. This makes the contents of these two projects accessible to all other projects.

 

·         Each form is linked with the following Texts files (see the Texts tab of Form Properties);

·         /PROJECT1_Messages (corresponds to the messages entity for the business project from V4.0)

·         /GLOBAL_Messages (corresponds to the GLOBAL messages of V4.0)

·         /Shared_Texts (corresponds to the Shared Texts from V4.0)

 

·         All Client Javascript and Style Sheet entities are converted to web resource files ending with .js or.css and all references to these are changed correspondingly.

 

·         All versions of released workflow processes are saved to the ReleasedWorkflows folder within the workspace.

 

·         An Integration Services project is created for all Integration Services and associated scripts. Similarly a System Services project is created for all System Services and associated scripts.

 

·         A new ebaseConf folder is created within the web application on the server and most existing server properties are migrated to new files in this folder