Building your Presentation with Classes

1
Building your Presentation with Classes
Sasha Kraljevic
Principal TSE
2
Agenda

• Presentation Layer in the OERA
• Requirements
• Design Patterns
• Implementing the Model
• Implementing the Presentation
• Implementing the View
• Integration with Common Infrastructure
• Summary

3
Presentation Layer in OERA
OpenEdge Reference Architecture

• Provides a high-level blueprint
• Allows you to separate concerns
• Helps you not to complicate your life
• Facilitates agile design and development

4
OpenEdge Reference Architecture
Presentation
5
OpenEdge Reference Architecture
Enterprise Services
Presentation
Business Components
Common Infrastructure
Data Access
Data Sources
Presentation controls the user interface and
requests data and other services
6
Demo What do we want to achieve?
7
Agenda

• Presentation Layer in OERA
• Requirements
• Design Patterns
• Implementing the Model
• Implementing the Presentation
• Implementing the View
• Integration with Common Infrastructure
• Summary

8
Presentation Layer - Requirements
must

• Have a clearly defined interface to Business
  Components (BC) and Common Infrastructure (CI)
• Be able to serve different UI client types
• Allow reuse of common code shared by different UI
  client types
• Lend itself to testing

9
Requirement 1 The Presentation has a clearly
defined interface to BC CI layers
Components in the Presentation layer should be

• Able to locate required services in the BC CI
  layers
• Able to communicate with them
• Able to handle dependencies on application state
  in a loosely coupled way

10
Requirement 2 The Presentation can serve
different UI client types
The Presentation layer

• Should not be a single monolithic body of code
• Should handle user actions in the same way
  regardless of the UI type
• Should take into account the UI type and session
  state, for example
• HTTP/ML is stateless
• Client/Server GUI may maintain state

11
Requirement 3 The Presentation allows reuse
of common code
In the Presentation layer

• Some code is responsible for handling
  information
• This should be UI independent
• Some code is responsible for responding to user
  actions
• This will be UI type dependent
• Some code is responsible for rendering the user
  interface
• This will be UI type dependent

12
Requirement 4 The Presentation lends itself
to testing

• User interfaces are complicated to test
• User actions can be hard to capture
• Small changes to the UI disrupt saved tests
• The Presentation architecture should facilitate
  automated testing

13
Agenda

• Presentation Layer in OERA
• Requirements
• Design Patterns
• Implementing the Model
• Implementing the Presentation
• Implementing the View
• Integration with Common Infrastructure
• Summary

14
Design Patterns

• A number of existing patterns can be used
• Choose one or more that match best to the
  requirements
• To list some- MVC (Model View Controller)- MVP
  (Model View Presenter)
• and their derivatives

15
Model-View-Controller versus
Model-View-Presenter
MVC Model View Controller
MVP Model View Presenter
16
Presenter versus Passive View
MVP Model View Presenter
MVP Passive View
17
Design Patterns Composite pattern for Views
18
Design Patterns Composite pattern for
Presenters
19
Example View
20
The View with the Presenter and Model
VIEW
PRESENTER
MODEL
21
Design Patterns Back to the OERA
22
Agenda

• Presentation Layer in OERA
• Requirements
• Design Patterns
• Implementing the Model
• Implementing the Presentation
• Implementing the View
• Integration with Common Infrastructure
• Summary

23
The Service Adapter and Service Interface

• Service Adapter sits outside the Model
• Connects the Presentation to Service Interface
• Service Interface sits above the Business
  Components
• Routes each request to the right Business
  Component

Presentation
Client session
Enterprise Services
Service Adapter
Service Interface
AppServer session
Business Components
Common Infrastructure
Data Access
24
The role of the Model in the Architecture
Support for a Business Component Type
The Model
Service Adapter
Service Adapter
Business Component
Service Interface
25
Implementing the Model with classes

• The Model holds data on behalf of the View
• There is a Client Business Component (CBC) type
  for each Business Component type
• Presentation layer Customer CBC type maps to a
  Customer Business Entity
• There is one instance of a CBC for each View
  element that requests distinct data of the type

26
Data instances

• Data is not held persistently in the Business
  Components on the server
