× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



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


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 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.