White Star Software Exchange 2005 – DEV-15 DEV-15 All Dynamic Applications John Campbell White...

White Star SoftwareWhite Star Software Exchange 2005 – DEV-15Exchange 2005 – DEV-15

DEV-15DEV-15All Dynamic ApplicationsAll Dynamic Applications

John CampbellJohn Campbell

White Star SoftwareWhite Star Software

White Star SoftwareWhite Star Software Exchange 2005 – DEV-15Exchange 2005 – DEV-15 22

My BackgroundMy Background

• 20 years of Progress

• Written Several Books

• Created TailorPro

• Speaker at many Conferences

• Architect and Developer

• Progress consulting since 1985

• Performance and Disaster Recovery– (That’s Adam)

• Application architecture and development– (That’s me)

• Personal relationship with clients

Presentation OverviewPresentation Overview

• Design for migrating existing character application to GUI and Web

• AP Background

• Application Goals

• Design and Architecture

• Technology

Background Background

• Tasked to assist in software design and architecture

• Existing application partner

• Medical Practice Scheduling

• 18-year old Character Application

• Need to move to GUI for Windows and Full GUI on the Web

Application AssociationApplication Association

• Had worked on early development

• Knew Primary Developer

• Product Knowledge

• Architectural Skills

Architecture GoalsArchitecture Goals

• Too Easy to “code and go”

• Hard to revise later

• Good foundation is a key for– Scalability– Flexibility– Maintainability

Client ProfileClient Profile

• Medical Scheduling

• Primarily ASP Model

• Some on-site installations

• Needed to support full GUI in web access– Off-site doctors– Off-site data entry

Application RequirementsApplication Requirements

• Extremely Rich Application

• Some Highly Complex Browsers

• Complex Business Rules

• Simple Maintenance Screens

• No Compromise of Full GUI

• Run (quickly) Over Internet

Long Range GoalsLong Range Goals

• High usability

• Realistic data model

• Ease of Extensibility

• Ease of Maintainability

Possible SolutionsPossible Solutions

• No Initial Architectural Restrictions

• We considered the following– Non-Progress– ADM2– DWP– Progress Dynamics®– Self-made

White Star SoftwareWhite Star Software Exchange 2005 – DEV-15Exchange 2005 – DEV-15

Application Design Application Design ChoicesChoices

Environment ChoicesEnvironment Choices

• Progress– Powerful, Rich Environment– In-house Progress expertise

• AppBuilder based GUI– Allows Local or Web Distribution

• WebClient™ for Web– Acceptable issues

• Dynamic Coding– Small footprint– Single point maintenance

Data ManagementData Management

• AppServer™ Enabled

• ProDataSets for data management

• Single server- and client-side apps for– Retrieval– Update– Maintenance

ArchitectureArchitecture

• Data retrieval modules separated on server

• Display components data independent

• Specialized uses means small footprint

• Many users do same task

• Reduces overhead of web client download

Single ApplicationsSingle Applications

• Data Retrieval

• Data Storage

• Lookup Browser

• Lookup Detail

• Data Entry

InterfaceInterface

• Some Static Interface Components for Maintainability

• Dynamic Lookup Browsers, Queries

• Dynamic Detail Screens

• Dynamic Data Entry Screens

ObjectivesObjectives

• Partition– DB I/O– Validation– Business Rules– Interface

• Use AB to design – Screens– (Most) Browsers

• Dynamic Screen Objects• Dynamic Data

Validation and Business RulesValidation and Business Rules

• Primary Validation on Client

• Some on server

• Business rules on server

Associating Business RulesAssociating Business Rules

• Data Driven

• Screens validation

• Business Rules

• “Hooks” in code

Interface ArchitectureInterface Architecture

• Primary (scheduler) Browser

• Secondary (lookup) Browse

• Lookup Detail

• Maintenance Screens

• Toolbar

Scheduler BrowserScheduler Browser

• Starting point for all functions– Baseline is Static– Easier visualization – Columns and data dynamic– Individual Cell Colored– Multiple views of data

SchedulerScheduler

Lookup BrowsersLookup Browsers

• Static Window• Browser Completely Dynamic• Data Context Sensitive• Availability is Data-driven• Designed with AppBuilder• Stored in Repository

– Columns– Query– Key fields

LookupsLookups

Dynamic Button if field can be looked up

Simple Dynamic BrowserSimple Dynamic Browser

Dynamic sort and search ability

