Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Document free model definition placement #226

Merged
Merged
Show file tree
Hide file tree
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 3 additions & 3 deletions docs/01-get-started.md
Original file line number Diff line number Diff line change
Expand Up @@ -122,7 +122,7 @@ These are the most important directories:

- `config`: These are the configuration files for your Serverpod. These include a `password.yaml` file with your passwords and configurations for running your server in development, staging, and production. By default, everything is correctly configured to run your server locally.
- `lib/src/endpoints`: This is the default location for your server's endpoints. When you add methods to an endpoint, Serverpod will generate the corresponding methods in your client.
- `lib/src/models`: The model definition files are placed here. The files define the classes you can pass through your API and how they relate to your database. Serverpod generates serializable objects from the model definitions.
- `lib/src/models`: Default location for your model definition files. The files define the classes you can pass through your API and how they relate to your database. Serverpod generates serializable objects from the model definitions.

Both the `endpoints` and `models` directories contain sample files that give a quick idea of how they work. So this a great place to start learning.

Expand Down Expand Up @@ -167,9 +167,9 @@ To learn more about endpoints, see the [Working with endpoints](concepts/working

Serverpod makes it easy to generate serializable classes that can be passed between server and client or used to communicate with the database.

The structure for your serialized classes is defined in yaml-files in the `lib/src/models` directory. Run `serverpod generate` in the home directory of the server to build the Dart code for the classes and make them accessible to both the server and client.
The structure for your serialized classes is defined in `spy.yaml` files anywhere in the `lib` directory. Run `serverpod generate` in the home directory of the server to build the Dart code for the classes and make them accessible to both the server and client.
SandPod marked this conversation as resolved.
Show resolved Hide resolved

Here is a simple example of a yaml-file defining a serializable class:
Here is a simple example of a `spy.yaml` file defining a serializable class:

```yaml
class: Company
Expand Down
4 changes: 2 additions & 2 deletions docs/02-get-started-with-mini.md
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,7 @@ If you are using VS Code, install our Serverpod extension. It will help you vali
:::

## Creating models
In Serverpod, you define your models in easy-to-read YAML-files, which you place in your server’s `lib/src/models` directory. Model files will be converted to Dart classes that can be serialized and sent to and from the server to your app. This is an example of a model file:
In Serverpod, you define your models in easy-to-read YAML-files, which you place anywhere in your server’s `lib` directory with the `spy.yaml` extension. Model files will be converted to Dart classes that can be serialized and sent to and from the server to your app. This is an example of a model file:

```yaml
class: Company
Expand Down Expand Up @@ -111,4 +111,4 @@ var result = await client.company.isLegit(company);
```

## Conclusion
You are now ready to start exploring the exciting world of Serverpod! And even if you start out with Serverpod mini, you can always [upgrade](upgrading/upgrade-from-mini) to the full version later.
You are now ready to start exploring the exciting world of Serverpod! And even if you start out with Serverpod mini, you can always [upgrade](upgrading/upgrade-from-mini) to the full version later.
4 changes: 3 additions & 1 deletion docs/06-concepts/02-models.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,8 @@
# Working with models

Models are Yaml files used to define serializable classes in Serverpod. They are used to generate Dart code for the server and client, and, if a database table is defined, to generate database code for the server. Using regular `.yaml` files within `lib/src/models` is supported, but it is recommended to use `.spy.yaml` (.spy stands for "Server Pod Yaml") to leverage syntax highlighting provided by the [Serverpod Extension](https://marketplace.visualstudio.com/items?itemName=serverpod.serverpod) for VS Code.
Models are Yaml files used to define serializable classes in Serverpod. They are used to generate Dart code for the server and client, and, if a database table is defined, to generate database code for the server.

Using regular `.yaml` files within `lib/src/models` is supported, but it is recommended to use `.spy.yaml` (.spy stands for "Server Pod Yaml"). Using this file type allows placing the model files anywhere in your servers `lib` directory and enables syntax highlighting provided by the [Serverpod Extension](https://marketplace.visualstudio.com/items?itemName=serverpod.serverpod) for VS Code.
SandPod marked this conversation as resolved.
Show resolved Hide resolved

The files are analyzed by the Serverpod CLI when generating the project and creating migrations.

Expand Down
2 changes: 1 addition & 1 deletion docs/06-concepts/10-modules.md
Original file line number Diff line number Diff line change
Expand Up @@ -67,7 +67,7 @@ dependencies:

## Referencing a module

It can be useful to reference serializable objects in other modules from the yaml-files in your model directory. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.
It can be useful to reference serializable objects in other modules from the YAML-files in your models. You do this by adding the module prefix, followed by the nickname of the package. For instance, this is how you reference a serializable class in the auth package.

```yaml
class: MyClass
Expand Down