|
The problem with function keys in Web applications is that browsers assign default behaviors to them. There's no way that I know of to disable default behaviors, except in Internet Explorer. For users who have standardized on Firefox, or Linux, or Mac OS workstations, the JavaScript you use to trap function keys won't work the way you want. On the other hand, there's no problem having JavaScript monitor for accelerator keys, like Alt-1, which could be used to submit forms. If you decide to front-end existing green-screen applications with an HTML interface, be prepared for quite a bit of extra CPU overhead. A typical 5250 data stream is about 1-2 kb in length. A comparable HTML stream may be 10-50 kb in length. Some Java interfaces consume 30-50 times more CPU cycles to produce green-screen screen equivalents in HTML. Any savings in high-priced "interactive" CPU cycles may be gobbled up by additional, although lower-cost batch CPU cycles. Given enough concurrent users, the decrease in performance will be felt. One problem with CGI interfaces is the load associated with new program activation. Most developers use "named" activation to solve this problem, but may unwittingly unleash a different problem. When say 100 users request the same resource at the same time, the HTTP server will attempt to load 100 instances of the same application, and since application resources are scoped to named activation groups, they aren't released until the HTTP server is shut down. That's probably fine if you're deploying only a moderate number applications, but will become a problem as the number of users and applications grow. It's like a built-in memory leak. Some developers suggest restricting the number of available CGI threads as a stop-gap measure, which is less than ideal, because it's a global setting that applies to all applications running under the HTTP server, and doesn't scale well between low and high-peak usage. OO languages like Java may consume a lot more CPU and memory than native languages in the case of small workloads, but as the number of users and applications increases, the more efficient J2EE architecture is, in comparison to standard CGI, because no more than one instance of a Servlet is running within the Application Server at a time. Scripting interface like JSP, ASP, RSP, RPGsp, PHP, or Net.Data, are seductively simple when getting started with Web applications, but can get very unwieldy as the number and complexity of applications grows, unless you find an effective way to separate UI code from program logic. Scripts are great for simple applications, though. Using standard program models is critical for enterprise class development. It's much easier to adapt an existing model to a new subject than to rewrite a new application from scratch. One problem with "templates" that come with popular code generators is that they're quite primitive, providing little more utility than say DFU, or WRKDBF. It's hard to justify GUI point and click interfaces unless you're providing users with additional functionality, or streamline access. Packaged templates normally aren't very adaptable, and may require mastering an intermediate scripting language in addition to the generated language. Enterprise class development raises a lot of architecture questions. Should applications run under generic or specific user profiles? Is there a need to access many applications from a single sign-on? Do different users need different menus, and different access rights? Should some applications expose "maintenance" capabilities to some users while "inquiry" to others? Do access rights need to be configurable on a role by role basis? Is there a need to support multiple runtime contexts such as different HTTP or J2EE application servers, or provide access to production vs. development vs. test data, or provide access to different versions of the same application? Are physical files segmented into members which provide snapshots of the database, perhaps by fiscal year? Do certain users get access to certain records only, and do record filters need to be configurable according to user roles? Just some things to consider. Nathan Andelin --- Mary Koetting <Mary_Koetting@xxxxxxxxxxxxxx> wrote: > We're a small shop (5 RPG/COBOL programmers) with an > I5 Iseries (Apache > server) and we're researching a new tool to write > web applications and would > appreciate any input you have on the subject...we > have some visual RPG > experience and have a couple of web applications > using Brad Stone's eRPG. > > > > There will be forms entry, maintenance, automatic > emailing, real time > updating with about 100 users and it would use at > least 30 files...would > also love to have something in place that would > capture the form as a > scanned object and pass it to an Oracle > database....we spend a lot of effort > feeding forms to a scanner. Don't know if this is > even possible but would > save a lot of work. > > > > We want to be able to use function keys to move from > one screen to another. > > > > We would like to get cut down on our interactive > workload and also need to > keep track of who does what...we have a lot of PHI > information (HIPAA) so we > have to know when, how and who changed the > information. I've seen a little > of the Nexus Portal and I'd like to know if anyone > has experience with it > also. > > > > We greatly appreciate any and all guidance...thanks! > > > > > > > > Mary Koetting > > Senior Programmer Analyst > > Missouri Consolidated Health Care > > 573-526-2856 > > > > -- > This is the Web Enabling the AS400 / iSeries > (WEB400) mailing list > To post a message email: WEB400@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: > http://lists.midrange.com/mailman/listinfo/web400 > or email: WEB400-request@xxxxxxxxxxxx > Before posting, please take a moment to review the > archives > at http://archive.midrange.com/web400. > > __________________________________ Discover Yahoo! Have fun online with music videos, cool games, IM and more. Check it out! http://discover.yahoo.com/online.html
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.