• A Data Instance can represent a simple object (a
  row), a complex object (a DataSet or other form),
  a set of rows
• A Data Instance can be held by a Client Business
  Component and bound to by the View
• A Data Instance in the Model can be held as long
  as the data is needed
• A Data Instance can be shared by multiple Views

27
Example a data instance for SalesReps
Presentation
View2
View1 SalesReps
Presenter
Enterprise Services
BIND
CBC SalesRep
Svc Adapter SalesRep
All SalesReps
SalesRep BE
Business Component
Common Infrastructure
All SalesReps
SalesRep DAO
Data Access
Data Sources
28
Data Instances on server and client

• On the server
• A single Business Component can be refreshed and
  reused for all requests
• The same Business Components can be used to
  supply data to Enterprise Services
• On the client
• A single Service Adapter can be used for all
  instances of a type in a session
• Distinct Views can have distinct CBC instances
• A single CBC instance can be reused to supply
  different data to a given View

29
Example Sharing and reusing data instances
Presentation
View1 Order
View2 Order
Presenter
Enterprise Services
CBC Order
CBC
Order
Svc Adapter Orders
Order 1
Order 3
Order 5
Order 5
Order BE
Business Component
Common Infrastructure
Order 5
Order 1
Order 3
Data Access
Order DAO
Data Sources
30
Client-side code hierarchies
componentbase.cls
INVOKES
Service Adapters
The Model
INHERITS
Common Infrastructure
clientcomponent.cls
serviceadapter.cls
manager.cls
servicemanager.cls
beCustomer.cls
saCustomer.cls
factory.p
31
Looking at class-based ABL code clientcomponent
super class
CLASS pres.clientcomponent INHERITS
base.componentbase / Handle for the default
query on the top-level DataSet buffer / DEFINE
PUBLIC PROPERTY hTopRelQuery AS HANDLE
NO-UNDO GET. PROTECTED SET. DEFINE
PROTECTED VARIABLE AdapterRef AS
pres.serviceadapter NO-UNDO. END CLASS.

• CLASS inherits behavior from a base class
• PUBLIC property protects setting the value
• PROTECTED VARIABLE protects access to the value
• Also defined as a specific class type

