Login Register Actian.com  

Actian Community Wiki

Navigation
Learn About
Developing With
Ingres Talk
Information
Toolbox

Ingres Roadmap/OpenROAD 6.2

From Ingres Community Wiki

Jump to: navigation, search

Contents

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


Image:announce_discuss.png=Discussion Image:announce_planning.png=Planning Image:announce_design.png=Design Image:announce_develop.png=Coding Image:announce_beta.png=Code Complete Image:announce_release.png=Stable Image:announce_terminate.png=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
  • 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


EntryField enhancements

Adjustable field-level margins

Application Behaviour

Fields enhancements

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



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.

Personal tools
© 2011 Actian Corporation. All Rights Reserved