Dynamic Browse Code SampleDynamic Browse Code Sampleif not valid-handle(hBrowse) then create browse hBrowse assign height = 5 width = 55 frame = frame BrowseFrame:handle row = 2 column = 5 query = hQuery visible = yes sensitive = yes separators = yes width = 65 allow-column-searching = true triggers: on start-search persistent run StartSearch in this-procedure. on value-changed persistent run Valuechanged in this-procedure. on any-printable persistent run AnyPrintable in this-procedure. on backspace persistent run Backspace in this-procedure. on return persistent run BrowseReturn in this-procedure. end triggers.

Dynamic Browse Code SampleDynamic Browse Code Samplefor each tBrowseColumn: /* point to the dynamic temp-table field which corresponds to our static temp-table structure; build the browse column exactly like the temp-table column, which is a proxy for the actual DB Column of the same name */ hTTColumn = hTTBuffer:buffer-field(ColumnName). /* c-race.race-code */ hBRColumn = hBrowse:add-like-column(hTTBuffer:name + "." + hTTColumn:name) no-error. if tBrowseColumn.ColumnLabel <> "" then hBRColumn:label = tBrowseColumn.ColumnLabel. /* let the browse know if we can sort on this column */ hBRColumn:private-data = string(sortable). end. assign fieldrow = hbrowse:row + hBrowse:height-chars + .1 hBrowse:fit-last-column = yes hFillin:row = hBrowse:row + hbrowse:height.

Lookup Detail - DesignLookup Detail - Design

• Static window

• Dynamic Fields

• Designed with App Builder

• Stored in Repository

Simple Detail ScreenSimple Detail Screen

Lookup Detail - FunctionLookup Detail - Function

• Not updateable

• Context sensitive

• Persistent window– Data changes if browse row changes

Maintenance Screens - DesignMaintenance Screens - Design

• Similar to lookup Detail:– Static window– Dynamic fields– Build with AppBuilder + Tool

• Save screen definition data to repository

Maintenance Screens - Maintenance Screens - FunctionFunction

• Single Toolbar for all Applications

• Able to associate maintenance screen with a specific browse – Data context sensitive

• Also can run any screen standalone

Dynamic sort, search and filter

Screen RepositoryScreen Repository

• Location of interface data• Small Tables• Easy to Transfer Data• Simple to identify if already on client

– (Don’t reload)

• Static temp-tables– Clarity– Maintenance

Repository StructureRepository Structure

Module

Browse Maint Screen Detail Screen

ProgramProgram

ProgramColumns ProgramFields ProgramFields

Screen ScalingScreen Scaling

• Originally None

• Ultimately– Agreed to limit

• Number of Browse Columns• Number of Screen Fields

Data ManagementData Management

• Dynamic temp-tables defined for user data

• ProDataSets used for these TTs

• Dynamic query for context-sensitive data

• DataSource set to dynamic query

Data Management Data Management

Menu Choice

Client App Server / DB

Screen Data Request

Screen Paint

Data Selection User Data Request

Data Presentation

Data Update Data Storage

1 – Menu Choice

2 – Screen Paint

3 – User Data

4 – Data Update

Code SampleCode Sample

/* --------------- get actual table data ------------------ *//* first, create an empty DB buffer structure */create buffer hDBBuffer for table pTableName.

/* create the empty temp-table structure handle */ create temp-table hDataTT.

/* clone the DB structure into the temp table */hDataTT:create-like(pTableName).

/* add the rowid field so we can find the DB record later */hDataTT:add-new-field("fRowid","rowid").

/* set it to undo-able so we can set tracking changes on */hDataTT:undo = yes.

/* create the temp-table with a name of "t" + the table name: tc-race note -- this is critical in the submitchanges.p program -- q.v. */hDataTT:temp-table-prepare("t" + pTableName).

/* get a buffer handle for the temp table */hTTBuffer = hDataTT:default-buffer-handle.

Code Sample ContinuedCode Sample Continued/* now create a dataset for the t-t buffer */create dataset hDataSet.hDataset:set-buffers(hTTBuffer). /* Next, create the query to the DB */create query hDbQuery .hDBQuery:set-buffers(hDBBuffer).

/* now, a data-source for the query and tt-buffer */create data-source hDataSource.hDataSource:query = hDBQuery.hTTBuffer:attach-data-source(hDataSource).

/* set an event method to populate each row with the rowid */hTTBuffer:set-callback-procedure("after-row-fill","SetRowid",this-

procedure).

/* create a query for getting records out of the DB */hDBQuery:query-prepare(pQueryPhrase).

/* fill the dataset from the query */hDataSet:fill().

Submitting ChangesSubmitting ChangesassignhAfterBuffer = hSaveDataSet:get-buffer-handle(1)hBeforeBuffer = hAfterBuffer:before-buffer.

