Introduction and Use Case
We think it is easier to describe the features and functionality with Use Cases. To make the documentation easier and shorter we will use a single Use Case for all pages, which will be extended over time. This page describes the details of this use case. To unify the documentation is still in progress and only very few pages have been updated so far. We will add a note to this page for these pages.
We recommend to open this use case side by side with the documentation, so that you do not have to switch back and forth.

The company

The user is the Lead Developer and CTO of a midsize news magazine called "FoodCrunch", a magazine for everything around food startups. It has just over 100 employees from 14 different languages. The editors and content authors write articles, news and other kind of editorial content. In addition to that the magazine also maintains a database called "Food Base" with information about all startup in the food area and information like co-founders, investment rounds and more.
Therefore we create one project in Squidex for all our content, assets and settings and invite all developers and content editors to this project to work together. In Squidex we call this an "App".

The content structure

The structure of the content is defined by Schemas in Squidex. In this section we describe the different content types for our use case. Read more about schemas here:

Editorial content

The CTO decided to have a single structure for all editorial content. After bringing everybody to the table, the developers and editors have decided together what information they need for each content. Even though our website is available in four different languages we write editorial content for exactly one language.
This schema is just called contents and has the following fields.
Name
Type
Localizable
Description
language
String
No
The content language.
title
String
No
The title of the editorial content.
slug
String
No
A single slug for Google friendly URLs.
content
String
No
The actual content.
type
String
No
The type of the content, e.g. "Article" or "News".
startup
Reference
No
A reference to the startup in the database.
image
Assets
No
One or more teaser images.

Startup database

The startup database is maintained in multiple languages, so that entries can be reference them from all articles, independent from the language they are written in.
This schema is called startups and has the following fields.
Name
Type
Localizable
Description
slug
String
No
A single slug for Google friendly URLs.
name
String
No
The name of the startup.
description
String
Yes
The description of the startup.
funding
Number
No
The total funding in USD ($).
foundingDate
DateTime
No
The date the startup has been founded.
founders
Array
No
The founders as list of name and position.
tags
Tags
No
A list of tags for search.
location
Geolocation
No
The geolocation of the headquarter.
metadata
Json
No
Unstructured metadata.
givenUp
Boolean
No
Indicates whether the startup has given up.

JSON structure

If you are a content editor, you can skip this section.
Of course we use JSON to represent our content in the database and API. Each content item is one document and the values of all fields are just called "content data" or "data". Because Squidex supports localized fields we need a way to structure our localized fields as well as our non-localized fields. In Squidex we have decided to use a common structure for that. Therefore our content has the following shape:
1
// contents
2
{
3
// Additional metadata, such as content id.
4
"data": {
5
"language": {
6
"iv": "en"
7
},
8
"slug": {
9
"iv": "super-corp-buys-food-startup"
10
},
11
"title": {
12
"iv": "Super Corp buys Food Startup"
13
},
14
"content": {
15
"iv": "A very long text"
16
},
17
"type": {
18
"iv": "Article"
19
},
20
"startup": {
21
"iv": [
22
"673d3a3a-988f-4ce6-a8ec-022e73e12f9f"
23
]
24
},
25
"image": {
26
"iv": [
27
"287a2948-8992-4e65-990f-3ee486c9a4b5"
28
]
29
}
30
}
31
}
32
33
// startups
34
{
35
// Additional metadata, such as content id.
36
"data": {
37
"slug": {
38
"iv": "best-organgs"
39
},
40
"name": {
41
"iv": "Best Oranges"
42
},
43
"description": {
44
"en": "Best Oranges sells the best oranges in the Valley",
45
"de": "Best Oranges verkauft die besten Orangen im Tal"
46
},
47
"funding": {
48
"iv": 1000000
49
},
50
"foundingDate": {
51
"iv": 2021-01-10T00:00:00z"
52
},
53
"founders": {
54
"iv": [{
55
"name": "John Doe",
56
"position": "Marketing"
57
}, {
58
"name": "Jane Doe",
59
"position": "Sales"
60
}]
61
},
62
"tags": {
63
"iv": [
64
"oranges",
65
"food",
66
"valley"
67
]
68
},
69
"location": {
70
"iv": {
71
"longitude": -122.431297,
72
"latitude": 37.773972
73
}
74
},
75
"metadata": {
76
"iv": {
77
"createBy": "auto-importer"
78
}
79
},
80
"givenUp": {
81
"iv": false
82
}
83
}
84
}
Copied!
As you can see, we need an JSON object for our localized fields. To use a generalized structure all objects use fields iv (for invariant) is used for localized fields. Read more about the reasoning in the section about localization:

People and roles

The following people work together with Squidex to bring content to the website.
  • Developers work together to bring new features to the website. Their responsibility is to define the schemas in Squidex and to implement the business roles with Workflows and Permissions. To make it easier for them to find and fix bugs on the website they also have full control to the content itself.
  • Editors are responsibility to write the articles in different languages and to make all the research around it. Because false information are a big deal in the News industry they are not allowed to publish the content itself.
  • Reviewers check the content before it gets published for spelling and grammar mistakes and also check correctness of all facts and information in the content.
  • Publisher work together with Marketing and social media to decide when a content should go live. They can also publish reviewed content and do not create any content themselves.
Last modified 9mo ago