3 ms·

In a more general sense, I don't understand why we can't define field attributes in ONE spot and have most of the application software automatically just use th

by tabtab 8y ago

In a more general sense, I don't understand why we can't define field attributes in ONE spot and have most of the application software automatically just use that info rather than reinvent it in code? Things were moving that way in the 80's it appeared, then OOP came along and overzealous practitioners declared RDBMS and tables as an official evil. Sure, different screens or reports may need different subsets of such fields, but filters can be built to sort or filter different "views" as needed per usage point. (OOP is good for some things, but not others.) I'm tired of retyping or mass-replicating the field wheel. Let's return to table-oriented programming and data dictionaries. It's a D.R.Y. sin. Code is NOT the best place to store most field info. (RDBMS can also store navigation, screen, and menu info, but one thing at a time. 90% of typical CRUD could be done in a declarative sense.) You are welcome to disagree; I encourage spirited debate.

danmaz74 8y ago
Rails finds the fields from the dB and turns them into properties automatically... Isn't this exactly what you were asking?
- tabtab 8y ago
  Do you mean it generates code? That's still a "DRY" violation. And if you mean it only looks at the RDBMS table, then it has insufficient info. Describing a field well often requires more info/meta-data than what a typical RDBMS schema has. Here's a list of typical attributes: db-field-name, type, display-name, form-sequence, list-sequence, relation-type (primary key, foreign key, etc.), reference-table, min-length, max-length, default-value, help-tip, bootstrap-column-width, grouping-filters/codes, search-form-type, and other optional do-dads.
  - danmaz74 8y ago
    It doesn't generate code, it "just" allows you to load and save fields by checking the tables structures. You still need to add code manually for relationships and some specific features. Regarding the attributes you listed, looks to me like those are very CRUD-oriented. Many fields don't have a direct representation in the UI at all...
    - tabtab 8y ago
      Example? One can pick and choose what fields are included in what using WHERE clause filters. And yes, not everything is necessarily displayed, but that won't "hurt" my suggestion.

by tabtab 8y ago

danmaz74 8y ago

Rails finds the fields from the dB and turns them into properties automatically... Isn't this exactly what you were asking?

tabtab 8y ago
Do you mean it generates code? That's still a "DRY" violation. And if you mean it only looks at the RDBMS table, then it has insufficient info. Describing a field well often requires more info/meta-data than what a typical RDBMS schema has. Here's a list of typical attributes: db-field-name, type, display-name, form-sequence, list-sequence, relation-type (primary key, foreign key, etc.), reference-table, min-length, max-length, default-value, help-tip, bootstrap-column-width, grouping-filters/codes, search-form-type, and other optional do-dads.
- danmaz74 8y ago
  It doesn't generate code, it "just" allows you to load and save fields by checking the tables structures. You still need to add code manually for relationships and some specific features. Regarding the attributes you listed, looks to me like those are very CRUD-oriented. Many fields don't have a direct representation in the UI at all...
  - tabtab 8y ago
    Example? One can pick and choose what fields are included in what using WHERE clause filters. And yes, not everything is necessarily displayed, but that won't "hurt" my suggestion.