From Ingres Community Wiki

Contents 1 OpenROAD 6.2 2 Application Appearance 2.1 Displayed fields enhancements 2.2 TabFolder enhancements 2.3 EntryField enhancements 3 Application Behaviour 3.1 Fields enhancements 3.2 Rich TreeViewFields to support virtually all industry-standard features 3.3 Tagged Values 4 Sprint Projects

OpenROAD 6.2

Status: WIP in progress planning page.

Project Objectives	OpenROAD 6.2 is highly focused on providing developers the ability to improve the appearance of their end-user application.
Target Platforms	All

=Discussion =Planning =Design =Coding =Code Complete =Stable =Terminated

Application Appearance

The following features have been added to allow the application developer to adjust the appearance of the application in the 4GL code at runtime. In addition, these features will be adjustable by the application end-user, should the application developer provide them with the capability.

Displayed fields enhancements

• Bordering and backgrounds and gradients to match any current style
  • Addressed via multiple development background bitmap projects
• bitmap transparency (bitmapclear)
• Opacity
  • Typical current uses are:
    • alternative to dimming in all dimming scenarios:
    • buttons/windows/panels other than the appropriate one are made part-opaque to signal irrelevance.
    • Our dimming implementations are variable in quality and largely restricted to text not background
    • Part-opaque window edges to signal temporary informational popups
    • Watermarking to notify of ownership/restricted reuse rights for data
    • Indication that a field (and therefore a facility) is present in case required (typically it solidifies on mouseover). For example:
    • Empty checkboxes are extremely noisy, especially in table-based situations, and make the screen hard to read. When present but opaque, the user is aware of the option without being distracted
• Exact width and height settings [(including zero size)] for vertical tablefields
• Embedded “sprites” (for schematics, tracks, arrows, map features, etc.)
  • Typical current uses are:
    • Hotspots in diagrams, maps, text areas, multifunction fields
    • Information sprite (white “?” on blue oval) in textfield margins (think of “what’s this”) , on downclick pops up howto/what panel
    • Dropdown arrow on buttonfield, when clicked shows menu options with extended capabilities, but user can just click main area of button for principal function. Look at the top of this window for many examples. This can be intrinsic if we want, since any field can store a menu.
    • Dropdown optionlist on entryfield righthand margin
    • “Drag move” sprites for design processes involving complex layouts – room allocation, fastest-route-involving, garment choice, screen-layout-design, …

TabFolder enhancements

• Bitmapped tabs (an additional tabbar style option)

EntryField enhancements

• Provide the ability for developers to tune their EntryField text displays in different circumstances

Adjustable field-level margins

Application Behaviour

Fields enhancements

• Intrinsic [mobile] hotspots for multiple click behaviours (Buttons with dropdown arrows, input fields with help/warning sprites, etc)
• Embedded “sprites” that can move or switch at runtime
• FieldsByProperty capability

Now the fields on a form can be collated for selection and manipulation into a single array of all the fields, or just those fields with a characteristic propertyvalue (all tabpages, all dimmed fields), or a characteristic tag or tagvalue (all fields unrelated to the compositefield’s userclass); as well as wildcarded, formatted versions of any of these conditions. The search can be on the whole form, any compositefield, or any array of fields passed to the method, enabling collections to be refined and combined.

This offers a dramatic reduction in collection and manipulation code, and increase in the control that developers can exercise over the frame display and functionality at runtime.

Rich TreeViewFields to support virtually all industry-standard features

• Branch Cut and Paste, Multinode selection, Autosizing, Rightclick without select

Tagged Values

Tagged Values

Allow you to extend the definition of an application, field, or class as much as you like, by adding properties in the form of tag plus value. Tags are saved, inherited, scoped just as properties are.

• For example, an EntryField has about 100 properties built into or inherited into its definition. To add or remove a single one of these requires days, weeks, months. Or you can add or remove a taggedvalue-defined property in a single line of code.

Result?

• An awful lot of fragile 4gl code using frame- and global-scope variables to hold property values becomes unnecessary.
• A new set of robust context-related capabilities becomes possible that was not practicable before

Allow you to add ancillary information to the definition of an application, field, class, attribute or method (think of properties of properties).

• For example, any business-object attribute will typically get its value from a database table column. To specify which one requires SQL, and SQL is hardcode not definition, and cannot itself be queried. Or you can just add a taggedvalue to the attribute, specifying the column it maps to.

Result?

• An awful lot of fragile hard SQL code, including add, browse, change, delete, lookup, validate code, can be replaced by a single query generation engine.
• All the rich context information a database holds can be captured and stored alongside the corresponding application elements, instead of being partly and randomly re-coded in the 4gl by a developer with no database experience.

The generators

Are a direct consequence of this:

• the userclass generator mines the database for information about cross-table relationships as well as attribute cardinality, naming standards, etc, and uses this to define not just one but a constellation of interrelated business-classes, not just the ingres-datatype but the business-datatype of any attribute, not just the name but the business category of any attribute (datetime, financial, identifier, location, etc etc), as well as the application database mappings mentioned above.

• The display generator exploits the information captured by the userclass generator to create displays where like fields are grouped in panels together (identifiers, dates, financials, location), just as the enduser expects, and the business object interrrelationships (identified from the database cross-table relationships) are visualized as subpanels and tablefields in the main display.
  • The query generation engine mentioned above can be applied directly to such a display to provide all the standard data handling with no business-area-specific code.
  • The fields, panels, tablefields can be deleted at will (or better still, marked for non-generation) and everything still works

• The tagged value properties are the glue that makes all of this possible.

Sprint Projects

A number of Sprint projects will also be included in this release. They are documented at OpenROAD Projects with the release that they will be included in clearly noted next to the project.