× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I told myself I wouldn't respond, but you draw me out :-)

Just so I can fully understand the statement you are making. You think that
implementing a thin Java servlet that is different for each screen holds the
same level of difficulty as Javascript? (rhetorical)

Hee hee! And you accuse me of stretching. Java trouble tickets? I have
never had a Java trouble ticket because of a thin JSP architecture. Of
course, you do need to train them to handle CSS trouble tickets...

You were stretching things I said so I felt the need to correct. To say
that a company implementing Java servlets that run on the front of every web
app wouldn't have a trouble ticket related to something wrong on the Java
end is just foolish-ness on your part. If you arguing over semantics of
calling it a "Java trouble ticket" I don't know what to say other than you
are looking to argue for the fun of it.

re-work your CMS to facilitate Java objects,
Yet even with an RPG-CGI approach, you have to make your CMS work with HTML
fragments. And Apache configuration files. And CSS files.

Just so I can fully understand the statement you are making, would you say
that deploying Javascript, which is no more than a text in a file, is
similar in complexity to deploying Java? (rhetorical)

If your argument is that multiple languages is harder than one, of course
you're right.
There we go! Bingo! That's what I was looking for!

And if you include the fact that CSS and HTML are both additional languages
(and non-native ones at that), that number jumps to pretty much 100%.

You know what I mean.

<joe>
You may disagree, and that's where we can leave this discussion. In my
opinion, adding one more language to the mix is not too onerous. You think
it is. I also think that anybody can learn enough Java to write thin-veneer
JSP, and you don't. Cool.
</joe>

Like I said in an earlier thread, each added technology should have an ROI
put on it. Do I think RPG programmers can learn your model - you bet. Do I
think they can write great applications with it - you bet. Do I think it
will take them longer to do it with the thin JSP vs. RPG - I can guarantee
it (and you also agreed). I don't even know what you are fighting with me
on anymore.

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

From: albartell

Gotcha. So you're basically saying that if another language requires
any
learning, then you don't want it in your environment.

That's a big stretch of what I said. You are just fishing for argument.

Nope, I'm just tired of you saying how hard Java is. Java is not hard. If
you use JavaScript, you can use Java. It's just plain silly.


You need to weigh the fact that you will need to maintain a servlet
engine (i.e. Tomcat/Websphere),

Yes, it requires work. RPG-CGI requires knowledge of Apache! And HTML!
And JavaScript! It's just a matter of degree.


knowledge of Java IDE editor, knowledge of Java in general, train your
helpdesk to take Java/Tomcat trouble tickets,

Hee hee! And you accuse me of stretching. Java trouble tickets? I have
never had a Java trouble ticket because of a thin JSP architecture. Of
course, you do need to train them to handle CSS trouble tickets...


re-work your CMS to facilitate Java objects,

Yet even with an RPG-CGI approach, you have to make your CMS work with HTML
fragments. And Apache configuration files. And CSS files.


Introducing a new language that is not native (i.e. RPG, CL, C, COBOL,
etc)
to the i5 can double your work in many areas, and being that this
model is tightly coupled, the distribution of Java and RPG changes
needs to work quite seamlessly including if the install fails it needs
to be appropriately backed out.

If your argument is that multiple languages is harder than one, of course
you're right. But if your argument is that easier is better just because
it's easier, then you're just plain wrong.

While Java/JSP may not be the right architecture for some applications, it's
not because programmers have to learn another language. I would hazard a
guess that at least half of people on this list who are web enabling their
systems are using more than one language. And if you include the fact that
CSS and HTML are both additional languages (and non-native ones at that),
that number jumps to pretty much 100%.

So once we're past the idea that more languages are bad, we're back to the
"Java is too hard" complaint. However, if you consider JavaScript
acceptable, that pretty much removes the Java is too hard argument.

You may disagree, and that's where we can leave this discussion. In my
opinion, adding one more language to the mix is not too onerous. You think
it is. I also think that anybody can learn enough Java to write thin-veneer
JSP, and you don't. Cool.


Concerning your comments about EGL - does it use PCML to interface
with RPG? I think I asked this before but I don't remember the answer I
got.

Not as far as the programmer is concerned. It uses the toolbox to pass
records as data structures.

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.