There are downsides to validating and updating databases from lists and arrays as opposed to posting single row inserts and updates. That's the case regardless of whether you're using 5250 subfiles or Web interfaces. Say the list has 25 rows where each row is subject to 5 possible validations. Light up the screen like a Christmas tree when every row is in error? Return up 125 error message to the user? Unnecessary overhead in your PHP and RPG to handle arrays (as a batch) instead of single rows?

Consider an alternative such as:

http://www.radile.com/rdweb/temp/blessings.html


The data entry form keeps error handling manageable, while the list provides useful context and information to the user.

-Nathan



----- Original Message -----
From: Michael Ryan <michaelrtr@xxxxxxxxx>
To: Web Enabling the AS400 / iSeries <web400@xxxxxxxxxxxx>
Cc:
Sent: Friday, February 15, 2013 8:56 AM
Subject: [WEB400] Best Practice to Send Data to i

I need to send a bunch of data to the i using PHP. I'm reworking a 5250
subfile program that presents a data entry subfile to the user. The user
enters information into the subfile fields, presses enter, and the program
then processes each entry in the subfile.

I want to do this process in HTML and PHP. I'm thinking of displaying an
HTML table and then processing each row when the user POSTs the data. I
want to call a stored procedure to validate the data in each row.

My first thought would be to send all the data to the stored procedure as a
series of arrays, one for each column in the . The RPG developer (who will
write the code that will become the stored procedure) is looking for
basically a MODS as input. I want to keep the validation SP accessible from
both RPG and PHP.

Any ideas? Thanks!

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