Introduction

The BuildProfessional Version 8 Developer (xdev) is a complete redesign of the tools and services used to create and maintain BuildProfessional applications. This guide outlines the core concepts and facilities in the Version 8 Developer.

First, the new Developer is step in a longer term strategy to build a comprehensive platform for business application development. The Version 8 Developer is targeted to existing BuildProfessional developers that develop and manage existing application infrastructure. Therefore the Developer lacks the wizards and assistants required when building an application from scratch. This functionality will be introduced at a later time.

The Developer makes extensive use of XML in all its related technologies. If you are not familiar with XML we have provided a brief section on the basics of the relevant technologies.

The Developer provides a large variety of configuration options for team development, automated coding, source code control and integration of other tools and products. However it is important to note that the Developer remains a fully packaged solution ready to run without any configuration.

The Developer is an environment that provides a collection of tools like a component explorer, logic editor and screen painter. Most of the tools use common defacto user interface standards and most developers are productive immediately upon installation.

About XML

XML technologies are central not only to the applications being developed, but also in the Developer itself. The Developer embraces and uses XML technologies in every facet of it functionality. Here are brief descriptions of some of the XML technologies that BuildProfessional makes use of:

XML is nothing more than a common format for storing data. Instead of cryptic storage types and proprietary file layouts, XML uses human readable text with some tags to make it simple for a computer to process. Tags are used to identify the start and end of strings. While XML is commonly associated with Web solutions and e-commerce, it simply a format of data that can be used in any solution. There are some basic rules to writing XML and if the data follows these rules, the XML data is "well-formed". BuildProfessional will tell you if the xml data you are attempting to process is well-formed or not. It is not possible to process XML data that is not well-formed.

XML Parser. While XML seems like standard ASCII text, writing and especially reading XML can be quite complex. Instead of reading XML data directly we always go through a parser (a program built into BuildProfessional that knows how to effectively read and write XML data).

XML Schema (XSD). To define what items of data are allowed in a specific XML file, another XML technology, XML Schema's, are used. These files, normally stored with file extension .xsd, can dictate strict rules on values in the XML. If XML data does conform to a schema, it is invalid (but might still be well-formed). You can process invalid xml data, but in most cases you will not.

XML Transformations (XSLT). Once your data is in XML format, the most convenient method to alter the data to another format or layout, is by using a transformation. XSLT is a standard set of rules that allow you to convert one xml document into another. For example you could transform a list of records with five columns to a re-sorted list of three columns and a fourth calculated column, all using a single BuildProfessional command referencing a transformation.

XHTML. Almost identical to HTML, XHTML is used to render web pages. You typically transform XML data to XHTML when displaying report or other data that need fonts and colors.

XML Services. This is the method used to transfer data between two programs on the same or different computers. It is networking technology like most other, but happens to work well with modern Internet style networking hardware and XML formatted data.

The Developer

To start the new developer, select the Developer icon or run "wintdyx -uxdev". On the login start screen select "Use Internal Server" and open an application to develop. Upon startup a developer profile is created for the current developer user. The profile is an XML file stored by user in the "bin" directory (xdevprofile...xml) and contains default settings for the development environment.

There are six views used to develop and maintain applications (accessed via the View pulldown, one of the toolbar icons or function keys). All views are independent of each other and you can switch between them at any time without losing data:

Control Center. This is a group of predefined tabs pointing to web pages of your interest. Several call internal pages that display information about your application others call public pages on the Internet. The tabs in the Control Center are defined in the developer's profile and can point to any web page such as your own intranet or project management system.

Component Explorer. The explorer style view provides a tree style view of your application components. Selecting a tree node will populate the list box with components. This could be components of a certain type (i.e. Data Dictionaries) or components modified in the last week or for a certain job id. Once the components are listed, you can scroll through browse properties, select one or several for deletion or compare two components of the same type. The Component Explorer will allow you to quickly update components, one at a time.

Logic Editor. The logic editor is a document centric style editor for logic components. Up to 20 logic components can be opened at the same time and a tab is displayed for each open logic. The find and replace feature is always visible at the right. Click on the "Usage" tab to list other components that statically reference the current function or process (requires that xref if maintained on the application). Double click on the recent list to re-open a previously edited component.

