Just like every other EverythingIsa, it is possible to view everything, or at least a good portion of an app/algorithm/process as a CrudScreen system: editing screens to enter attributes; reports to analyze attributes; and queries, largely driven by saved and ad-hoc QueryByExample; handle the vast majority of the system's behavior. It '''blurs the distinction between data-entry and "programming".''' Programming is just "advanced" data-entry. 

There are two big questions one may have about this viewpoint: First, can it be done; and second, is it a good idea. The second can be split further into machine performance considerations and software complexity management considerations. I'm of the belief that for the most part it is a good idea, but that existing tools and fads don't support it, erroneously going the OO-framework-way instead to manage complexity and boat-loads of attributes.

Note that this does not preclude the use of visual-designers; for visual designers are just another form of CRUD. Further, if the actual info is stored in a database, then a visual designer is one of multiple editing options. One could use a table editor (TableBrowser) as well if that's the most convenient way to specify info for a particular need. 

I've seen medium-complexity applications written in MicrosoftAccess using zero VBA coding, only screen, report, query, and design screens and wizards. Can't say I liked the result, and hope it's not the pinnacle of EverythingIsCrud's potential, but it got the job done. (I have some ideas for improving the technique, but that's another topic.)

--Top
---------
See also: SturgeonsLaw ;-), RestArchitecturalStyle, TableOrientedProgramming, ConvertingImperativeToDeclarative, ViewingAlgorithmsAsCollectionProcessing, NakedObjects, AutoGenCrudScreens
----
CategoryUserInterface