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

data managementsingle

application associationhad

web distributionwebclient

software design

existing character application

background20 years of

dynamic browse code

architecture goalstoo