Aaron Bartell wrote:
1) Going back to one of my earlier posts today I mentioned the fact that
many of these drag and drop tools don't implement paging of a large data set
efficiently (i.e. they copy the entire dataset into a Collection and page
through that Collection in memory vs. going back to the database and
resequencing or getting the next set of records). Could somebody show us
whether or not EGL gives us efficient paging out of the box? BTW, the same
would need to be implemented in RPG-CGI, and obviously RPG-CGI doesn't have
it out of the box either.
Well, let's see if we can surprise everyone with a civl discourse <grin>. You only have two questions about EGL and they're both very good questions. This first one is a matter of how you load the array, and it's really more of an issue of SQL vs. ISAM. You can't just load the contents of a result set into an array and expect it to perform. So typically frameworks that only know SQL lack in this regard. With EGL, you can use either a scrollable cursor or thanks to its stateful connection capability you can call an ILE program and have it do the paging, much as you would in a normal subfile program.

2) Does he framework allow for the same screen sequence to be entered into
from different initiating screens? Let's say you have an "Advanced Customer
Search" set of screens that you wanted to access from both order entry,
customer maintenance, and customer service. In traditional RPG it was as
easy as calling the "Advanced Customer Search" screen with a set of parms
and hitting F3 when you wanted to back out to the previous screen. In JSF's
out of the box approach (and I don't know if EGL suffers the same fate) you
essentially hard code the next screen to be displayed based on your
faces-config.xml file which essentially means you can't just hit F3 and go
back up the call stack because there isn't one. Instead I had to spin my
own wool again to make this work (and even then I don't feel I was entirely
successful).
As you know, this is a fundamental limitation of every framework. The problem is the lack of a program stack, something missing in every browser-based technology. Even RPG-CGI has problems with this. You may remember that I designed such a stack into my thin-client design, but it really doesn't mesh well with the rest of the browser-based world. In the browser world there aren't "call levels" in a "stack"; browser pages simply don't return to the caller.

I don't have a good alternative, either. This may be one feature we lose in the move to client/server programming. The idea of a rigid conversation flow where panel sequence is determined by the server may become a thing of the past, even though it has some really good points. Instead, what we see is a more client/server approach where an extended UI widget (a wizard, for example) walks the user through an entire sequence of user input stages, and then the entire operation is attempted at once by sending a message to the server.

That widget, then, can be embedded in any page using some sort of mashup technique. So, if you need to send an email, for example, you simply invoke the email widget, either in a popup dialog or in an embedded frame in your application. The point is that your particular requirement may simply not be applicable anymore.

By the way, although there is a faces configuration file, EGL allows you to very easily invoke any page you want using URLs, including passing parameters. As far as I can tell, your deeplinking requirement from our earlier conversations is met by EGL. But that still doesn't allow you to effectively "call" one or more browser pages and then magically return to the calling page, especially if the stack is more than two call levels deep.

Joe


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.