Your building blocks for fast and future-proof development Koen Verbeeck Senior R&D Engineer...
-
Upload
ethel-mosley -
Category
Documents
-
view
215 -
download
0
Transcript of Your building blocks for fast and future-proof development Koen Verbeeck Senior R&D Engineer...
Your building blocks for fast andfuture-proof development
Koen VerbeeckSenior R&D Engineer [email protected]
Evy De BlockR&D Engineer [email protected]
• Located in Puurs, Belgium
• Unique team of Progress OpenEdge Developers– Each member having +15 years Progress OpenEdge
experience
• Focus on:– Development Frameworks (Desktop, Mobile, Web)– Migration Strategies– Enterprise ERP Solutions
• Serving World-wide customer base– Each having unique requirements
About BinteQ
• Grown up using Progress OpenEdge
• Made the switch of:– “Framework user” (Financial applications) – “Framework Developer” (technical scope)
• Internal Nick-name is “Sherlock”– Because of her unique “in depth” research & debugging
techniques
• Worked with Progress OpenEdge on:– Windows,– Unix,– …
About Evy De Block
• Long history with Progress Development– Since 1987– Progress version 4.2 (first release using “overlay frames”…
)
• Worked with Progress OpenEdge on any possible platform– Windows, Unix, VAX/VMS, OS/400, Motif, …
• Specialized in Development Frameworks for Progress:– Windows Desktop Applications– Mobile Apps– Web Development
About Koen Verbeeck
① Progress Evolution & Partner Reality② Principles③ Classic ABL vs OO ABL④ Our goals & approach⑤ Demo’s⑥ Summary⑦ Q&A
Agenda
1. Progress (R)EvolutionSince OpenEdge 10.x (and continued in OpenEdge 11.x):
• Object Oriented Programming (OO ABL)• Support for Modern .Net Controls (GUI for .Net)• Visual Designer• ProDataSets• Structured error handling• 32/64 bit support• IPv6• New SOAP parser• …
Progress OpenEdge Partner Reality• Existing Progress applications since Progress v4,
v5, v6, v7, …• Mature and Rich applications• Decades of man-years of work• Huge investment for full-rebuild (not feasible)• Technology: Client Server applications, extensive
use of:• Full procedural code• Includes• Shared Variables• ActiveX Controls to spice up UI• …. Does this sound familiar ? How to deal with this ?
Why Modernize ?
Business reasons:• Safeguard Competitive Market Position• Safeguard application value
Technical reasons:• (R)Evolution won’t stop• Need to motivate young talented developers
o Require Modern Development Studioo Object Orientation is a must, procedural is “weird”
• Interface with modern external systems• Support new OS’s• …
• Make Legacy Applications OpenEdge 11 ready– Use Visual Designer– Use OO ABL, DotNet Controls, …– Modern Look & Feel
• Foundation for New Applications using New Technology
• Improve performance• Migration for existing applications:
– Re-use Application Layouts– Replace ActiveX Controls with DotNet Controls– Code level compatibility for current applications
Our Goals
• Manufacturing Principles• Learn and explore new OO ABL• Design & write new Components• Redesign & rewrite framework (1 time effort, done
now)• Design & optimize Conversion Tool• Convert application(s)
Our approach
• Design process– Raw materials– Design
• Manufacturing process– Components– Standards– Quality Control
• Distribution / Deployment• Customer Care
2. Manufacturing Principles
Is software development any different ?
• Requirements• Predictable Time• Predictable Quality• Predictable Cost
Software Development
This is what Fly2Pro is all about !
• Application Developers (focus on what to build, not how to build it)
• Framework Developers (R&D, search how things work)
Different Type of Software Engineers
Classic ABL OO ABL / GUI for DotNet
• Programs (.w & .p) • Classes (.cls)
• Procedures & Functions • Methods, Events, Properties
• Windows• Frames
• Widgets• Control Frames
• OCX Controls
• DotNet Forms• DotNet Controls (Infragistics &
MS)
• App Builder • Visual Designer
• … • …
3. Classic ABL vs OO ABL (Different Worlds)
• ABL Windows & Frames cannot “contain” DotNet Controls
only DotNet Forms can host DotNet Controls
• DotNet controls cannot simply “replace” OCX Controls
OCX controls reside in the widget chain: ABL Window
Control Frame
OCX ControlDotNet Controls reside in the DotNet object chain
DotNet Form DotNet Control
What is NOT possible
• Use object-oriented ABL to access .NET objects • Data binding between ABL data sources and .NET
controls • Write ABL event handlers for .NET controls• Embed “ABL Windows” into DotNet
“WindowContainer”
Concrete:– Classic ABL (.w & .p) can access Methods in OO ABL
Classes (.cls)– Classic ABL procedures can “subscribe” to DotNet Events– Embedding explained
Integration Possibilities
Re-use Layouts: Window Embedding
ABL Window
OCX Control
ABL Frame & Widgets
DotNet Form
WindowContainer
• ResultsBoth ABL Program .w as well as DotNet Form .cls are
active in memoryABL Window is no longer visible, only frame(s) + widgetsABL Window still exists (hidden / view still has effect)ABL Window is embedded into WindowContainer Control
on .Net Form
Window Embedding
ABL .w DotNet Form
Correct “destroy / dispose” order of both is essential !!!
Embed native DotNet Controls in ABL User Controls
– To be used in “new” DotNet framework– UI only, no data access– Full OO ABL using Visual Designer– Standerdize 1.000’s of properties– Hide Control complexity for Application Developer– Open for future change
• Infragistics Ultra Controls• Telerik RAD Controls• Other…
Design New User Controls
Essential Controls:• Grid Control• Command Bar / Ribbon Bar• Tabstrip Control
Modern & More advanced Controls:• Scheduler / Calendar Control• Docking Pane Manager Control• Property Grid Control• Charting Controls• ….
ABL User Controls
• Re-design framework– Split UI & Logic– Migrate Logic to OO classes– Invoke new DotNet User Controls– Slim down legacy framework
• Keys to success– New controls don’t overlay existing controls– No double UI code to execute
Integrate Old & New World
Faster application performance !!!
Co-existence of Classic ABL & OO ABL (New Code)
• Controllers– Data Access for UI Components, pass results in Temp-
tables– OO ABL– Can execute Local or on AppServer
• Proxies– Instantiation of Controller (local or AppServer)
• Examples– CommandBarController (data access to build
Menubar/Toolbar)– SecurityController (data access for security
etc)– MenuShellController (data access for Menu Shell)– MenuShellProxy– SecurityProxy
New framework objects (besides User Controls)
Clean integration using Published Events
ClassicABL .w
DotNet Form
Embedwd ABL Window
DotNet Control
WAIT-FOR System.Windows.Forms.Application:Run(mainForm).
FireEvent
sSubscribe
GridCtrl
Publish Event
Time to show something
5. Real Life example
Ribbon Bar
Grid Controls
Docking Panes
ButtonBar Controls
TabStrip Controls Split Container Legacy ABL
Frames
More examples: Scheduler / Calendar
Ribbon Bar
MultiView Calendar Control Docking Panes
Legacy ABL Frames
• First impression of your “new application”– Showcase for new DotNet UI
• Completely new UI Code– Visual Designer– OO ABL
• Modern interface: – MDI Interface: fast switching, organized desktop– TileView– Round buttons– Dockable Favorites-, Recently Used-, All Programs panes– Locate programs using Search
Menu Shell
Menu Shell Showtime
Tile Menu Shell
Automated Migration• ConvOE11 Tool can be customized / extended• ConvOE11 Tool can handle most (+90%) of the programs• Progress Browsers automatically converted to DotNet
Grids• Some “special programs” will require manual attention
Real Life statistics• Migrated Enterprise class ERP application (now Intl.
deployed)• + 4.000 programs, +2.000 forms• about 3 months• Migrated several partner applications as well in very
short time
Short Term Migration
Thanks to Fly2Pro, R&D has been done !!!
• Compatibility• as far as it can go
• New modern technology• OO ABL• DotNet• OE11• Future proof for new platforms
• Modern UI• Modern Grids• Ribbon Bar (or any other commandbar)• Open for any .Net control (e.g. advanced planning boards)
• Short Term Migration• ConvOE11: Manual labor can’t beat automated processes
6. Summary Fly2Pro
• Short Term Migration• ConvOE11: Manual labor can’t beat automated
processes
• Create New applications faster• With consistent quality thanks to the well designed
components
• Soft learning curve for developers• Designed to let ABL developers make the OO step
“easy”
• Improved application performance• We’ve seen the difference
• Predictable time, cost and quality• We’ve learned from the manufacturing principles
6. Benefits Fly2Pro
7. Any Questions ?