Re: IBM i upgrades / Dev Tools

Nathan,

You are correct. Your initial advise is not what I wanted to hear.

I may be wrong to want all of my business logic in PHP... as for email I do not need RPG or DB2 to email... PHP can email just fine. It could very well be that it is the terminology being used and or misunderstood.

When I think business logic, I think of the actions I allow users to have and when they can have them. Which page links are visible, which DOM elements I want to show.

When I am thinking of storing data, I can see allowing RPG to validate it and then store it. But I can write the validation logic of the data easier in PHP with a language I consider to be more advanced.

I asked Tony Cairns about why DB2 still uses ebcdic vs utf8; he said, "IBM has always been about not breaking things." I understand that, I still think it should be an option. Hell MySQL will allow every other character field to be a different character set. Makes it difficult to do comparisons though. I have never used stored procedures or views with MySQL in my LAMP projects, and my code is tight, clean, fast and very responsive. I have spent the last 8 years developing a Data abstracted Object model... my data knows nothing of the views and my views know nothing of the stored data.

My web pages are never submitted. I use XHR2 exclusively.

I value all of the input I have received in this list, even when it is hard to digest. I am trying to learn how to make this wonderful machine perform. I may even try my hand at Free RPG.

Thanks,
Rob

On 2015-11-03 14:04, Aaron Bartell wrote:

I am curious how this conversation pans out. Lots of things sound good in
theory and can even be proven to be implemented, but there are so many
other factors that can potentially bite you in the butt later on. FWIW, I
participated in such an architecture where the front-end was .NET and
back-end was SQL stored procedures fronting RPG code. All database
interaction went through the RPG code and the stored procedures numbered in
the thousands. Deployments were **painful** and missed deadlines were many
because of complexity. Sometimes complexity is warranted but it needs to
be very carefully balanced.

For example, and going back to Nathan's example, what if some INSERTs
should send a confirmation email and others shouldn't; and what if it
depends on what user interface is writing the row? You could pass the
interface (web vs. 5250) into the trigger but then you start being guilty
of "leaky abstraction".

With that said, I am a firm believer in things like foreign
keys/constraints and SQL stored procs where they've proven their need in a
given project (based on PHP business logic failing) , but to start out a
project declaring all logic must exist in them is making a lot of
assumptions.

At the end I guess what I am getting at, Nathan, is that there is more than
one way to skin a cat.

Aaron Bartell
litmis.com - Services for open source on IBM i


On Tue, Nov 3, 2015 at 1:44 PM, Nathan Andelin <nandelin@xxxxxxxxx> wrote:

Any guidance is most appreciated.

Any guidance is most appreciated? I doubt that, since you hastily dismissed
my previous advice about placing data validation, RI constraints, and
business rules "in the database" behind triggers.

I believe that what I'm suggesting is very sound advice. Moreover, what you
seem to be insisting on in placing that type of processing in PHP, is poor
architecture.

Anyone having a connection to your database can bypass your "business
logic". You may be enthralled with PHP right now, but there may come a time
in the near future when something comes along, say single-page
applications, or responsive UI design, or whatever innovation which
improves the user experience which PHP is not well suited for. You may
change your mind about PHP. But your business logic should nevertheless
remain intact.

Here's a link to an RPG sample which handles data validation, which is
evoked by a before-insert / update trigger.

http://code.midrange.com/ee85fb606a.html

I don't understand your perceptions about RPG being "archaic". But since
you are so predisposed, allow me to point out a few elements which show the
elegance of the design.

The source module compiles into a "service program" which exposes three
procedures namely:

init();
process();
term();

init() and term() procedures "initialize" the module when first loaded into
memory by a piece of plumbing known as a "mediator", and "clean up" after
the mediator notices the module no longer being used (a period of
inactivity).

The process() procedure implements "data validation" and generating a
surrogate key for a record, prior to "insert".

Since RPG runs in the same address space as the database, and has direct
access to records, it can simply call a a procedure to "retrieve" error
messages or completion messages, and return them to "callers", using a
single statement. Notice msgGetText() - retrieve a formatted message from
a DB table and trgMsgAdd() - add a message to an array.

Invalid data prevents the update from occurring, no matter who the caller
might be, regardless of whether PHP is the middleware du jour, or not.

This interface can also be configured to work asynchronously. Say rather
than "validations" process() is used to compose and send email, generate an
order for a bank card and a PIN. Is there any reason to tie up the UI while
waiting for such back-end processing to occur? If you want to provide your
users with the best user experience possible ...
--
This is the Web Enabling the IBM i (AS/400 and 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 email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus