Well, for a Crud Generator to be functionally complete it has to fulfill the following requirements:

* Rule 0: It should work for tables that have a primary key of any number of fields (1 or more)
* Rule 1: Be able to generate the CrudScreen''''''s for the IrreducibleComplexityEntityModel
* Rule 2: It should be possible to “capture” the entire “model graph” as a single transaction starting from any entity node in the model graph
** ''Please clarify what a "model graph" is.''
*** The model graph is the graph representing the EntityRelationshipModel in a EntityRelationshipDiagram (''in the image linked as of 2009/2/19 the "entity nodes" are the green rectangles'')
* Rule 3: It should be possible to “skip” validation until the “save” button of the screen to save the entity node where we started is clicked, and, it should be easy to go from there to any of the screens used to edit the other nodes to fix any validation error.
* Rule 4: It should be possible to search for instances (rows?) of  the entity (class, table?)  by using a QueryByExample node graph that can be built using one or all of the nodes of the model with any arbitrary depth.

With these rules, I realize that the only FunctionallyCompleteCrudGenerator that I have seen was Apple WebObjects DirectToWeb… All others (JbossSeamGen for example) are unable to deal with all the kinds of relationships in the IrreducibleComplexityEntityModel and, even without that limitation, are just unable to deal with requirements 2,3, and 4. because all of them force you to either violate transactionality by forcing you to save before navigation to the next node, or force you to pass all validation rules at a particular node before going to the next, or, have a really simple and powerless query by example UI.

''I agree that there are very few tools out there that fulfill there requirements. WebObjects really was ahead of its time. But it's like Lisp: TooAdvancedForItsOwnGood often means proprietary lock-in or technology lock-in or community lock-in.''

EditHint: Maybe the 'obvious' requirements of CRUD should be restated to provide a bit more context for the unsuspecting reader.

----

"Make possible to" is only part of the problem. "Make it convenient to" should also be considered. For example:

* Make it convenient to control which subset of columns participate in a given query, screen, report, etc.

* Make it convenient to have "dummy" columns or fields that can be turned into formal ones with custom processing.

* Make it convenient or automatic to pick/display the short name if no long name available for a given field.

----
See Also: TheRadBottleneck, CrudScreen, CrudPatterns, CodeGenerationIsaDesignSmell, CreateReadUpdateDelete (for definition of CRUD)
----
CategoryInteractionDesign