We will just have to agree to disagree. Adding Java to an RPG programmers
environment simply isn't as easy as you make it out to be (in my
experience). Like I said (paraphrasing here), if the thin JSP layer simply
received the RPG data from the controller and built the screen based on it
then this architecture is much simpler. Of course that would warrant the
passing of meta data with the data, but done right could produce a pretty
cool framework (one that I am working on in the desktop environment) that is
easier to build initially and maintain after the fact.

Aaron Bartell
http://mowyourlawn.com



-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Joe Pluta
Sent: Monday, June 04, 2007 11:09 AM
To: 'Web Enabling the AS400 / iSeries'
Subject: Re: [WEB400] Windows vs i5/OS as a platform

From: albartell

If you were able to take "configuring" or mapping out of the Java code
(because really it serves a simple purpose) and allow it to just know
how to render the data it is passed, well then this architecture would
be just fine. But it's the fact that a programmer has to touch a
piece of data twice in the UI layer when using Java vs. once when
using RPG.

You have to touch it twice anyway in the green screen, sometimes three
times. You have to add it to the database, then add it to your display
file, then add it to your business logic.

I'm sorry, but complaining about adding literally THREE LINES to your Java
code (the definition of the field in the data bean, and the conversion code
in the servlet) just seems like nitpicking to me.


Back to the contradicting. I am strictly talking about server side
technologies and you and I both know that Javascript doesn't compare
in complexity to Java on the iSeries (or any othe platform).

This is the entire code needed to add a field using completely handcoded
Java (it's even easier with EGL):

Add THIS to the bean (makes the field available to the JSP):

String myNewField;

Add THIS to the data structure definition (converts between EBCDIC character
data and a Java String):

new AS400Text(30),

And then finally add THIS to the logic (moves the converted field from the
data structure to the bean):

bean.myNewField = convertedData[15];

Yes, I hard-coded the field type and size and the ordinal position of the
field in the data structure but technically, all of this code could be
generated from an externally-described data structure. Add one more line to
get the field back to the program for an input-capable field.


Most of the time people
simply aren't using Javascript as much as the highest end sites out
there (obviously AJAX is catching on).

Simply loading a dropdown and then marking the selected value takes more
code than what I outlined above, unless you're generating the HTML for the
combobox in your CGI program, one little scrap at a time.

And Ajax is quite a bit more difficult than a simple combo box.


I'm sorry, but this drum beat that Java is too hard but JavaScript is
not
is simply indefensible.
We'll have to differ I guess. I just don't see the two being the same
- in use or function.

No, I agree! Simply converting data structures to Java beans is as simple
as you can get. JavaScript is a pain in the rear (and it's much harder to
debug).

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.


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.