Re: CRUD app interface

This is the angle I was going for when I mentioned web services. Creating and duplicating data relationships, business rules, and authority rules with every new fad that comes along, and every new line manager's biases and whims, is a self flagellating exercise. In my opinion.

Why not provide a singular solution that allows all those new things to happen without having to worry about keeping a bunch of more-or-less duplicating systems synched.  Trying to solve the same problems a half dozen different ways seems to me to be a good way to start fights in the lunch room.


On 11/8/2018 11:10 AM, Nathan Andelin wrote:

On Thu, Nov 8, 2018 at 7:05 AM <JRusling@xxxxxxxxxxx> wrote:

Yeah, it's kinda slick, i like it.

I agree that CRUD utilities are slick, in a way. But I think that people
should understand that they fail in regards to most functional, user
experience, and database integrity requirements.

When we expose database read, write, update, and delete capabilities
through a user interface, those operations should be backed up by logic
that ensures end-user access authorities, database integrity constraints,
the implementation of database-I/O related business rules, error handling,
along with messages worded in a way that is meant for human understanding.
When database update operations fail due to field-level validation, the
field should be highlighted, and the cursor placed in the input element.

I wrote about that type of logic in the following article:

http://rd.radile.com/rdweb/info2/ibmiapp04.html

Which suggest that database I/O related logic should be placed in database
event procedures, having names such as:

on_read()
on_write()
on_update()
on_delete()

They should be written in a language like ILE RPG, which runs in the same
address space as the DBMS, and can perform record-level operations.
Although the part of the CRUD application that performs browser I/O may be
written and run in various language environments, I would still assert that
at least part of it - the part that actually performs RLA operations should
be written in an ILE language.

Which suggests that if one chooses to use a non-ILE language, and language
environment, then that part of the application should be coded in such a
way that it is able to interface with the back-end part, which is
performing the actual DB I/O, and the part that responds to database events
(read, write, update, and delete).