32
Client Business Component subclass
CLASS samples.pres.beCustomer INHERITS
pres.clientcomponent samples/dsCustomer.i
CONSTRUCTOR beCustomer() AdapterRef CAST
(servicemgrstartService
("samples.pres.saCustomer, "sa"),
samples.pres.saCustomer). CREATE QUERY
hTopRelQuery. hTopRelQueryADD-BUFFER(DATASET
dsCustomerGET-BUFFER-HANDLE(1)).
hTopRelQueryQUERY-PREPARE ("FOR EACH "
DATASET dsCustomerGET-BUFFER-HANDLE(1)NAME).
END CONSTRUCTOR.

• CLASS inherits behavior from the super class
• CONSTRUCTOR executed on creation
• PROTECTED variable can be set from this subclass
• PROPERTY hTopRelQuery accessed just like a
  variable

DEFINE PROTECTED VARIABLE AdapterRef AS
pres.serviceadapter NO-UNDO.
33
Methods in the Client Business Component
METHOD PUBLIC VOID fetchWhere (INPUT-OUTPUT
DATASET-HANDLE phDSContext) DEFINE VARIABLE
iBuffer AS INTEGER NO-UNDO. DEFINE VARIABLE
hDataSet AS HANDLE NO-UNDO.
AdapterReffetchData(OUTPUT DATASET dsCustomer,
INPUT-OUTPUT
DATASET-HANDLE phDSContext). hDataSet
DATASET dsCustomerHANDLE. DO iBuffer 1 TO
hDataSetNUM-BUFFERS hDataSetGET-BUFFER-
HANDLE(iBuffer) TABLE-HANDLETRACKING
-CHANGES YES. END. END METHOD.

• Method is PUBLIC to allow access from Presenter
• VOID return type
• fetchData reference in AdapterRef verified by
  compiler

DEFINE PROTECTED VARIABLE AdapterRef AS
pres.serviceadapter NO-UNDO.
34
Agenda

• Presentation Layer in OERA
• Requirements
• Design Patterns
• Implementing the Model
• Implementing the Presentation
• Implementing the View
• Integration with Common Infrastructure
• Summary

35
Looking at class-based ABL code presenter class
CLASS presCustomerMaintenance INHERITS
base.presenterScoped-define REFERENCE-ONLY
REFERENCE-ONLY samples/dsCustomer.i
REFERENCE-ONLY / DEFINE DATASET dsCustomer
REFERENCE-ONLY FOR eeCustomer . / DEFINE
PROTECTED PROPERTY clsbeCust AS
samples.pres.beCustomer NO-UNDO GET. PRIVATE
SET. DEFINE PRIVATE VARIABLE hViewer AS HANDLE
NO-UNDO. END CLASS.

• CLASS inherits behavior from a base presenter
  class
• PRIVATE setter protects setting the value
• PRIVATE VARIABLE protects access to the value
• Also defined as a specific class type where the
  view is realized using class type

36
Looking at class-based ABL code presenter
constructor
CLASS presCustomerMaintenance INHERITS
base.presenter CONSTRUCTOR PUBLIC
presCustomerMaintenance ( ) SUPER ().
clsbeCust NEW samples.pres.beCustomer(). IF
SESSIONCLIENT-TYPE "4GLCLIENT" OR
SESSIONCLIENT-TYPE "WEBCLIENT" THEN DO RUN
CustomerMaintenance.w PERSISTENT SET hViewer.
RUN setPresenter IN hViewer (INPUT THIS-OBJECT )
NO-ERROR. RUN populateData IN hViewer
NO-ERROR. RUN enable_UI IN hViewer NO-ERROR.
WAIT-FOR CLOSE OF hViewer. END.

• SUPER() calls constructor in a base presenter
  class
• Instantiate the Client Business Component
• RUN the view, pass the reference to the presenter
  object, populate data and enable the UI
• The View can be realized as the specific class
  type instead of the ABL persistent procedure

37
Agenda

• Presentation Layer in OERA
• Requirements
• Design Patterns
• Implementing the Model
• Implementing the Presentation
• Implementing the View
• Integration with Common Infrastructure
• Summary

38
The View
/ Included Temp-Table Buffer
definitions /samples/eCustomer.i
/Temp-table defined as REFERENCE-ONLY / /
Local Variable Definitions ---/ DEFINE DATASET
dsCustomer REFERENCE-ONLY FOR eeCustomer .DEFINE
VARIABLE clsPresenter AS presCustomerMaintenance
NO-UNDO .. . . ON CHOOSE OF BtnDone IN FRAME
DEFAULT-FRAME / Done /DO
clsPresenterexitObject() .END. PROCEDURE
populateData clsPresenterfetchData(OUTPUT
TABLE eeCustomer BY-REFERENCE ). END
PROCEDURE. PROCEDURE setPresenter DEFINE
INPUT PARAMETER clsObj AS presCustomerMaintenance
. clsPresenter clsObj . END PROCEDURE.
39
Agenda

• Presentation Layer in OERA
• Requirements
• Design Patterns
• Implementing the Model
• Implementing the Presentation
• Implementing the View
• Integration with Common Infrastructure
• Summary

40
Integration with Common Infrastructure
Presenter class procedures Service Adapter to
CI
Remember inheritance?
CLASS service.ServiceMgr INHERITS Base IMPLEMENTS
IComponentFactory,IComponentRegistry
USE-WIDGET-POOL END CLASS.

• presCustomerMaintenance inherits base.presenter
• Base.presenter inherits base class
• base class defines class variable
  clsServiceMgr
• Using Service Manager class methods, we now have
  access to all other services in CI !!!

41
Agenda

• Presentation Layer in OERA
• Requirements
• Design Patterns
• Implementing the Model
• Implementing the Presentation
• Implementing the View
• Integration with Common Infrastructure
• Summary

42
Demo What have we achieved?
43
In Summary

• Separate concerns!
• Use proven design patterns!
• Follow OERA best practices!

44
Questions?
45
Thank you foryour time
46
(No Transcript)