Merge branch 'development' into yl-proofread-microflow-and-nanoflow-documentation

Author: Yiyun333

content/en/docs/deployment/mendix-cloud-deploy/_index.md

@@ -62,7 +62,7 @@ There are two ways to prevent your Free App from being archived:
 * Visit the Free App
 * Deploy a new version of your app to your Free App environment
 
-#### Deletion of Unused Projects (#projects-deletion)
+#### Deletion of Unused Projects {#projects-deletion}
 
 If a project has never seen any activity since it was created, it is kept on the Team Server for a maximum of one year. After this, the project on the Mendix Platform, its repository on the Team Server, and any Mendix Cloud resources will be permanently deleted.
 

content/en/docs/refguide/mobile/getting-started-with-mobile/prerequisites.md

@@ -5,6 +5,7 @@ url: /refguide/mobile/getting-started-with-mobile/prerequisites/
 weight: 10
 description: Troubleshoot common issues associated with building and running native mobile apps.
 aliases:
+    - /refguide/mobile/distributing-mobile-apps/building-native-apps/how-to-min-versions/
     - /refguide/getting-the-make-it-native-app/
     - /howto/mobile/common-issues/
 ---

content/en/docs/refguide/modeling/application-logic/microflows-and-nanoflows/nanoflows/_index.md

@@ -8,7 +8,7 @@ description: "Presents an overview of all the elements that can be used in a nan
 
 ## Introduction
 
