Hi Nathan;
This is a great idea. I Actually did the same for normal I/O as an IceBreak
build in function .. Why: to get rid of the F-spec and to allow multiple
files pointers in the same RPG program (which otherwise will require another
F-spec)
Underneath I'm using the _Ropen, _Rwrite , _Rread .. C-library functions
So a I/O from a web page - with a relative record number looks like:
err = Record_get('PRODUCT' : %addr(rec) : %size(rec) : QryStrNum('rrn'));
A complete program looks like:
//' Previous function parses update or add parameter
//' ------------------------------------------------
select;
//' The "New" button is clicked in the InputForm form
when Form('Option') = 'New' ;
rrn = 0;
clear rec;
Exsr InputForm;
//' The "Update" button is clicked in the InputForm form. Update or write
new record
when Form('Option') = 'Update';
Exsr Form2db;
rrn = FormNum('sys.rrn');
if (rrn = 0) ;
if Record_Write('PRODUCT' : %addr(rec) : %size(rec));
endif;
else;
if Record_Update('PRODUCT' : %addr(rec) : %size(rec) : rrn);
endif;
endif;
Exsr LoadList;
//' The "Delete" button is clicked - and a rrn exists; now delete that
record
when Form('Option') = 'Delete';
rrn = FormNum('sys.rrn');
if rrn > 0;
if Record_Delete('PRODUCT' : rrn);
endif;
endif;
Exsr LoadList;
//' Return without update - just reload the list
when Form('Option') = 'Return' ;
Exsr LoadList;
//' When Clicking on a row in the table the " href .." returns the "rrn"
allong in the "QryStr"
when QryStrNum('rrn') > 0;
rrn = QryStrNum('rrn');
if Record_get('PRODUCT' : %addr(rec) : %size(rec) : rrn);
clear rec;
endif;
Exsr InputForm;
other;
Exsr LoadList;
endsl;
Best regards
Niels Liisberg
IceBreak Chief SW Architect
System & Metode Technologies
Håndværkersvinget 8, DK-2970 Hørsholm
Phone: +45 70 20 36 10
Fax: +45 70 20 30 11
Direct: +45 45 177 055
Mobile: +45 31 158 861
E-mail: nli@xxxxxxxxxxxxxxxxx
Web: www.system-method.com and www.Icebreak.org
-----Original Message-----
From: web400-bounces@xxxxxxxxxxxx [mailto:web400-bounces@xxxxxxxxxxxx] On
Behalf Of Nathan Andelin
Sent: 18. juni 2008 22:43
To: Web Enabling the AS400 / iSeries
Subject: Re: [WEB400] Data validation, mapping, and error handling
Aaron,
My goal is to streamline browser I/O. A single line of code to read all
HTML form variables and store their values in data structure sub-fields.
Something like:
read('PETORDER':%addr(PETORDER));
where read() would automatically perform all data type validations and map
HTML form variables to data structure sub-fields.
And a single line of code to write all data structure sub-fields to the
browser, using edit codes and edit words where applicable:
write('PETORDER':%addr(PETORDER));
So browser I/O would be comparable to Display File I/O. I'm currently about
mid-way to getting there. My new RDDBRAPI service program is a step in that
direction.
Regarding my potential involvement in an open source Icebreak, I don't have
any specific plans at the moment, except to continue sharing ideas. I tend
to be verbally supportive of native IBM i solutions, regardless of who
develops them.
Nathan.
----- Original Message ----
From: Aaron Bartell
To: Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
Sent: Wednesday, June 18, 2008 12:45:32 PM
Subject: Re: [WEB400] Data validation, mapping, and error handling
So if I understand where you are going with this, you could have this meta
data associated with a HTML form field, and upon being submitted up to the
iSeries you would have it auto-validated based on the meta data?
If so, that is pretty cool! Especially if you could make it so you could
apply business logic errors AND the automated "valid data based on data
type" checking in the same round trip.
Feel free to ignore this question if you don't want to answer it, but I am
curious to know if you are going to be involved with the coming IceBreak
Open Source version? By "involved" I mean actively participating in
furthering development and acting as a guide for new features (like you have
done here with the meta data idea). You obviously have your own framework
and have found efficiencies to build apps on the i, but I would guess that
as a group we could come up with a solid solution much quicker than if we
did it separate.
Aaron Bartell
http://mowyourlawn.com
midrange.com
