Although I agree that we are back in in the client/server paradigm with a
fat client running in the browser, the real funny thing is that lot of this
code is monolithic.



Many EXT JS programs actually looks like a messy System/34 WSU program and
I can’t see the difference in describing the structure of an expected JSON
structure or describing a buffer in RPGII FI specs and then do an AJAX call
instead for a chain to the server.



Scoot has also overlooked one thing and that is that EXT JS comes in two
flavors …



The first EXT JS is coded in OO javascript and can be coded completely
without the need of a traditional server, you just install XAMPP (Apache)
on your PC and you are up and running.



The second EXT JS is actually server side EXT JS! There is a small company
called Google, and they have a development environment called GWT and
Sencha has their EXT JS for GWT called Sencha GXT.



http://www.sencha.com/products/gxt/



What GWT does is that it generates clientside javascript on the fly, so
then we are back again to the CGIDEV2 approach.



I have in powerEXT used a combined technique.



Let’s take a 5250 ‘work with’ function, if you strip it down and remove all
the fields and check of the application fields that it handles you actually
ends up with a 5250 UI Controller that in most cases will be exactly the
same from program to program – it will just handle a subfile and a panel
without data so you have a skeleton program for a 5250 ‘work with’ function
that you can copy and populate with a subfile & panel definition by adding
an DDS and you can insert the DB table and add the DB fields in the RPG
code OR you can make a program generator that does the same.



You can do the exactly same thing in javascript, that is strip it down to a
generic ‘work with’ function and then let a program insert the specific
code for the function, the big difference is that you can do it dynamically
since javascript doesn’t has to be compiled.



Since the server does the code, you can easily personalize each client
program according to user rules and even make I18N translations of metadata.



What is left is to define the data structure of the JSON object in the
communication with the server. This is done with a late binding to the
fields in grids and forms. The REST service the program calls in order to
get data start by defining the data it sends so the JSON object that is
returned from the server contains a description and then the data.



So it all becomes true MVC if it is organized properly:



- The Controller is a generic javascript for all ‘Work With’
functions

- The View is generated by the server on the fly and passed to the
Controller

- The Model resides on the server as a UI independed REST service



So the server isn’t just a server that delivers data and the Model trough
REST services, the big difference from traditional HTML is that the program
that generates the View is separated for the program that delivers the
actual application and data – the Model.



Another thing is that the system that delivers the View doesn’t have to be
the same system that delivers the Model and you can even use different
languages and even use a cloud app to deliver both the Controller and the
View.



So do we need middleware that can deliver code to the client, yes, but
today it is more likely to be JSON specifications to the UI components
embedded in javascript than traditional HTML.



Is CGIDEV2 a ‘dead duck’ in that sense/environment? No, even many would
like to kill it and throw out the baby with the bath water to get their
hands on the CGIDEV2 developers. CGIDEV2 is a good a middleware as any
other handler and I’m working on genuine UNICODE support in CGIDEV2 by
changing the internal storage I/O model to run in UTF-8 instead of EBCDIC.



So is there any truth in “This paradigm has really changed”?



Yes, but don’t go to sleep, because tomorrow it may all have changed ;-)



Is there a “holy-war” going on?



Yes, we have one God (IBM I) but we mostly disagree what goes into our Holy
Bible. Unlike many other platforms we have a relatively small community of
worshipers that gathers and discuss in few general forums where we mostly
sing “I did it my way” as the preferred psalm as we grow older.



It simply can’t be different when everybody runs in different directions,
there is no true collaboration and some even use dirty tricks so as to
announce “open standards”, even spiced with borrowed feathers, that
basically is a single ISV proprietary standard.


On Sat, Dec 8, 2012 at 4:42 PM, Mike Pavlak <mike.p@xxxxxxxx> wrote:

A key point to add to Scott's observations. PLEASE make sure during the
interview process that the PHP or C programmer (or whatever) is interested
in "business" programming. I have seen IBM i shops hire good people who
simply are not interested in business programming and after 6 months they
leave because the wok isn't "exciting" for them. Please realize that
there is a lot more to hiring someone than just skills and attitude. If
you want just a web designer, they are out there. If you want someone
who will work with the next generation of technology AND BUSINESS which
could by any of the languages discussed in this thread, please make sure
that are headed in that direction. We went through quite a few developers
at another company before we finally figured out that part of the
equation. In other words, someone who wants to just write games may not
make a good business developer on IBM i, let alone learn RPG/Free.

One more observation has to do with hiring religious wars. Let's say the
resource you are looking at has Linux all over her resume. This is not to
say that they would be opposed to learning IBM i. But, make darned sure
they have a VERY open mind or you may spend the next 6-12 months fighting
an internal religious war about platforms. Many people who have an open
mind find IBM i quite nice. Others can find a million excuses for why they
"think" they can't do their job. Scott is a perfect example of "NO
EXCUSES" :)

My $.02.

Mike
Office Phone: (708)233-5880 Cell: (408)679-1011


-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Scott Klement
Sent: Saturday, December 08, 2012 1:51 AM
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Web Enabling Applications

Todd,

What I've discovered is that RPG is simply a better language for writing
business rules and business logic than the others.

I agree with your assessment that it's often hard to find qualified RPG
developers. That's not to say that it's hard to find RPG developers --
but rather than most RPG developers on the job market have out-of-date
skills, so are not "qualified." The reasons for this vary, but it's
mostly because too many businesses have this idea that RPG and IBM i are
not capable (Which is completely untrue) and therefore delegate modern
tasks to other platforms. This becomes self-fulfilling, because the
RPGers don't get real life work experience with modern work.

To combat that, you have to start somewhere... and one approach that
has worked well for several shops that I've talked to is to hire PHP or C
programmers, and then TEACH them RPG. Many of them, once they get past
the learning curve, are REALLY impressed by the RPG and IBM i environment.
The integrated platform with integrated database is a positive boon for
them. Being able to write business logic and database logic in RPG is
something they enjoy, because it makes their job easier than attempting
the same thing in languages like PHP or C. (Especially C!)

And they bring a fresh viewpoint to old shops, and their experience with
modern development techniques comes along with them -- and the results are
great.

So please don't be dismayed when you can't find RPG programmers... just
hire a PHP or C programmer, and teach them. I think you'll be pleased
with that.

However -- and this is a mistake I've seen too many times -- don't try to
thrust them into old-fashioned ways of doing things, that will turn
them off. Give them Rational Developer, not SEU/PDM. Have them learn
and write apps in Free format code, with subprocedures and other modular
techniques, and SQL for file access. Don't start them off with legacy
stuff, or it will discourage them. (Though, probably down the road,
they'll have to learn the legacy stuff to maintain older applications --
but don't start them there, or they'll get turned off of the platform.)

-SK


On 12/7/2012 1:06 PM, Allen, Todd wrote:

I may be in the minority here but I'd shy away from using CGIDEV2 for
any sort of web development. I say minority on this list only. The
percentage of all web developers that have used or heard of CGIDEV2 is
probably less than .001%. We've found that RPG developers are hard to
find. RPG developers that have web experience are even harder to
find. If JSON is a requirement then I'd also be concerned about
processing JSON data with RPG. There are plenty of libraries out
there for JSON processing but I don't know if you'll find one for 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.
--
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 ...

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.