> On the one hand, you have a FK field and, on the other, a TextAreaField with monospaced set to True. Is this a description of a table or a view...?
Both!
TextAreaField and StrField both define a string field in the database. The only difference between them is how they would appear rendered in HTML.
In the code snippet I included, MonDoc is a Python class that encodes the schema for a MongoDB table (MongoDB calls them collections). But MonDoc is actually a subclass of another class, FormDoc, that encodes data for an HTML form.
Using FormDoc, you can define the fields of your form, render it into HTML, validate results, etc.
The reason I merged forms and table schemas into one concept was I've used so many systems that define forms, and so many systems that define tables and they're all very similar, and I don't like having to do cut-and-paste to transform a form definition into an almost-the-same table definition. I find it tedious and error prone.
Does this reduce flexibility? It does a bit, by tying together forms and tables. But I think any rapid prototyping system is going to trade flexibility for speed of programming.
Ah gotcha, thanks for the clarification. I think the camelCase threw me off and made me think this was pseudocode (Python is usually written in snake_case).
It isn't pseudocode, it's Python source code.
> On the one hand, you have a FK field and, on the other, a TextAreaField with monospaced set to True. Is this a description of a table or a view...?
Both!
TextAreaField and StrField both define a string field in the database. The only difference between them is how they would appear rendered in HTML.
In the code snippet I included, MonDoc is a Python class that encodes the schema for a MongoDB table (MongoDB calls them collections). But MonDoc is actually a subclass of another class, FormDoc, that encodes data for an HTML form.
Using FormDoc, you can define the fields of your form, render it into HTML, validate results, etc.
The reason I merged forms and table schemas into one concept was I've used so many systems that define forms, and so many systems that define tables and they're all very similar, and I don't like having to do cut-and-paste to transform a form definition into an almost-the-same table definition. I find it tedious and error prone.
Does this reduce flexibility? It does a bit, by tying together forms and tables. But I think any rapid prototyping system is going to trade flexibility for speed of programming.