Re: IBM i upgrades / Dev Tools

Hi Rob

one problem with "doing everything in PHP" is that potentially it will
blind you to all the other elements the platform brings to the solution.

In addition to DB triggers, you have the advantage of jobqueues,
subsystems, dataqueues - all the work management stuff that the i provides
to help you architect your solution - and that is just for starters.

If you stick only to PHP and build the kind of PHP solution you see in
books and all over the web - and that you are most likely familiar with -
then you will have thrown out all the advantages the i offers as an
integrated platform. Most likely you will end up building a whole lot of
stuff that is built into the i already.

BTW, don't read this as a recommendation to switch to RPG - I just believe
it will help your project reap the unique benefits the i provides if you
look outside the PHP box and don't just implement a classic LAMP type PHP
solution on the i.

On Wed, Nov 4, 2015 at 10:01 AM, Rob <rob.couch@xxxxxxxxxxxxxx> wrote:

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


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