Screen Painter. The screen painter provides document centric access to one or several screen images. As controls are selected, the relevant properties are displayed to the right. The template screen is used to define the properties of new controls (if you want to add many buttons of the same size and other characteristics, first change your template). Auto-placements help you paint screen controls without using the grid. You can define a variety of rules for component placement or resizing (placements are stored in your developer profile).

Component Editor. The component editor is a document centric editor for any component (including screens and logic). Up to 20 components can be opened at the same time and you can switch between them using the associated tab. Use the Component Editor to create or modify components of mixed types.

Debug View. The debug view provides a series of features that allow you to analyse an application at runtime or following a serious error or problem. The trace view is quick and simple viewer of trace details with a convenient search feature to single out a specific function. If you run debug from the Developer, an appropriately named trace file is created automatically. Version 8 provides a debug dump feature to capture a memory image of a process. A dump is run from your 4GL code (after a serious error or manually during debugging). The Developer has a Debug dump file viewer. For example you can access all currently opened XML subsets at a certain point in time. In the view, you can view that subset as XML data or test it in a XML container.

The Repository Server

All component access is provided through an internal or remote Repository Server. The server accepts XML-based requests and returns XML-based replies. The Developer itself uses these XML requests and replies to process application source.

Advanced developer users will be able to create their own requests to process components, individually or for mass editing. Programs and applications can be produced to programmatically alter components and develop complete applications.

Other Useful Information
 

• Job Ids; Every component action (create, modify, delete) are tracked by a Job Id. Set the Job Id in the Windows / JobId screen. Job Ids are defined in the jobs_user.xml file in "bin". The Component Explorer will include all job ids defined and you can see which components have changed for a certain job id. A project id is available as a method to group several job ids in as a project.

  The Developer only tracks modifications by job id and does not provide project or job management functionality. It is assumed that the job and project ids originate from a separate project management system.
   

• Short Lists; In the Component Explorer you can create "short lists" of components that you want to make note of for some reason. Select a component in the list and press the short list add (+) button on the toolbar. Once several components have been selected, view the selection from the Component Explorer tree. For example you could browse around an application to select components for deletion. Instead of actually deleting the components, add them to a short list. Once your are done, go to the short list and delete them all at once. The advantage is that the short list can now be used when developing other applications (i.e. you want to delete the same components in several applications).
   
• Keyboard; There are a number of keyboard accelerators used throughout the Developer.
   

• Use standard Ctrl-O, Ctrl-S etc in the document centric tools.
• Use Ctrl-J or Ctrl-H to change a job id or view job id history.
• Use F2-F8 for quick access between the primary views.
• Use F11 and F12 to navigate between open components in Logic Editor, Screen Painter or Components Editor.

Large Applications

When maintaining a large application it is important to use component filters and the "Max Hits" setting to speed up component access. The settings depend on the speed of your local system and will vary from site to site and user to user. A faster machine will allow you to run quite comfortably with Max Hits at 500-1,000 components.

Internal versus Remote

There are two types of Repository Servers. Internal refers to the server built into every developer. Using the Internal you can access applications in your local repository (sfiles). Use the Internal server for large repository instructions or batch processes like Generate All.

Remote Server refers to a server accessible via Web-API. You can access your local repository as remote by using server "localhost". There is a 60 second timeout on requests to remote servers so it is not possible to perform large repository instructions (i.e. Find in all functions) or a Generate All.

Thin Client, Fat Client and Stand-Alone.

The Developer supports all configurations for development including thin client, fat client or stand-alone. The Developer will attempt to perform tasks depending on the configuration currently in use, but sometime the Developer user must select functionality based on the installation configuration. For example if you are developing in thin client mode, you will also need to test your application by selecting "Run in Client".

Output files generated by the Developer for viewing in the NetView control (Internet Explorer) is written to the tmp/web directory. If you are developing in thin client mode, the NetView control must access these files through HTTP. Therefore it is essential that the Developer server is running a web server and the tmp/web directory is available as http://{developerserver}/bptmp.

The recommended Development configuration is a central Repository Server with remote stand-alone Developers.