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



Yes, you have a much thinner UI than most, but it still requires coding for
each new screen and field added right? If that is true then you need two
knowledge sets to create/modify a screen/application. A programmer could
just as easily code an error in the Java logic/mapping that is reading from
the data queue as they could in the RPG side, and it wont be blatantly known
where it is until you dig in.

That is where having a single language shines (which I believe you agree
with, but you don't put enough weight on the fact that Java isn't a
lightweight language for many of the people that would have to use it in
this architecture). Yes you have to do HTML, CSS, and Javascript in both,
but in a RPG CGI scenario you only need to know RPG as the primary
serverside language, not RPG AND Java.

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 9:49 AM
To: 'Web Enabling the AS400 / iSeries'
Subject: Re: [WEB400] Windows vs i5/OS as a platform

From: albartell

What you are describing is exactly the reason I try to steer people
away from glam and glitter technologies like Java and .NET as a way to
modernize their existing RPG apps. Sure you can do things easier on
the front end, but you lose a lot of the backend stuff that will cause
major headaches for maintenance programmers and all of a sudden it
takes three people to debug a problem on your web site.

Oh poo, Aaron. <grin>

As I said in a previous message, you can use any front end (Java, PHP,
Python, even .NET) provided your back end is solid. In fact, in a proper
design, you shouldn't care what your UI looks like; it ought to be entirely
transparent to the business logic.

The converse of that is that you ought to be able to test the bejeezus out
of your UI including all sorts of end-point conditions just by writing
simple test servers. You ought to be able to make sure that all the UI code
works before you ever even hook it up to a server.

In the case of the web, the part that runs on the server, the generation and
presentation of HTML, really isn't that hard to debug. Call a server, make
sure the right HTML is getting sent out. You can even automate a lot of
that using something like WebRoller.

In reality, the hard part of the UI testing in the web is the JavaScript and
CSS and all that happy crap, and that's no easier to debug using RPG-CGI
than it is using Java or any other presentation methodology, since the code
to be debugged is running on the workstation.

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.