Nathan,
I am a complete noob with EGL so you can take what I say with a grain of
salt. Here is an example of what Joe is talking about (I think):
There is the usual setup for building a project in EGL. Creating a
project just takes a wizard which walks you through the steps of setting
the project up. One of the steps is to identify the database (schema or
library) that you are working with and what tables you will use. The
wizard generates a "standard" set of library functions that you can use
to access the data. If the table was called customers, you might end up
with a GetCustomer, GetCustomerList, updatecustomer, updateCustomerList,
etc. Basically, it generates a standard set of I/O routines that deal
with single record access and multiple record access. In reality, under
the covers, the customer records are mapped to an array so you can load
one, or many with a single DB call. These are generated automatically
for you and you can add or modify what is there. The "plumbing" of the
I/O, in and out of the array, is handled for you.
So basically, out of that one wizard step, you end up with an array of
data elements and a set of functions relating to I/O that are based on
the table design. Those are part of an overall component structure that
is available to you in the framework.
So you then create a .jsp page, again using a wizard, choosing a
template "theme" that basically lays out the initial page for you. That
is what DW would do for you as well: create a "blank" page based on a
template you designed. But, and here is the cool part, when you have
the design view in front of you, you right click on the page and take
the option to Edit Page Code. Now, rather than seeing the HTML (which
you could see through another view) now you have an EGL file that allows
you to define the data elements and functions you want to have available
in your page. Using the EGL language (and very little of it, by the
way), you define those elements and functions.
So let's say you have a customer record and want to retrieve a list of
customers to a page. Well, remember that the wizard already created the
array and the base functions for you (you haven't coded anything yet),
so your EGL code might look like this:
--------------------------------------------------
package jsfhandlers;
import eglderbyr7.StatusRec;
import eglderbyr7.access.CustomerLib;
import eglderbyr7.data.*;
import com.ibm.egl.jsf.*;
handler allcustomers2 type JSFHandler{onConstructionFunction =
onConstruction, onPrerenderFunction = onPrerender, view =
"allcustomers2.jsp", viewRootVar = viewRoot}
viewRoot UIViewRoot;
customerArray Customer[0]{maxSize = 100};
status StatusRec;
// Function Declarations
function onConstruction()
CustomerLib.GetCustomerListAll(customerArray, status);
end
function onPrerender()
end
end
----------------------------------------------------
Even most of THIS code was generated without typing. The only thing I
changed was to add the customerArray (of Customers) with a max size of
100 and reference the function I need in onConstruction.
Then in the onContruction function (which is called when the page loads
and is automatically included) I just referenced the function
GetCustomerListAll (that was created for me) in the CustomerLib (which
was created for me). You can see where the components come from by
looking at the import statements. Again,this stuff is generated for you
based on your selections.
OK. So we have a function and some data elements that are now available
to be referenced by the page, since we are editing code for the page.
We save our changes and switch back to the page designer. Now, as
components, I have a customerArray object available to me. If I had
created other functions, like a loadCustomers function, I would have
that available as well. The functions you create are available as
"Action" components in the page designer. When actions are dropped on a
page they become buttons by default.
Now, all I have to do is to grab the customerArray object and drop it on
the page and it presents as a HTML row in the page with each field
listed in the order in which they were created in the array. I can
choose to omit fields and make some or all read only (I'll learn more
about designer options in a week or so). But, in any case, you drop the
array onto the page and you immediately have customer record laid out.
(again, reformatting the base page is something that will be in the next
workshop).
This example really has no function beyond just listing customers when
the page is rendered. So it is pretty easy. But the "drag and drop" is
the cool part. You code data elements and functions as part of the page
design. Those functions and data elements are available to the page at
that point. I probably typed less than 100 characters to get a customer
listing. Creating a single customer maintenance page is just as easy:
code a customer record as a data element in the page and reference the
getCustomer function that has already been created in CustomerLib and
then drop the customer record on the page and use the onConstruction
function to get the record. Need to pass the customer ID as a
parameter? No problem, the page already has a reference to it and you
can pass it to the function.
I don't plan to give you a full tutorial but the basic concept is this:
Each jsp page, beyond the usual HTML element objects that are available,
also have a reference created to a set of data elements and functions
that you can add to and modify. How the references are maintained is
the magic of EGL. It just works.
It would be like you being able to associate your RPG program with a
Dreamweaver page design so that you could see all the record formats and
variables that are in the RPG program and just drag and drop them into
the Dreamweaver page. And, even better, those relationships are
maintained as you modify your RPG code and the page. This is very cool
stuff.
You need to download the trial and take 1 hour to walk through one or
two examples. With your background you'll see the power in it in a
heartbeat.
Pete
Nathan Andelin wrote:
Joe Pluta wrote:
Have you tried dropping a field or a record or an array of records
onto a web page? The fact that
the data from the EGL fields is automatically passed
to the page with no work on your part, that's what
I find lacking in any tagging approach...
Joe, you seem to have a misconception about HTML templates used by
CGIDEV2 and similar toolkits. They're much different than the "tagging
approach" used by Java frameworks. But you can do the research
yourself; I just mention it as an aside.
I really wanted to ask about the "no work on your part". What about
defining EGL records? And what is it that automatically binds them to
fields on the page?
If an RPG program uses templates, you'll see code like the following
that inserts field values into a page:
rptVarSet('type':%trimr(codetype));
rptVarSet('desc':%trimr(typedesc));
Notice that the API also allows the %trimr() function to be called, but
it could just as well be any other type of data formatting, or even
decrypting the field before outputting it. Or if the user is not
authorized to see the field, an empty value could be returned. Or the
statement could be conditional. This is quite powerful on the one hand,
and perfunctory on the other. It's the type of code you could do when
your half asleep.
And if it's just too perfunctory, you could write a procedure to
automatically map fields from an externally defined data structure to
fields on the page with a single function call, which is what the folks
at cnxcorp did in their Valence RPG toolkit.
Nathan.
midrange.com
