You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: 10/umbraco-cms/extending/packages/creating-a-package.md
+2
Original file line number
Diff line number
Diff line change
@@ -170,6 +170,8 @@ To allow other people to use your package you will need to publish it to a publi
170
170
171
171
There is comprehensive documentation on how to [Publish a NuGet package to NuGet.org](https://docs.microsoft.com/en-us/nuget/nuget-org/publish-a-package) in the official NuGet documentation, as well as how to [Publish to a private feed](https://docs.microsoft.com/en-us/nuget/hosting-packages/overview) while developing.
172
172
173
+
To publish your package to the Umbraco community, use the "[Listing Your Package](https://docs.umbraco.com/umbraco-dxp/marketplace/listing-your-package)" article to feature your package on the Umbraco Marketplace.
174
+
173
175
## Installing a NuGet package
174
176
175
177
You can install your newly created NuGet package using Visual Studio, Rider, Command Line or editing the project file directly.
Copy file name to clipboardExpand all lines: 10/umbraco-cms/reference/configuration/nucachesettings.md
+35-6
Original file line number
Diff line number
Diff line change
@@ -4,7 +4,9 @@ description: "Information on the NuCache settings section"
4
4
5
5
# NuCache Settings
6
6
7
-
This settings section allows you to specify the block size of the BTree used by NuCache. This is configured by default, so you don't need to configure this. However it is possible with something like:
7
+
The NuCache settings allow you to configure different aspects of how cached content is stored and retrieved. Below are the details of the available settings and how they can be configured to optimize performance and compatibility with your project needs.
8
+
9
+
## BTreeBlockSize
8
10
9
11
```json
10
12
"Umbraco": {
@@ -16,15 +18,42 @@ This settings section allows you to specify the block size of the BTree used by
16
18
}
17
19
```
18
20
19
-
This is how NuCache is configured by default. It is important to mention that the block size must be a power of two, at least 512, and at most 65536 (64K).
21
+
{% hint style="info" %}
22
+
The block size must be a power of two. It should be at least 512 and at most 65536 (64K).
23
+
{% endhint %}
20
24
21
-
## Additional Settings
25
+
## NuCacheSerializerType
26
+
27
+
The `NuCacheSerializerType` setting allows developers to specify the serialization format for NuCache content. This setting is particularly relevant for projects migrating from older versions of Umbraco that relied on JSON formats.
28
+
29
+
To use JSON serialization instead of the default MessagePack:
It is possible to configure NuCache to work in memory only without reading/writing the NuCache database files.
40
+
### Using 'appsettings.json'
24
41
25
-
Startup duration may increase for larger sites during a "warm boot" but smaller sites should see minimal impact.
42
+
```csharp
43
+
{
44
+
"Umbraco": {
45
+
"CMS": {
46
+
"NuCache": {
47
+
"NuCacheSerializerType":"JSON"
48
+
}
49
+
}
50
+
}
51
+
}
52
+
```
53
+
54
+
## Additional Settings
26
55
27
-
The settings have not yet been exposed via the new configuration setup, instead you must configure with a composer.
56
+
You can configure NuCache to work in memory only without reading/writing to the NuCache database files. Startup duration may increase for larger sites during a "warm boot" but smaller sites should see minimal impact. The settings have not yet been exposed via the new configuration setup, instead you must configure with a composer.
Copy file name to clipboardExpand all lines: 10/umbraco-cms/reference/templating/modelsbuilder/understand-and-extend.md
+48-32
Original file line number
Diff line number
Diff line change
@@ -1,21 +1,22 @@
1
1
---
2
+
description: Understanding and Extending ModelsBuilder in Umbraco
3
+
---
2
4
3
5
4
-
meta.Title: "Understand and Extend Modelsbuilder"
5
-
description: "Understand and extend modelsbuilder"
6
-
---
6
+
# Introduction
7
7
8
+
Umbraco’s Models Builder automatically generates strongly typed models for content types, allowing developers to work with Umbraco data in a structured and efficient manner. This article explains how models are generated, how composition and inheritance work, and best practices for extending models without causing issues.
8
9
9
-
#Understand and Extend
10
+
## Models Generation Process
10
11
11
-
Models are generated as partial classes. In its most basic form, a model for content type `TextPage`ends up in a `TextPage.generated.cs` file and looks like:
12
+
Models Builder generates each content type as a partial class. For example, a content type named `TextPage`results in a `TextPage.generated.cs` file with a structure like this:
@@ -45,7 +46,12 @@ public partial class TextPage : PublishedContentModel
45
46
}
46
47
```
47
48
48
-
What is important is the `Header` property. The rest is (a) a constructor and (b) some static helpers to get the `PublishedContentType` and the `PublishedPropertyType` objects:
49
+
In the above code:
50
+
51
+
* The model includes a constructor and static helpers to fetch the content type (`PublishedContentType`) and property type (`PublishedPropertyType`).
52
+
* The most important part is the property definition (`Header`), which retrieve values from Umbraco.
53
+
54
+
You can use helper methods to access content and property types:
49
55
50
56
```csharp
51
57
varcontentType=TextPage.GetModelContentType(); // is a PublishedContentType
@@ -54,11 +60,16 @@ var propertyType = TextPage.GetModelPropertyType(x => x.Header); // is a Publish
54
60
55
61
## Composition and Inheritance
56
62
57
-
Content type *composition* consists in having content types "inherit" properties from other content types. Contrary to C#, where a class can only inherit from one other class, Umbraco content types can be composed of several other content types.
63
+
### Composition
64
+
65
+
Umbraco content types can be composed of multiple other content types. Unlike traditional C# inheritance, Umbraco allows a content type to inherit properties from multiple sources.
58
66
59
-
The `TextPage`content type could be composed of the `MetaInfo` content type (and thus inherit properties `Author` and `Keywords`) and of the `PageInfo` content type (and thus inherit properties `Title` and `MainImage`).
67
+
For example, a `TextPage`might be composed of:
60
68
61
-
Each content type that is involved in a composition is generated both as a class and as an interface, and so the `MetaInfo` content type would be generated as (some code has been removed and altered for simplicity's sake):
69
+
***MetaInfo** content type (inherits `Author` and `Keywords` properties).
70
+
***PageInfo** content type (inherits `Title` and `MainImage` properties).
71
+
72
+
Each content type in a composition is generated both as a class and as an interface. The `MetaInfo` content type would be generated as:
62
73
63
74
```csharp
64
75
// The composition interface
@@ -81,7 +92,7 @@ public partial class MetaInfo : PublishedContentModel
81
92
}
82
93
```
83
94
84
-
And the `TextPage` model would be generated as (some code has been removed and altered for simplicity's sake):
@@ -91,9 +102,13 @@ public partial class TextPage : PublishedContentModel, IMetaInfo
91
102
}
92
103
```
93
104
94
-
A content type *parent* is a tree-related concept: In the Umbraco backoffice, a content type appears underneath its parent, if any. By convention, a content type is always **composed of its parent** and therefore inherits its properties. However, the parent content type is treated differently, and the child content type *directly inherits* (as in C# inheritance) from the parent class.
105
+
### Inheritance
106
+
107
+
In addition to composition, content types can have a parent-child relationship. In the Umbraco backoffice, a content type appears underneath its parent.
95
108
96
-
Therefore, assuming that the `AboutPage` content type is a direct child of `TextPage`, it would be generated as:
109
+
By convention, a content type is always **composed of its parent** and therefore inherits its properties. However, the parent content type is treated differently, and the child content type *directly inherits* (as in C# inheritance) from the parent class.
110
+
111
+
If `AboutPage` is a child of TextPage, its generated model would inherit directly from `TextPage`:
97
112
98
113
```csharp
99
114
// Note: Inherits from TextPage
@@ -103,9 +118,11 @@ public partial class AboutPage : TextPage
103
118
}
104
119
```
105
120
106
-
## Extending
121
+
## Extending Models
122
+
123
+
Since models are partial classes, developers can extend them by adding additional properties.
107
124
108
-
Because a model is generated as a partial class, it is possible to extend it. That could be by adding a property, by dropping the following code in a `TextPage.cs` file:
125
+
For Example:
109
126
110
127
```csharp
111
128
publicpartialclassTextPage
@@ -114,17 +131,17 @@ public partial class TextPage
114
131
}
115
132
```
116
133
117
-
Models builder does not take a custom partial class into account when generating the models. This means that if a custom partial class, inherits from a base class, tries to provide a constructor with the same signature, or implements a generated property, it will cause compilation errors.
134
+
Models Builder does not recognize custom partial classes during regeneration. If your custom class conflicts with the generated class (e.g., overriding a constructor), it will cause compilation errors.
118
135
119
-
Furthermore a generated model will always be instantiated with its default constructor, so if an overloading constructor is created it will never be used.
136
+
Overloaded constructors will not be used because models are always instantiated using the default constructor.
120
137
121
-
For more complex partial classes, you'll have to use the full version of the[Models Builder](https://github.com/zpqrtbnk/Zbu.ModelsBuilder).
138
+
For more complex customizations, use the full version of [Models Builder](https://github.com/zpqrtbnk/Zbu.ModelsBuilder).
122
139
123
-
## Best Practices
140
+
## Best Practices for Extending Models
124
141
125
-
Extending models should be used to add stateless, local features to models, and *not* to transform *content* models into view models or manage trees of content.
142
+
Extending models should be used to add stateless, local features to models. It should not be used to transform *content* models into view models or manage trees of content.
126
143
127
-
### Example of good practice
144
+
### Good practices
128
145
129
146
A customer has "posts" that has two "release date" properties. One is a true date picker property and is used to specify an actual date and to order the posts. The other is a string that is used to specify dates such as "Summer 2015" or "Q1 2016". Alongside the title of the post, the customer wants to display the text date, if present, else the actual date. If none of those are present, the Umbraco update date should be used. Keep in mind that each view can contain code to deal with the situation, but it is much more efficient to extend the `Post` model:
130
147
@@ -151,7 +168,7 @@ A customer has "posts" that has two "release date" properties. One is a true dat
151
168
}
152
169
```
153
170
154
-
And to simplify the view as:
171
+
Simplified view:
155
172
156
173
```csharp
157
174
<div class="title">
@@ -160,13 +177,12 @@ And to simplify the view as:
160
177
</div>
161
178
```
162
179
163
-
### Example of bad practice
180
+
### Bad practices
164
181
165
182
Because, by default, the content object is passed to views, one can be tempted to add view-related properties to the model. Some properties that do *not* belong to a *content* model would be:
166
183
167
-
* A `HomePage` property that would walk up the tree and return the "home page" content item
168
-
* A `Menu` property that would list the content items to display in a top menu
169
-
* Etc.
184
+
* A `HomePage` property that retrieves the "home page" content item.
185
+
* A `Menu` property that lists navigation items.
170
186
171
187
Generally speaking, anything that is tied to the current request, or that depends on more than the modeled content, is a bad idea. There are much cleaner solutions, such as using true *view model* classes that would be populated by a true controller and look like:
172
188
@@ -179,17 +195,17 @@ public class TextPageViewModel
179
195
}
180
196
```
181
197
182
-
One can also extend Umbraco's views to provide a special view helper that would give access to important elements of the website, so that views could contain code such as:
198
+
One can also extend Umbraco's views to provide a special view helper that gives access to important elements of the website:
Thescopeandlife-cycleofamodelis*notspecified*. Inotherwords, youdon't know whether the model exists only for you and for the context of the current request, or if it is cached by Umbraco and shared by all requests.
206
+
Themodel's scope and lifecycle are *unspecified*. It may exist only for your request or be cached and shared across all requests.
0 commit comments