Mendix Intermediate Developer cheat sheet

Persistable entities map to database tables and receive system attributes (ID, CreatedDate, ChangedDate, ChangedBy, Owner); non-persistable entities exist only in runtime memory.

Attribute types: AutoNumber, Binary, Boolean, Date (with optional localization), Decimal, Enumeration, Hash, Integer, Long, and String with a maximum length.

Associations are references (1-1, 1-*, *-1) or inheritance; an association is owned by the entity it starts from, and delete behavior is configured on that side.

Many-to-many associations are not native: model a join entity with two 1-* associations, which can also carry attributes describing the relationship.

Delete behavior 'cascade' removes the referenced object when the owner is deleted; without cascade only the association link is removed.

Event handlers run on before/after create, commit, delete and rollback, and can change values or veto the operation by raising an error.

Validation rules include required, unique, range (min/max) and regular expression; required and unique are also enforced client-side where applicable.

Add an index to attributes used in XPath constraints or sorting; a unique index enforces uniqueness at database level rather than in application logic.

A generalized entity inherits attributes, associations, event handlers, indexes and access rules from its parent entity.

Microflows execute server-side inside a database transaction and can retrieve persistent data; nanoflows execute in the browser and support offline apps.

Core activities: Create object, Change object, Retrieve, Delete object, Commit, Rollback, Decision, Loop, Merge, Call microflow, Show page, Show message, Log message.

Retrieve options: all objects, an XPath/database constraint, or an association path from a known object; the range (offset and amount) limits the result set.

Commit with events triggers event handlers and validation; Commit without events writes directly to the database; 'Refresh in client' reloads the object on the page.

An unhandled error rolls back the microflow's uncommitted changes; error events can be raised with type Error, Warning or Information and a custom message.

Boundary error events attached to activities, calls or loops catch exceptions and offer rollback, continue, or open a custom error page.

List operations: Create list, Add to list, Remove from list, Change list, List operation (union, intersect, subtract, contains, range, head, tail) and Aggregate list.

Loop over list exposes each item as a variable; while loops evaluate a condition each iteration, and break/continue can be configured on loops.

Microflow properties include return type, 'Apply entity access', 'Mark as stateless', and access rules bound to module roles.

Page building blocks: layout (defines placeholders), template, snippet (reusable fragment), building block, and data container widgets.

A data view binds exactly one object; list view, data grid and gallery bind a list; page parameters pass objects into pages and snippets.

Data source options: database (XPath), microflow, nanoflow, association, listen to widget, and context.

Nanoflows run in the browser, can call microflows, perform client-side calculations, and are required for offline-capable logic.

Visibility and editability accept expressions such as $currentObject/Status = 'Open', which are evaluated in the browser, not on the server.

Widget events: On click (microflow, nanoflow, open page, show message, sign out, close page), On change, and On enter/leave.

Pluggable widgets from the Marketplace extend client-side behaviour; Atlas UI supplies the default layouts, styling and building blocks.

A microflow used as a page data source must return a list, and the page's users need access to that microflow through their module roles.

Security levels: Off (no checks), Prototype/Demo (demo users, most rules unenforced) and Production (all access rules enforced).

App security defines user roles; each user role aggregates one or more module roles, and the module roles carry the actual permissions.

Entity access rules grant create, read, write and delete per attribute and association, and may include an XPath constraint that filters readable rows.

Page access is granted per module role; a user without access to a page cannot open it, even through microflow navigation.

Microflow and nanoflow access rules list the allowed module roles; a microflow without any access rule is callable by all users.

The Anonymous user role governs unauthenticated visitors; login behaviour, password policy and session timeout are configured in app security.

When 'Apply entity access' is enabled on a microflow, it enforces entity access restrictions for the objects it retrieves and creates.

Published REST and SOAP operations require configured authentication and run with the rights of the mapped user or module role.

Call REST service sends GET/POST/PUT/PATCH/DELETE requests with URL, query parameters, headers, authentication and body; the response body, status code and headers become variables.

The REST response body can be kept as a string or transformed with an import mapping into Mendix objects and lists.

Import mappings convert JSON/XML into entities and export mappings convert entities into JSON/XML; mapping can be automatic or matched by name.

A published REST service defines resources with operations (HTTP method plus path) bound to microflows, together with import/export mappings.

Consumed web services come from importing a WSDL, which generates XML schemas and message definitions used by a call activity in a microflow.

Published web services (SOAP) expose microflows with XML message definitions, and operations can be versioned.

Consumed REST authentication options: none, basic, custom header/API key, and OAuth 2.0 flows such as client credentials and authorization code.

Published REST authentication options include no authentication, basic with module roles, custom microflow-based checks, and active session.

Outgoing request timeouts and proxy settings are configured in the app runtime settings, not only per activity.

A Java action extends CustomJavaAction and implements executeAction; parameters declared in the modeler appear in the generated proxy class.

Entity parameters arrive as IMendixObject; generated proxy classes expose typed getters and setters that wrap the same runtime object via getMendixObject().

Core methods handle runtime operations: Core.create, Core.retrieveId, Core.retrieveXPathQuery, Core.commit, Core.rollback, Core.delete.

Core.microflowCall("Module.Microflow").withParam(name, value).execute(context) invokes a microflow from Java code.

Exceptions thrown in Java surface as errors in the calling microflow and can be caught with a boundary error event.

Java actions are server-side only: they cannot access browser APIs and are unavailable to offline-first client logic.

Third-party jars belong in the project userlib folder or a module's dependency list and are packaged into the deployment package.

Java actions need access rules when callable from the client, and should use Core.getLogger for logging consistent with the runtime log.

Repositories live on Mendix Team Server (Git-based) or another Git server; Studio Pro supports commit, update, revert, branch line and merge.

A deployment package holds the compiled model, custom Java and dependencies, and is built from a specific revision of the repository.

Mendix Cloud environments typically include Acceptance and Production per licensed node, in addition to local development in Studio Pro.

Constants can be overridden per environment in the cloud portal, letting one package point at different endpoints, credentials or feature flags.

Run locally uses a local database on the developer machine; Run in cloud deploys a built package to the selected environment.

On startup Mendix synchronizes the database schema with the model; incompatible changes fail and require a clean database or manual migration.

Transporting a package moves the built artifact, not the source model; every new change requires a new commit and a new build.

The cloud portal provides logs, metrics, backups, and environment settings such as Java heap size and extra JVM parameters.

Index attributes used in XPath constraints, sorting and association paths; without an index the database performs a full table scan.

Set the retrieve range (offset and amount) and use XPath filters instead of retrieving all objects and filtering inside a microflow.

Avoid retrieving inside a loop (N+1 queries); retrieve the full list in one query or use an association-based retrieve from a known object.

Mark microflows stateless where possible and avoid storing large object lists in session variables.

The MxAssist Performance Bot flags anti-patterns such as retrieve-in-loop, unnecessary commits and missing indexes.

Log with appropriate levels (trace, debug, info, warning, error, critical) using Log message activities or Java logging; view them per environment in the cloud portal.

The debugger supports breakpoints and step over/into to inspect variables, and can attach to cloud environments as well as local runs.

Typical runtime errors: stale objects (object was deleted), security errors from missing entity access, and timeouts or heap exhaustion from long-running microflows.