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



Well put Scott.


Jim Cooper
Program Coordinator
Lambton College
jim.cooper@xxxxxxxxxxxxxxxxx
519-542-7751 ext. 3219


________________________________________
From: web400-bounces@xxxxxxxxxxxx [web400-bounces@xxxxxxxxxxxx] on behalf of Scott Klement [web400@xxxxxxxxxxxxxxxx]
Sent: Saturday, December 08, 2012 2:37 AM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Web Enabling Applications

Hello,

I hesitate to weigh in on this discussion, as it has all the earmarks of
a long and unproductive "holy-war" type of discussion. However, I'm
going to be optimistic and hope that doesn't happen, and put in my 2 cents:

If you look at web development 5 years ago, most web apps were HTML that
was emitted from server-side programs. Tools like Net.Data were good
for that sort of approach (though, Net.Data didn't catch on) Popular
tools were perl, PHP, ASP and JSP. Within our community, CGIDEV2 made
it easier for RPG to do the same things that PHP, ASP, JSP did in other
languages. (Commercial products like RPGsp also did this nicely.) These
would all emit HTML, with just some variables inserted from business
logic, and that business logic tended to be coded inside the same script
along with the HTML.

This paradigm has really changed. As others have said, emitting HTML
from the server side is passe in today's world.

Server side programs today perform the business logic, and perform only
small pieces of logic at a time (which is to say, they do not generate
whole web pages as output.) The output is a simple XML or JSON that's
passed to the front-end.

The front-end logic is where almost all of the UI is coded.

I've seen two prevalent approaches to the front-end:

1) An HTML page, with JavaScript to perform certain functions. (The
jQuery approach)

2) Very little HTML, with most of the page described in JavaScript (The
ExtJS approach.)

In either case, though, the UI logic is coded on the front-end, and the
important technologies to understand are JavaScript, CSS, and HTML
(though, HTML knowledge is somewhat fading.)

WITH THAT IN MIND...

Since no UI coding is done on the back-end, it seems to me that it
doesn't make too much sense to pick a language that makes it easy to
code HTML. 5 years ago it was very useful to have technologies that
made it easy to incorporate HTML in your programs -- but that's not
really needed today. All of the older techs still work -- you just
replace the HTML with JSON or XML... But, in a manner of speaking, they
are overkill. Since you no longer emit HTML, you spend very little of
your UI coding on the server side. You don't really need a language
that specializes in embedding web technologies into your server side
language...

What's most important on the server-side now is a language that makes it
easy to code BUSINESS LOGIC. This is where RPG can really shine,
because it's great for business logic.

It may be true that languages like PHP make it easier to build JSON --
but, it's not really all _that_ big of a deal, there are JSON libraries
for RPG, or you can code them with regular/normal string manipulation
(which really isn't that hard.) Same is true of XML.

The big focus of your work when you sit down to build an application is
really on the writing the business logic itself. I've coded in 20+
programming languages, and I have always found RPG to be the best thing
out there for business logic... it's just an elegant environment for
business logic!

The other time-consuming part is the UI design... and this is an
important piece, but since that logic is all on the front-end these
days, it really doesn't matter what the back-end language is, since
that's not where you code it!

-SK


On 12/7/2012 4:43 PM, Allen, Todd wrote:

That's great to have this functionality available. Admittedly, there
is more than I was aware of. However, we're talking about RPG
expertise required to handle the server-side component of your web
application. That is where I would be careful about my decision to
use RPG for that part of it. This may sound like blasphemy,
especially since I wrote RPG code many years back, but I think
businesses must keep an eye to the future in these cases.

There are many factors that go into that and every shop is different
so that may make the decision a foregone conclusion. If I am
thinking long term then I am very hesitant to invest heavily in RPG
for the web server-side language. I would never advocate changing
the back-end business logic but there are too many other options out
there to go with CGIDEV2 blindly just because your business logic is
written in RPG. You are limiting your future resource pool by
putting all your server side web scripting in RPG.

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

P Please consider the environment before printing this email
This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.

As an Amazon Associate we earn from qualifying purchases.

This thread ...

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.