|
Hey Bob! I live in the US - lexicon invention is part of the deal!! While your points are valid, they do not seem to apply to the majority of the server-based tools on the market. You may be taking a new approach, but the majority of currently available server-based refacing tools simply intrude on the code or the data stream, take the same green screen data that was originally being sent in a 5250 format, and redisplay it in an HTML format. The original application still operates in the manner in which it was designed - it thinks it is having a conversation with a terminal. Using a simplified OSI model for example (where there are a presentation layer, application layer and database layer for the development model) most refacing tools simply integrate to the presentation layer. Without reengineering the original application to remove the presentation layer - for example, let's re-write all our interactive RPG withOUT a display file - we are still screen scraping the original display file screen conversation. I assert that the diversion of the data stream at an earlier point than a telnet connection is still screen scraping. If we continue to think that our legacy applications are pigs, then we will continue to need lipstick, plastic surgery and beyond. When our legacy applications are rewritten so the presentation layer is separate from the application layer and the database layer, then a server-based presentation layer will be a powerful tool. Until that industry wide reengineering takes place, the lexicon of the 80s will remain in the marketing vernacular - pig, lipstick, screen scraping, etc. and screen scraping will survive. Bob, you were the one who encouraged me to write modular code in 1983 on S/38. It took me some time to understand, but all my applications were built modular from that moment. One exception (which rears its head in this moment) has always been a display file - an INTEGRAL part of iSeries coding techniques. I would love to see a hand-written iSeries application that utilizes display file server programs, but alas, they are simply toys for some of us uber-techies - mostly pigs with wings. Application development on the iSeries does not have the modular structure to allow us to truly separate the presentation layer with a server. Without radical application reengineering, the concept of a set of characters in row 2, column 3 (3 or 4 long) is inherent to our development environment, platform and even our psyche. Until that day, we have a data stream to deal with. Screen scraping pervades. I say, give that pig some wings - and at least let it ~look~ like it is flying! Trevor ----- Original Message ----- From: "Bob Moore" Subject: RE: webfacing and competing products > Trevor, > > Screen-scrapers > > To integrate with host applications from non-standard client systems, > developers commonly use text - > filtering systems that process the screen-by-screen results of terminal > interaction. These systems are > generally called screen-scrapers because they have to extract meaningful > data from a screen's worth of > undifferentiated information an inefficient method at best. > Screen-scraper interfaces are some of the least > robust interfaces possible because of the many assumptions that have to > be made when determining what > data from each screen is important. Very little can be done to catch > errors or provide for unusual > situations with a screen-scraper because the interface definition is so > arbitrary. If the third through fifth > characters of the second line of the fourth screen are used to indicate > the three-digit product code of a > widget, for instance, the entire interface could be thrown off by having > four-digit product codes come into > use after the interface is developed. Processing application data post > client receipt on-the-glass is too > little too late. The light weight screen-scraper approach does not allow > server based transformation where > application interfaces and system data are current, available and known. > > Familiar? Pigs cannot as far as I know fly, new lipstick look or no! > > Inventing one's own lexicon does not alter reality! > > Bob Moore
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 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.