-Nanoflows are similar to [microflows](/refguide/microflows/), in that they allow you to express the logic of your application. However, they do have some specific benefits. For example, they run directly on the browser/device and can be used in an offline app. Furthermore, most of the actions run directly on the device. Hence, there is also a speed benefit for logic which does not need access to the server. For more information on how nanoflows and microflows differ, see the [Differences between Microflows and Nanoflows](/refguide/microflows-and-nanoflows/#differences) section in *Microflows and Nanoflows*.
+Nanoflows are similar to [microflows](/refguide/microflows/), in that they allow you to express the logic of your application. However, they do have some specific benefits. For example, they run directly on a browser/device and hence can be used in an offline app. Furthermore, since most of the activities run directly on the device, there is also a speed benefit for logic which does not need access to the server. For more information on how nanoflows and microflows differ, see the [Differences between Microflows and Nanoflows](/refguide/microflows-and-nanoflows/#differences) section in *Microflows and Nanoflows*.
 
 This page is an overview of all the elements that can be used in a nanoflow. For the properties of the nanoflow itself, see [Nanoflow Properties](/refguide/nanoflow/). 
 
@@ -18,28 +18,32 @@ For information on using nanoflows as data sources, see [Nanoflow Source](/refgu
 
 ### Offline Mobile Apps
 
-Nanoflows are designed with offline-first applications in mind, as they allow you to model application logic that works in offline apps. Since all database-related actions are executed on the local offline database, nanoflows in offline apps are fast.
+Nanoflows are designed with offline-first applications in mind, as they allow you to model application logic that works in offline apps. Since all database-related activities are executed on the local offline database, nanoflows in offline apps are fast.
 
 ### Logic Where No Connection Is Needed
 
-Nanoflows also offer great value to online applications (for example, for UI logic, validations, calculations, and navigation). However, keep in mind that when you perform database-related actions, each action will create a separate network request to the Mendix Runtime.
+Nanoflows also offer great value to online applications (for example, for UI logic, validations, calculations, and navigation). However, keep in mind that when you perform database-related activities, each activity creates a separate network request to the Mendix Runtime.
 
-The following actions interact with the database:
+The following activities interact with the database:
 
-* Create
-* Commit
-* Retrieve
-* Rollback
+* [Create object](/refguide/create-object/)
+* [Commit object(s)](/refguide/committing-objects/)
+* [Retrieve](/refguide/retrieve/)
+* [Rollback object](/refguide/rollback-object/)
 
-Therefore, the best practice is to use nanoflows in online applications when they do not contain the above actions.
+Therefore, the best practice is to use nanoflows in online applications when they do not contain the above activities.
 
 {{% alert color="info" %}}
-Changing objects without committing is not a database-related action, as changes are applied on the device or in the browser.
+An exception for the **Create object** activity is that you can use it to create a new [non-persistable entity](/refguide/persistability/#non-persistable), and this NPE has no error handlers, calculated attributes, or read-only attributes. In this case, no request is sent to the Mendix Runtime.
+{{% /alert %}}
+
+{{% alert color="info" %}}
+Changing objects without committing is not a database-related activity, as changes are applied on the device or in the browser.
 {{% /alert %}}
 
 #### Other Cases
 
-Nanoflows perform best in online applications when no database-related actions are used, which are generally the best cases. However, nanoflows containing at most one database-related action can still perform well. Since such nanoflows only require one network call, they perform as efficiently as a microflow. An example of this is performing validation logic on an object and committing the object in the same nanoflow.
+Nanoflows perform best in online applications when no database-related activities are used, which are generally the best cases. However, nanoflows containing at most one database-related activity can still perform well. Since such nanoflows only require one network call, they perform as efficiently as a microflow. An example of this is performing validation logic on an object and committing the object in the same nanoflow.
 
 ## Notation and Categories
 

content/en/docs/refguide/modeling/domain-model/generalization-and-association.md

@@ -69,7 +69,7 @@ Making a decision between inheritance and associations is something you should d
 
 ### Inheritance
 
-Using inheritance can make your microflows easier to maintain, you can re-use functionality. However, you do lose flexibility. Once you have applied inheritance to an entity it is difficulty to remove the inheritance and keep all the data using a relationship. Take into account whether a record can change type of subclass, for example an employee specialization object changes and becomes a project manager object. In most scenarios there is no perfect solution and there are always concessions to make, just be aware of the implications when making a choice.
+Using inheritance can make your microflows easier to maintain, you can re-use functionality. However, you do lose flexibility. Once you have applied inheritance to an entity it is difficult to remove the inheritance and keep all the data using a relationship. Take into account whether a record can change type of subclass, for example an employee specialization object changes and becomes a project manager object. In most scenarios there is no perfect solution and there are always concessions to make, just be aware of the implications when making a choice.
 
 Don't just add inheritance because it is easier, or remove it because it is slower. Especially in scenarios where different object types have to go through a similar process, it can be worthwhile to apply inheritance just so you can re-use functionality and increase the consistency and stability of your application.
 

content/en/docs/refguide9/modeling/integration/odata-services/wrap-services-odata.md

@@ -149,27 +149,27 @@ The following examples are possible ways to use OData to connect to external dat
 
 You can use the features released in Studio Pro [9.17](/releasenotes/studio-pro/9.17/) to build a connector that wraps a third-party service API as OData. 
 
-For example, say you want to build an app that works with the [Twitter v2 REST API](https://developer.twitter.com/en/docs/twitter-api/getting-started/about-twitter-api). You would like a simple app where you can enter the ID of a Twitter user and view their latest tweets and followers. 
+For example, say you want to build an app that works with the [X v2 REST API](https://developer.x.com/en/docs/x-api/getting-started/about-x-api). You would like a simple app where you can enter the ID of an X user and view their latest tweets and followers. 
 
 {{% alert color="info" %}}
-This guide is meant to serve as an example to show how to use *Connector Kit 2* features, and is not an official guide to building a Twitter connector. It is intended for local deployments and has not been tested.{{% /alert %}}
+This guide is meant to serve as an example to show how to use *Connector Kit 2* features, and is not an official guide to building an X connector. It is intended for local deployments and has not been tested.{{% /alert %}}
 
 {{% alert color="warning" %}}
-On February 9, 2023, Twitter will drop support for free API access and will offer a paid basic version instead. Please use the guide below as a reference only.
+On February 9, 2023, X will drop support for free API access and will offer a paid basic version instead. Please use the guide below as a reference only.
 {{% /alert %}}
 
 #### Prerequisites
 
 To build your app, you first need to do the following:
 
-* [Register as a Twitter Developer](https://developer.twitter.com/en/portal)
+* [Register as an X Developer](https://developer.x.com/en/portal)
 * Download Studio Pro [9.17](/releasenotes/studio-pro/9.17/) or above
 
-#### Building the Connector {#twitter-connector}
+#### Building the Connector {#x-connector}
 
-Set up a connector module that communicates to the Twitter API with OData by following the steps outlined below. To ensure that your app will run, fill in your valid bearer token as the **Default value** in a **BearerToken** [constant](/refguide9/constants/). You can get one by [registering as a Twitter Developer](https://developer.twitter.com/en/portal).
+Set up a connector module that communicates to the X API with OData by following the steps outlined below. To ensure that your app will run, fill in your valid bearer token as the **Default value** in a **BearerToken** [constant](/refguide9/constants/). You can get one by [registering as an X Developer](https://developer.x.com/en/portal).
 
-1. Use the Twitter API to find the JSON structures for the calls for users, tweets, and followers, and add the [JSON structure](/refguide9/json-structures/) for each.
+1. Use the X API to find the JSON structures for the calls for users, tweets, and followers, and add the [JSON structure](/refguide9/json-structures/) for each.
 2. Create [import mappings](/refguide9/mapping-documents/#import-mappings) for each, which generates entities in your domain model.
     {{< figure src="/attachments/refguide9/modeling/integration/wrap-services-odata/twitter-connector-domain-model.png" alt="Domain model for Twitter connector module." class="no-border" >}}
 3. Publish all three non-persistable entities as a published OData service (see [Non-Persistable Entities as Published OData Resources](#npe-published-odata)).
@@ -182,35 +182,35 @@ Set up a connector module that communicates to the Twitter API with OData by fol
 
 #### Building the Client
 
-Set up a Twitter client module that allows users to input a Twitter ID and communicates to the Twitter API via your [Twitter connector](#twitter-connector).
+Set up an X client module that allows users to input an X ID and communicates to the X API via your [X connector](#x-connector).
 
-1. Create a consumed OData service in the client module, and import the XML file you exported in the [building the connector](#twitter-connector) section.
+1. Create a consumed OData service in the client module, and import the XML file you exported in the [building the connector](#x-connector) section.
 2. Drag the external **Users**, **Tweets**, and **Followers** entities into your client domain model.
-3. Add a non-persistable entity for the TwitterClientInput to be able to fill in the data, handled by a **NewTwitterInput** microflow.
+3. Add a non-persistable entity for the XClientInput to be able to fill in the data, handled by a **NewXInput** microflow.
 
-    Double-click the entity, and in the **Persistable** field, choose **No**. The domain model for the Twitter client looks like this:
+    Double-click the entity, and in the **Persistable** field, choose **No**. The domain model for the X client looks like this:
 
-    {{< figure src="/attachments/refguide9/modeling/integration/wrap-services-odata/twitter-client-domain-model.png" alt="Twitter client domain model with external entities and non-persistable entity." class="no-border" >}}
+    {{< figure src="/attachments/refguide9/modeling/integration/wrap-services-odata/twitter-client-domain-model.png" alt="X client domain model with external entities and non-persistable entity." class="no-border" >}}
 
     {{< figure src="/attachments/refguide9/modeling/integration/wrap-services-odata/newtwitterinput-microflow.png" alt="Microflow that handles inputted usernames." class="no-border" >}}
 
 4. Add a new page to display the data, and create a ShowUserPage microflow.
 
-    The microflow includes a **Retrieve Object** action that pulls information from the **TwitterClientInput** non-persistable entity. In this case, you can use the XPath constraint [Username=$TwitterClientInput/Username] to get the users with the username you entered. This is then translated into an OData request that is sent to the connector.
+    The microflow includes a **Retrieve Object** action that pulls information from the **XClientInput** non-persistable entity. In this case, you can use the XPath constraint [Username=$XClientInput/Username] to get the users with the username you entered. This is then translated into an OData request that is sent to the connector.
 
     {{< figure src="/attachments/refguide9/modeling/integration/wrap-services-odata/showuserpage-microflow.png" alt="Microflow that handles TwitterClientInput request and shows a page." class="no-border" >}}
 
-5. On the **TwitterPage**, use a **Data Grid**, and pull data **by Association** from the to get the tweets and followers connected to the user.
+5. On the **XPage**, use a **Data Grid**, and pull data **by Association** from the to get the tweets and followers connected to the user.
 
 #### Parsing the URI
 
-Run the Twitter client to receive decoded OData requests. 
+Run the X client to receive decoded OData requests. 
 
 1. Manually parse the URI, and create a microflow to read data from the URI. 
     {{< figure src="/attachments/refguide9/modeling/integration/wrap-services-odata/read-uri-data.png" alt="Microflow that finds query parameter values." class="no-border" >}}
-2. Extract the Twitter user ID from the query, and use a **Call REST** object to ping the Twitter API for the followers (or other data). The API response goes into the import mapping.
+2. Extract the X user ID from the query, and use a **Call REST** object to ping the X API for the followers (or other data). The API response goes into the import mapping.
 
-Ensure that you have created microflows for all entities used in your connector. When you run your app, you can enter the ID of a Twitter user and view their latest tweets and followers.
+Ensure that you have created microflows for all entities used in your connector. When you run your app, you can enter the ID of an X user and view their latest tweets and followers.
 
 ## Updatable Operational Data Stores {#operational-data-stores}
 

content/en/docs/releasenotes/mobile/mendix-native-mobile-builder.md

@@ -11,7 +11,7 @@ The Mendix Native Mobile Builder is a UI-based tool, complimentary to Mendix Stu
 
 ## 2025
 
-### Release 1.0.132
+### Release 1.0.133
 
 **Release date: January 7, 2025**