Hi Dave
Good question - the simplicity comes for the RPG developer that will
make use of a handler. The idea is that you will be able to take
existing code and add one keyword to an F-spec - the HANDLER keyword -
and then you make no additional changes - or you can write new code that
is just like what you would do for a native DSPF.
In order to do this for WORKSTN file types, the 3 main vendors each have
different tools for designing the web interface from the screens you
have now. They each implement this differently - one uses native DSPFs
that take advantage of some seldom-used keywords. Another uses their
existing tools to convert DSPFs to ASP.Net forms (I'm not sure of the
exact term here).
But the result is that you will make very little change to your existing
code, and you can go forward to new apps with standard RPG opcodes.
There is the benefit, especially for screens.
I've written a handler for database files - I have found tools that help
create a table on the iSeries that matches the remote table design,
which is necessary, right? You can't be thinking of an I10 0 field on
the iSeries and try to match it to an A20 in SQL Server.
The difficulties in handling the IO are for the person who creates the
handler. For the database-type handler I wrote, my goal was to support
as many of the DB opcodes as I could. I got almost everything - I think
only SETGT, READP, and READPE are excluded for sure. But I had to learn
just what really happen when you specify a READE or a SETLL, and just
how to implement them using SQL, the language I have to use in the
remote databases. I did find good solutions, but it took a while.
For DSPF support, you would need either to include all the opcodes, or
to be very clear about what you will NOT support. The one who writes a
handler can choose just what they will support. But a modernization
effort is not very useful, unless it covers almost everything. And that
is the effort I spoke of here.
So I'm trying to put together a picture of it - you mention CGIDEV2 - at
this time you may be using that to produce web pages and read forms from
there. So consider the idea that you could write a handler that would
use CGIDEV2 as the means for working with web pages. You could make it
specific to your needs, or make it more generic - the latter is another
challenge that the vendors have had to overcome. But in your shop, there
is nothing wrong with writing a handler for a specific application, and
have it handle only OPEN, EXFMT, and CLOSE - for a very simple web page.
I'm just thinking as I write this, so these are just ideas. That handler
might be tied to a particular file - which would have in it the fields
for data that you need on the web page. You will want to figure out just
what OPEN means - is it something you do in response to the incoming
request from the browser? Probably - I've not worked out these details
myself.
So you can put your existing CGIDEV2 code into a service program - maybe
you've done that already. That service program could be modified some to
get the parameters from the RPG runtime that OAR sends. Then you have a
2- or 3-layer structure - not the MVC that Scott mentioned, necessarily.
But it would be modular, you would have the possibility of specifying a
different handler over the same DSPF for a different remote device, say.
Your RPG code would remain the same.
This raises another issue - you can't specify the handler program or
service program dynamically - it is hard-coded. Now that might be OK -
the handler can receive an additional parameter with user-specific
information - that could be used to direct the handler to any of several
sub-handlers - I just made up that term! :)
Anyhow, you have stimulated my thinking - thanks for that. The
difficulties for handling IO are there for the one who creates the
handler. The ones who use the handler will not see those - their code
should be essentially unchanged - there is the simplicity for them.
Regards
Vern
On 2/3/2012 2:36 AM, Dave wrote:
Le 3 février 2012 08:52, Vern Hamberg<vhamberg@xxxxxxxxxxx> a écrit :
So, I think OA is just one of several options for refactoring - its use
for handling display file IO is a huge effort, so far as I can see
Hi Vern,
Been following this thread with interest, although I'm not yet in a
position to be able to discover OAR for myself. What are the difficulties
in handling the IO? I thought it was going tobe easier to transform an RPG
for use with a browser than with CGIDEV2, for example.
midrange.com
