Mendix Rapid Developer cheat sheet

Studio Pro is the desktop IDE; the Developer Portal (web) hosts apps, team, and environment management - the two are complementary, not interchangeable.

A Mendix app version is defined by its Mendix Studio Pro version; opening an app requires a Studio Pro version equal to or newer than the one recorded in the project.

App roles in the Developer Portal: App Admin (full control incl. members and environments), App Team Member (build access), and end users who only consume the deployed app.

The Project Explorer organizes modules; each module contains a domain model, pages, microflows, nanoflows, and can be exported as a module for reuse.

Mendix Model SDK and the Mendix Platform SDK allow programmatic model changes and automation; the Model SDK works on a local MPK/app model, the Platform SDK on Team Server APIs.

Studio Pro keyboard shortcuts: F4 opens the Toolbox, F8 runs the app, Ctrl+F searches the model, Ctrl+Shift+F searches across the project.

The Mendix Runtime executes microflows; the Client (browser) executes nanoflows and page logic; offline apps run nanoflows locally with a local database.

Marketplace content (modules, widgets) is downloaded into the project; modules become project dependencies and are versioned per module.

Entities are persistent by default; non-persistent entities exist only in memory and are not stored in the database.

Attribute types: String, Integer, Long, Decimal, Boolean, DateTime, Enumeration, AutoNumber, Binary, Hashed String, and (with modules) String with unlimited length.

Associations: reference (single) vs reference set (many); ownership determines which side stores the foreign key and whether the association is stored in the database.

Delete behavior on associations: 'Delete' cascades deletion of the referenced object, 'Remove' only removes the reference, 'No action' leaves orphan references.

System attributes (Owner, CreatedDate, ChangedDate, ChangedBy) come from the System module and are populated automatically for persistent entities.

Generalization allows an entity to inherit attributes and associations from a parent entity; the child can be queried as the parent.

Calculated attributes are computed by an expression or microflow and are not stored; event handlers (Before/After Create/Commit/Delete) run microflow logic on persistence events.

Indexes on attributes speed up XPath queries; add indexes on attributes used frequently in XPath constraints or sort orders.

Layouts define the shell (header, sidebar, content placeholder); a page selects a layout and populates placeholders.

Snippet = reusable UI fragment embedded in pages; can be parameterized and shared across modules.

Building blocks and page templates are prebuilt UI patterns from the Marketplace/Atlas UI; they instantiate widgets but are not runtime components.

Data sources for a data view/list: database (XPath or microflow), microflow, nanoflow, association, or selection.

Widgets commonly used: Data view (single object), Data grid/List view (collection), Input widgets (text, date, enum), and Action buttons (microflow, nanoflow, page, delete).

Pluggable widgets extend the widget set; they are built with the Mendix Web Widget framework and require a compatible Studio Pro version.

Page parameters pass context between pages; a page opened with an object parameter receives that object as its data context.

Native mobile pages differ from web pages: they use native widgets and a native navigation profile; web and native pages can coexist in one app.

Microflow activities: variable operations, object operations (create/change/delete/retrieve), decisions, loops, and calls (microflow, nanoflow, Java action, REST/SOAP).

Microflow parameter types include entities, primitives, lists, and objects; return type must match the declared return type.

Error handling: error events with custom handlers (continue, rollback, custom) and the 'Raise error' activity; unhandled errors roll back the transaction.

Microflows run in a transaction; commit boundaries are explicit - objects not committed are discarded if the transaction rolls back.

Loops iterate over a list; nested loops change complexity dramatically - prefer XPath or aggregate activities where possible.

Nanoflows run client-side and cannot use Java actions, commit objects to the database directly, or call microflows that require server context; they can call microflows.

Java actions extend microflows with custom Java code; they are compiled into the app and can access the Mendix Runtime API.

Microflow expressions support functions like toString, parseInteger, formatDateTime, and XPath-based retrieve; expressions are typed and case-sensitive.

Security levels: Off, Prototype/Demo (no login enforcement), and Production (enforced login, role-based access).

Module roles define permissions inside a module; user roles map module roles to app users; a user can have multiple user roles.

Entity access rules define create/read/write/delete per module role; XPath constraints on access rules restrict which objects a role can see or modify.

Microflow access is set per module role (allowed or not); page access likewise; a user without access cannot execute or open the resource.

The System.User entity holds user accounts; System.UserRole is the base for app-specific user roles; password policy is configured in Project Security.

Anonymous users exist only when 'Allow anonymous users' is enabled; they receive the Anonymous user role and no login is required.

Entity access 'read' restrictions apply to XPath retrieval and data views; a user cannot retrieve objects outside their allowed XPath constraint.

Security is enforced server-side; client-side widget visibility is a UX aid, not a security boundary - restrict data in access rules.

Consumed REST: define a REST call in a microflow with a base URL, method, headers, query parameters, and a response handler; responses can be mapped to entities.

Published REST: expose microflows as REST operations with a path, HTTP method, and request/response mapping; authentication via basic auth or custom microflow.

Consumed SOAP: import a WSDL to generate a service and operations; the generated microflow calls the operation and maps the response.

Published SOAP: expose microflows as SOAP operations with a WSDL generated from the model.

Import/export mappings translate between XML/JSON and Mendix entities; they support inheritance and nested structures.

REST response mapping supports JSON with 'Import mapping' or direct expression; errors return HTTP status codes configurable in the operation.

Authentication for consumed services: none, basic, or custom (e.g., OAuth token via a microflow); secrets should be stored in constants, not hard-coded.

