|
> From: Jim Damato > > What exactly are you looking for in a migration path? Client > server and web > software architecture is so different and so much more complex than > traditional AS/400 programming. It's like writing a book and > expecting your > word processor to provide a migration path to a movie. It's so easy to > blame IBM, but the expectations are so unrealistic. ------------- This is where I disagree. It depends on what you mean by "traditional" programming. If you mean 1980's style monolithic programming where the business logic and the UI are inextricably intertwined through the use of common indicators implemented via 30,000 line programs, then yes indeed, you will have difficulty moving to any other UI, but that situation exists regardless of your toolset. If, on the other hand, the code adheres to the trends of the last decade or so, with modular programs where the user interface is separate from the business logic, then it's quite easy to move from a green screen to a UI independent environment. If, as is likely, your code is somewhere in the middle, there is a logical, simple path. 1. Mechanically separate your business logic and user interface 2. Wrapper your interface within an intelligent messaging architecture 3. Rewrite the sections of code that need performance improvements 4. Remove the wrapper for the rewritten sections It's simple. Part three is time consuming, of course, but not that difficult, especially when you've used part two to provide a zone of change where you can work without undue time pressures. All programming that interacts with the user is a series of transactions between the user and the host machine. There is nothing fundamentally different about the web interface and any other interface if you've designed a solid client/server infrastructure. Structuring and codifying the user/host interaction leads naturally to exactly that sort of robust, flexible client/server environment. The very best, most-used websites today, such as Google or Travelocity or Monster.com, have very simple user interfaces that are really no different from anything we're doing with green screens. Get data, send to server, show results. Most of our green screen applications can be adapted to that paradigm quite easily. Right now, my toolset converts a green screen program directly to an HTML-capable application in a few seconds. Joe Pluta www.plutabrothers.com "Adapting Tomorrow's Architectures to Today's Applications" +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2025 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.