/* temp-table name = "t" + tablename, so table name is obtained by shaving off the leading "T" */

create buffer hDBTable for table substring(hAfterBuffer:name,2).

/* build a query so we can process the T-T records */ create query hQuery.hQuery:add-buffer(hBeforeBuffer). /* knows about both creates and

deletes */hQuery:query-prepare("for each " + hBeforeBuffer:name).hQuery:query-open().hQuery:get-first().

Saving Updated RecordsSaving Updated Recordsdo while not hQuery:query-off-end transaction: case hBeforeBuffer:row-state: when row-modified then do: /* get the rowid of the databse table from the t-t record */ pRowid = hBeforebuffer:buffer-field("frowid"):buffer-value. /* find the DB record */ hDBTable:find-by-rowid(pRowid) no-error. /* see if the "before" T-T and the DB are different */ RecordUnchanged = hBeforeBuffer:buffer-compare(hDBTable). /* if the db record isn't changed, we can save data back */ if RecordUnchanged and hDBTable:available then do: /* but it's the AFTER record which holds the changes */ hAfterBuffer:find-by-rowid(hBeforeBuffer:after-rowid) no-error. /* if everything is OK, then we copy the after to the DB */ hDBTable:buffer-copy(hAfterBuffer). end. end. /* modified */

Save Row ChangesSave Row Changes

• Simple method for saving ProDataSet changes

• Seems to work fine if DataSource is buffer, or static query

• Apparently need to have individual code blocks for modified, created and deleted if DataSource is dynamic query

Validation ProgramsValidation Programs

• Simple validation on client

• Complex validation on server

• Data driven

Validation ProgramsValidation Programs

• Maintenance Screen repository has field for validation program

• Server side program associated with buffer name– Table level validation– Field level– Internal procedures– Code looks for program and internal

procedures according to naming conventions

ConclusionConclusion

• Progress offers significant value in application development

• Application partners are choosing it to build new apps with

• Language is unbelievably powerful and flexible

More ConclusionsMore Conclusions

• There are many Progress development paradigms

• Sometimes, you don’t need to use an existing model

• Full development model does not need to be – Complex– All-encompassing

Dynamic CodingDynamic Coding

• Distinct advantage of Progress

• Gives significant versatility

• Can be well written (if documented)

• Highly compact

• Extremely powerful

• Very flexible

Contact us at wss.com

Questions?

White Star Software Exchange 2005 – DEV-15 DEV-15 All Dynamic Applications John Campbell White...

Documents

White Dwarf Kicks in Star Clusters - cxc.harvard.educxc.harvard.edu/fellows/viewgraphs/2009/fregeau.pdf · White Dwarf Kicks in Star Clusters John Fregeau, Harvey Richer, Fred Rasio,

Legal Biz Dev Pricing White Paper x

White Star, Black Hole

Southern Crab Nebula - AmazingSpaceaging red giant star and a white dwarf— a burned-out star. The red giant star is shedding some of its outer layers, which spill onto the white

Veteran career star accelerator white paper

WHITE STAR MUD PUMP MAINTANENCE MANUAL-latest

Marcel and the White Star

Profiling Suspicious Code Tom Bascom White Star Software

Q1 2020 WORKBOOK Q1 2020... · 2020. 1. 24. · Z-STAR-XV6_WHT_(12) PURE WHITE 10273559 Z-STAR-XV6_TYL_(12) TOUR YELLOW 10273563 Z-STAR-XV6_WHT_HALF DZ (6) PURE WHITE 10283098 Engineered

White Star Kids - Catalogo 2012

Jim Critchlow - White Star

シューレース専門店の靴ひも屋トップページです · pst103 checker white red pck102 star white red pst104 checker white gray pck103 star black white pst 105 checker

WHITE DWARF By Hope Alridge. THE GENERAL CYCLE OF A STAR NebulaStarRed GiantRed dwarf White dwarf Supernova Neutron Star Black Holes

Astro2020 Science White Paper Towards a Theory for Star ... · Astro2020 Science White Paper Towards a Theory for Star Formation on All Scales Thematic Areas: Planetary Systems Star

White Dwarfs Neutron Stars and Black Holes. Red Giant vs Sun Sun vs White Dwarf White Dwarf vs Neutron Star Neutron Star vs Black Hole Solar Mass Star:

A radio pulsing white dwarf binary star

Benefits of Media Planning - White Star Media

004 Marcel and the White Star

The demographics of neutron star – white dwarf mergers

Star Death From white dwarfs…......to black holes