Re: Impressions of EGL - Part Duex

Joe wrote:

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.

But why loose this feature? Because there are problems with it? Because our
apps don't scale / perform badly? Why the move to client/server (a browser
app is nothing more than a client/server app).

I don't dismiss client/server and browser apps. But i find it interesting that the
rest of the world uses the browser to solve the deployment problem. We dont
have this problem. In fact, on our platform we have zero issues with that. Even
less than a browser app. Because our 5250 apps execute in a simple, robust
and *predictable* environment. They are built with one single language. Not
like a web app, where we have the server environment and language(s) to deal
with and the client environment / languages. And these environments have
grown to be what they are now. The client environment (the browser) was also
not meant to be used like this. It was meant (and still is) to be used to present
documents. But as documents get more dynamic (AJAX) the distinction between
"application" and "document" becomes more blurred.

There is a place for web apps. Apps for which a document oriented interface
is appropriate. A typical example would be a report, on which you can drill
down by clicking on a link. And sure i would use EGL to build it. I didn't use
EGL for now, but i know that to build a web app with the "i" as the server, EGL is the
way. No doubt.

But all this complexity just to replicate what we already have, with desktop apps, i.e.
a "rich" user interface.

Like i said, i find it interesting that the rest of the world uses the browser to solve
the deployment problem. They already have "rich" apps, i.e. the traditional client
server approach.

But we are using EGL (or web apps in general) to solve a completely different
problem. We use it to easily build an "i" app with a modern user interface. And if
we do, we loose those important features of our platform, simplicity, robustness
and predictability.

Date: Sun, 25 May 2008 23:01:10 -0500
From: joepluta@xxxxxxxxxxxxxxxxx
To: web400@xxxxxxxxxxxx
Subject: Re: [WEB400] Impressions of EGL - Part Duex

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
. 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

--
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.

_________________________________________________________________
Probeer Live Search: de zoekmachine van de makers van MSN!
http://www.live.com/?searchOnly=true