Web services can be called from microflows; timeouts and error handling should be defined per call to avoid blocking the runtime.

XPath constraints filter entity retrieval: [Attribute = 'value'], [Attribute > 5], and association paths like [Module.Association/Module.Entity/Attribute = 'x'].

XPath functions: contains(), starts-with(), ends-with(), not(), and boolean operators and/or; comparisons are case-sensitive unless using contains with exact case.

Retrieve activities accept an XPath constraint; an empty constraint retrieves all objects the user is allowed to see.

Validation rules on attributes (required, unique, range, regex) run on commit; 'required' blocks commit of null values.

Event handlers (Before/After Create/Commit/Delete) are microflows attached to an entity; they run on commit/delete and can raise errors to block the operation.

Validation feedback activity displays messages on input widgets; it requires the widget to be bound to the validated attribute.

Unique constraints are enforced at the database level; a duplicate commit raises an error that must be handled in the microflow.

XPath 'id' token: [id = $objectId] can be used to retrieve by object ID; object IDs are unique within the app.

Environments: Development (free, sleeps after inactivity), Acceptance, and Production; each environment has its own database and configuration.

Deploying from Studio Pro to a cloud environment uses 'Run' or 'Deploy for Eclipse'; the Developer Portal manages environment settings and constants.

Version control: Mendix uses Team Server (Git-based); branches isolate work, and merging back to the main line is required before deployment.

Model changes are committed as revisions; a revision must be committed before deploying to an environment.

Constants can be environment-specific; the Developer Portal overrides constant values per environment.

The Mendix Runtime runs on Java; the cloud environment is managed, while on-premises deployments use the Mendix Runtime distribution.

Database: cloud environments use a managed PostgreSQL database; on-premises can use PostgreSQL, SQL Server, or Oracle.

Backups and restore are managed per environment; production data is not automatically copied to acceptance - use a data snapshot or export.

Team Server hosts the Git repository and the team; each developer has a personal branch and merges via the portal or Studio Pro.

Sprint planning uses the Developer Portal's Stories (user stories) with story points, status, and acceptance criteria.

Feedback widget lets end users submit feedback with a screenshot and context; feedback items appear in the Developer Portal for triage.

Branches: main line is typically 'main'; feature branches are created per story and merged back after review.

The Developer Portal shows team activity, commits, and burndown; the burndown chart reflects story points completed per sprint.

Code review is done via merge requests on the Team Server; reviewers inspect model changes before merging.

Feedback items can be converted to stories; they carry the page context and user information for reproduction.

Version control conflicts occur when the same document is edited on two branches; resolve by merging in Studio Pro before committing.

The App Explorer groups modules, and each module shows Domain Model, Pages, Microflows, Nanoflows, and Resources.

The Toolbox (F4) lists available widgets for the current page or snippet; the Properties pane edits the selected element.

The Errors pane lists model errors; the app cannot run while errors remain.

The 'Find Advanced' dialog (Ctrl+Shift+F) searches across the whole project, including microflow activities and XPath.

Consistency errors block deployment; warnings do not, but should be reviewed before release.

Use a non-persistent entity for transient UI state (e.g., a form object) that should not be stored in the database.

Use a reference set when an object can be associated with many objects; use a reference for a single association.

Set association ownership on the side that logically owns the relationship; only the owner stores the foreign key.

Deleting an object with a 'Delete' association cascades; use 'Remove' to preserve the referenced object.

A data view requires a data source; a data grid/list view requires a collection data source and supports search, sort, and paging.

Use a snippet for UI reused on multiple pages; changes to the snippet propagate to all pages using it.

Page parameters are passed via the 'Open page' action; the target page must declare a matching parameter.

Native pages use native widgets and a native navigation profile; they cannot use web-only widgets.

A decision splits the flow into true/false branches; both branches must merge or end in an end event.

A loop iterates a list; use 'Aggregate list' for sum/count/average instead of a loop where possible.

The 'Retrieve' activity can retrieve by association, by XPath, or from a microflow/nanoflow.

Microflow return values must match the declared return type; a missing return path is a consistency error.

Security must be set to Production to enforce login; Prototype/Demo allows anonymous access for testing.

Module roles are assigned to user roles; a user role inherits the permissions of its module roles.

Entity access rules are per module role; no rule means no access for that role.

Page and microflow access are separate from entity access; all three must permit the action.

Use a consumed REST call for JSON APIs; use a consumed SOAP service when a WSDL is provided.

Import mappings map JSON/XML to entities and support nested objects and inheritance.

Published REST operations are defined on microflows; the path and method define the endpoint.

Store service credentials in constants so they can be overridden per environment.

XPath association path: [Module.Association/Module.Target/Attribute = 'value']; the association name links the two entities.

Use contains() for substring matching; use starts-with() for prefix matching; both are case-sensitive.

Validation rules run on commit; 'required' prevents null; 'unique' is enforced by the database.

Event handlers run on create/commit/delete; raising an error in a Before handler blocks the operation.

A revision must be committed before deploying; uncommitted changes cannot be deployed.

Each environment has its own database and constants; production data is not shared with acceptance by default.

Branches isolate work; merge to the main line before deploying to production.

Cloud environments sleep after inactivity; the first request after sleep has a cold-start delay.

Stories carry acceptance criteria, story points, and status; the burndown uses story points completed per sprint.

Feedback items are captured with page context and can be converted into stories.

Merge requests enable code review before merging a branch into the main line.

Version control conflicts occur when the same document is edited on two branches; resolve by merging in Studio Pro.