DataSource Creation: Recommended most comprehensive and convenient approach

[SchlauKunde]

It is my understanding that the notion of DataSource Descriptors plays a central role in the SmartClient Galaxy; and the more bolstered the DataSource Descriptors are, the better !

So I would like to know: What is the most recommended approach to (automatically) generate DataSource Descriptors ? IMO the most canonical path would be: Creating an (annotated) ER (Entity-Relationship) Model of the domain at hand; and then automatically creating SmartClient DataSource Descriptors from the ER Model.

Any suggestions/remarks ?

[SchlauKunde]

I am a little bit disappointed about the feedback of the SmartClient community !

I for one would like to adhere to the rational principle of having a 'Single Point of Truth (SPoT)' ! And my hope is that SpoT should be possible when leveraging the SmartClient Concept of DataSources on the client- as well as on the server-side.

First experiences - using MySQL 5.1.41:
- Automatically generated DataSources from MySQL have fields with type, name and key attributes; a required attribute is NOT derived
- When adding a required attribute to the DataSource fields, it is not correctly mapped to 'NOT NULL' in MySQL when automatically generating a MySQL table from the DataSource ...


Following is an enumeration of SmartClient DataSourceField attributes I would like to see treated automatically:
- type: should imply automatic validators whereever possible
- name
- foreignKey
- hidden
- length (for strings)
- required


Furthermore, what about:
- A Default Value ?
- Custom Validators ? Which are defined in many ERD (Entity-Relationship Diagram) Tools via DB Constraints ?


I suppose You get the point: I want to adhere to SPoT ! And I want to get the most out of this principle !


I AM aware that one can extend 'batchDSGenerator.jsp' ! But why should each and every SmartClient SPoT fan reinvent the wheel ? I guess there MUST already be plenty of approaches out there to adhere brilliantly to SPoT !

[Isomorphic]

Type already does imply validators, length is auto-derived. required and not null do not have the same meaning. Hidden can be meaningfully derived from SQL schema either. ForeignKey is inconsistenly exposed by different databases but support will be added at some point (no ETA). JDBC metadata is not nearly deeper enough to capture custom validators.

Trying to get to zero information in the .DS.XML file and everything derived from SQL schema is overall not realistic. However auto-derivation still succeeds 100% in it's goal of not forcing you to reiterate things that *can* be meaningfully derived from SQL schema.