mirror of
https://github.com/frappe/books.git
synced 2025-02-02 03:58:26 +00:00
chore: shift readme stuff into a readme
This commit is contained in:
18alantom
parent
591e7b3163
commit
c7ecdf6ff4
@ -1,10 +1,17 @@
|
||||
# Models
|
||||
|
||||
The `models` root folder contains all the model files, i.e. files containing all the models. **Models** here, refers to the classes that handle the data, its validation and updation and a bunch of other stuff.
|
||||
The `models` root folder contains all the model files, i.e. files containing all
|
||||
the models. **Models** here, refers to the classes that handle the data, its
|
||||
validation and updation and a bunch of other stuff.
|
||||
|
||||
Each model directly or indirectly extends the `Doc` class from `frappe/model/doc.ts` so for more info check that file and the associated types in `frappe/model/types.ts`.
|
||||
Each model directly or indirectly extends the `Doc` class from
|
||||
`frappe/model/doc.ts` so for more info check that file and the associated types
|
||||
in `frappe/model/types.ts`.
|
||||
|
||||
A model class can used even if the class body has no content, for example `PurchaseInvoiceItem`. Else the model used will default to using `Doc`. The class can also be used to provide type information for the field types else they default to the catch all `DocValue` example:
|
||||
A model class can used even if the class body has no content, for example
|
||||
`PurchaseInvoiceItem`. Else the model used will default to using `Doc`. The
|
||||
class can also be used to provide type information for the field types else they
|
||||
default to the catch all `DocValue` example:
|
||||
|
||||
```typescript
|
||||
class Todo extends Doc {
|
||||
@ -14,19 +21,28 @@ class Todo extends Doc {
|
||||
}
|
||||
```
|
||||
|
||||
While this has obvious advantages, the drawback is if the underlying fieldtype changes this too will have to be changed.
|
||||
While this has obvious advantages, the drawback is if the underlying fieldtype
|
||||
changes this too will have to be changed.
|
||||
|
||||
The data stored by the models is decided by the schema passed to it's
|
||||
constructor. Check `schemas/README.md` for info on this.
|
||||
|
||||
## Adding Stuff
|
||||
|
||||
When adding stuff to `models/**` make sure that it isn't importing any Vue code or other frontend specific code globally. This is cause model file tests will directly use the the `Frappe` class and will be run using `mocha` on `node`.
|
||||
When adding stuff to `models/**` make sure that it isn't importing any Vue code
|
||||
or other frontend specific code globally. This is cause model file tests will
|
||||
directly use the the `Frappe` class and will be run using `mocha` on `node`.
|
||||
|
||||
Importing frontend code will break all the tests. This also implies that one should be wary about transitive dependencies.
|
||||
Importing frontend code will break all the tests. This also implies that one
|
||||
should be wary about transitive dependencies.
|
||||
|
||||
_Note: Frontend specific code can be imported but they should be done so, only using dynamic imports i.e. `await import('...')`._
|
||||
_Note: Frontend specific code can be imported but they should be done so, only
|
||||
using dynamic imports i.e. `await import('...')`._
|
||||
|
||||
## Regional Models
|
||||
|
||||
Regional models should as far as possible extend the base model and override what's required.
|
||||
|
||||
They should then be imported dynamicall and returned from `getRegionalModels` in `models/index.ts` on the basis of `countryCode`.
|
||||
Regional models should as far as possible extend the base model and override
|
||||
what's required.
|
||||
|
||||
They should then be imported dynamicall and returned from `getRegionalModels` in
|
||||
`models/index.ts` on the basis of `countryCode`.
|
||||
|
||||
43
schemas/README.md
Normal file
43
schemas/README.md
Normal file
@ -0,0 +1,43 @@
|
||||
# Schema
|
||||
|
||||
Main purpose of this is to describe the shape of the models' table in the
|
||||
database. But there is some irrelevant information in the schemas with
|
||||
respect to this goal. This is information is allowed as long as it is not
|
||||
dynamic, which is impossible anyways as the files are data (`.json`, not `.js`)
|
||||
|
||||
If any field has to have a dynamic value, it should be added to the controller
|
||||
file by the same name, check the `books/models` subdirectory for this.
|
||||
|
||||
There are a few types of schemas:
|
||||
|
||||
- **Regional**: Schemas that are in the _'../regional'_ subdirectories
|
||||
these can be of any of the below types.
|
||||
- **Abstract**: Schemas that are not used as they are but only after they are
|
||||
extended by Stub schemas. Indentified by the `isAbstract` field
|
||||
- **Subclass**: Schemas that have an `"extends"` field on them, the value of which
|
||||
points to an Abstract schema.
|
||||
- **Complete**: Schemas which are neither abstract nor stub.
|
||||
|
||||
For more detail on the meta structure of the schema check `books/schemas/types.ts`.
|
||||
|
||||
## Final Schema
|
||||
|
||||
This is the schema which is used by the database and app code and is built by
|
||||
combining the above types of schemas.
|
||||
|
||||
The order in which a schema is built is:
|
||||
|
||||
1. Build _Regional_ schemas by overriding the fields and other properties of the
|
||||
non regional variants.
|
||||
2. Combine _Subclass_ schemas with _Abstract_ schemas to get complete schemas.
|
||||
|
||||
_Note: if a Regional schema is not present as a non regional
|
||||
variant it's used as it is._
|
||||
|
||||
## Additional Notes
|
||||
|
||||
In all the schemas, the `"name"` field/column is the primary key. If it isn't
|
||||
explicitly added, the schema builder will add it in.
|
||||
|
||||
The following schema fields will be implicitly translated by the frontend:
|
||||
`"label"`, `"description"`, and `"placeholder"`, irrespective of nesting.
|
||||
@ -1,42 +1,3 @@
|
||||
/**
|
||||
* # Schema
|
||||
*
|
||||
* Main purpose of this is to describe the shape of the Models table in the
|
||||
* database. But there is some irrelevant information in the schemas with
|
||||
* respect to this goal. This is information is allowed as long as it is not
|
||||
* dynamic, which is impossible anyways as the files are data (.json !.js)
|
||||
*
|
||||
* If any field has to have a dynamic value, it should be added to the controller
|
||||
* file by the same name.
|
||||
*
|
||||
* There are a few types of schemas:
|
||||
* - _Regional_: Schemas that are in the '../regional' subdirectories
|
||||
* these can be of any of the below types.
|
||||
* - _Abstract_: Schemas that are not used as they are but only after they are
|
||||
* extended by Stub schemas. Indentified by the `isAbstract` field
|
||||
* - _Subclass_: Schemas that have an "extends" field on them, the value of which
|
||||
* points to an Abstract schema.
|
||||
* - _Complete_: Schemas which are neither abstract nor stub.
|
||||
*
|
||||
*
|
||||
* ## Final Schema
|
||||
*
|
||||
* This is the schema which is used by the database and app code.
|
||||
*
|
||||
* The order in which a schema is built is:
|
||||
* 1. Build _Regional_ schemas by overriding the fields and other properties of the
|
||||
* non regional variants.
|
||||
* 2. Combine _Subclass_ schemas with _Abstract_ schemas to get complete schemas.
|
||||
*
|
||||
* Note: if a Regional schema is not present as a non regional variant it's used
|
||||
* as it is.
|
||||
*
|
||||
* ## Additional Notes
|
||||
*
|
||||
* In all the schemas, the 'name' field/column is the primary key. If it isn't
|
||||
* explicitly added, the schema builder will add it in.
|
||||
*/
|
||||
|
||||
export enum FieldTypeEnum {
|
||||
Data = 'Data',
|
||||
Select = 'Select',
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user