From: Nathan Andelin
Which part confused you? It will be good to know as a guideline
for explaining EGL to other RPG programmers.
Confused is perhaps too strong a word. It's not like there were conflicts
in the code or structure. I just said the code was a little hard for me
to understand. Regarding your chiding my lack of understanding, I guess I
need to suck up and take it because you answered most of my questions, and
I have to admit that it was my own inattention that caused me to miss the
array declarations in the JSF handler.
Thanks for your response, Nathan. And it was gentle chiding <grin>. I did
answer your questions. It's just that I sense a bias from you against EGL.
Maybe I'm wrong.
When you described dragging and
dropping the arrays onto a form, I had the preconception that they might
be defined in a file used specifically for that purpose. It's interesting
that the visual editor just pulls the array definitions right out of a
file that also includes logic.
I understand your point. And remember, the records ARE defined in an
external part. It's just the array of records that is added.
Interestingly, you can also create a variable on the JSF design page. If
you drag the "new variable" widget onto the page, you are prompted to create
a new variable, which is then added to the EGL code.
But my lack of understanding is also caused by not being familiar with the
syntax. Over the weekend I actually tried to find out what the "package"
statement was for, but was unable to find a satisfactory answer. If a
package is a folder (or directory in the IFS) then what's the purpose of
declaring that in the code module?
I've never enjoyed the "package" statement. It comes directly from Java,
and it seems that the package ought to be determined by the folder the
source resides in, and in fact that Java editor has an auto-correct feature
to fix you package name if you copy a source member into the wrong folder.
There are probably technical reasons that the language designers need the
package designation, but it's not clear to me.
I'm also not familiar with the "plumbing" that you've referred to in so
many of your earlier messages, which makes it hard to place the example
code in proper context. RPG programmers are more accustomed to reading
code from top to bottom to get a proper understanding of the flow and
context of code. Dealing with a tool that breaks code into numerous
configuration, data definition, and logic files is a bit harder to get
your arms around, and more especially when the mainline logic is handled
by an outside framework.
I have to disagree with this statement. RPG programmers deal with multiple
definitions all the time. Every programmer I know understands externally
described files and data structures, which are an EXACT parallel to the
externally described records. In fact, it's easier in EGL because I can
group multiple related structures into a single part and include that part,
and the group multiple parts into a package and include all the parts in a
package.
As to the mainline logic being handled by an outside framework, that sounds
almost like a definition of The Cycle <grin>. Seriously, though, the idea
of an event-driven framework may take some getting used to, but it's
essential for modern graphical applications, and EGL is a pretty painless
way to get there. They can start with simple page-level events, such as
onConstruction, and work their way up to responding to individual keystrokes
using AJAX.
If the programmer needed to change the output based on input from a
previous page, where would you put that logic? Say the application needed
to highlight a row in the table if the amount column were greater than a
certain value specified by the user, or say there was an option to display
just the table, or just the graph, or both based on user input? Where
would you implement that kind of conditional logic?
Almost all presentation issues would be handled through styles. While the
exact mechanics would depend on the business requirements, there are two
basic options. One allows you to define styles based on variables. You can
do this either in the WYSIWYG editor or in the source, much as you would
assign a DSPATR to a field in SDA. Then, you simply fill in the variable at
load time. This technique is typically used at display time. The second
option allows you to programmatically access the document object model and
update a widget's style; this is done in response to user events typically
to report error conditions.
As to visibility of entire portions of the screen, that can be handled
relatively easily using either a style (with visibility=hidden) or by using
the "render" attribute on the JSF widget. The render attribute is actually
quite powerful, allowing you to test variables to determine whether a given
widget is even rendered.
I also didn't realize that JSF was a JSP tag library. I think Microsoft
implemented their version of Web components via separate XML files,
defining component properties. It was interesting to learn that JSF tags
are intermixed with JSP, HTML, and perhaps even with flow control,
looping, and conditional logic in a single JSP file. I can imagine why
you wouldn't want to show that file, and why a visual tool would be needed
to edit it.
This is exactly why I didn't show the code. Here we have a tool that
completely designs the page for you using drag and drop without having to
touch a single line of code, and yet you're complaining about the source
code, even though you haven't seen it.
The point is that you don't have to look at the source to create great
applications, so what do you care what it looks like? Do you care how
convoluted the 5250 data stream is? Do you worry about the MI code
generated from the RPG compiler? I sure don't!
I think your bias is showing <grin>.
Comparing the visual JSF editor in the Workbench to SDA is a bit of a
stretch, because the DDS file generated by SDA is declaratory in nature,
easy to understand, and easy to edit in a basic text editor.
I have to disagree again. I think the analogy is quite good. Give a
subfile to a beginning RPG programmer (much less a Java programmer, which is
a better parallel) and they won't have a clue what it does - I know, I was a
beginning RPG programmer once upon a time. SFLNXTCHG is simple? 99N64
DSPATR(PC) is easy to understand? Pshaw, I say, pshaw!
And here's the $64,000 question: do you use SEU for all your DDS editing?
Most programmers I know would say no.
I'm not sure why you'd target RPG programmers with a tool like EGL. It
seems more appropriate for Java programmers.
Methinks thou doth protest too much. I think that, in fact, EGL is a great
way for RPG programmers to build visual applications. The language is
simple and declaratory, and all the plumbing to get stuff to and from the
web pages is done for them, just like DDS.
To me, any RPG programmer who could program an input-capable subfile would
find this to be child's play. RPG programmers actually like the language,
and in fact IBM is finding a lot of interest in EGL among System i shops.
Joe
midrange.com
