---
schema_version: "1"
id: 07866b880883bd116a42be24c31a79e79c541abafcba4c60dcd787e0d556ad99
title: Customizing the Parameters DSL
collection: mulesoft
version: current
locale: en-us
portal_url: https://docs.salesforce.com/mulesoft/current/en-us/mule-sdk/latest/parameters-dsl.md
canonical_url: https://docs.mulesoft.com/mule-sdk/latest/parameters-dsl
source_site: docs.mulesoft.com
content_type: documentation
content_hash: 683ea8113def6f330e1343756095130b53ae6d6710c5929abbdc3fca8abf5ae0
description: MuleSoft Documentation Site
release: "1.13"
latest: true
---
---
product: Mule SDK
version: 1.13
is-latest-version: true
keywords: parameter, parameters, mule, sdk, dsl, xml, syntax
---

# Customizing the Parameters DSL

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

To provide the best possible experience for the user, customize or limit some aspects of a
component’s parameters. For example, you can hide irrelevant parameters for clarity.

## Receiving Strings As Reference Or As Value

Let’s say we have an operation like the following:

```java
public void send(@Connection MyConnection connection, Object value) {
    connection.doSend(value);
}
```

Which will be invoked like this:

```xml
<demo:send value="requestPayload"/>
```

By default, Mule assumes that `requestPayload` is a reference to an object in the registry, like a
global list or POJO. If instead we want the extension to actually receive the `requestPayload`
string, we must modify the operation declaration, using the `@ParameterDsl` annotation:

```java
public void send(@Connection MyConnection connection, @ParameterDsl(allowReferences = false) Object value) {
    connection.doSend(value);
}
```

This change explicitly disables the use of references, so the operation will receive the string
value.

## Defining How Complex Types Can Be Used

Any Module is able to expose POJOs that conform to the Module API:

```java
// This is the POJO declaration
public class Door {

  @Parameter
  private boolean isLocked;

  @Parameter
  private String color;

}

// This is the configuration
public class HouseConfig {

  @Parameter
  private Door mainDoor;

}
```

When having this kind of parameters, the Module developer has the responsibility to configure how
the `Door` can be used in the DSL. For this, we have the `@TypeDsl` annotation, that allows you to
configure two important things:

- `allowInlineDefinition`: Defines if the POJO (in the example, the `Door`) can be declared inline
  for the element that uses it as parameter. If this value is `true`, then the user can declare:

  ```xml
  <demo:config name="myConfig"> (1)
      <demo:door isLocked="true" color="red"/> (2)
  </demo:config>
  ```

  <table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>The config is declared as the container of the parameter</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>A <code>Door</code> is declared inline (in the <code>config</code>)</td></tr></tbody></table>

- `allowTopLevelDefinition`: Defines if the POJO (in the example, the `Door`) can be declared as a
  top-level element in the application. If this value is `true`, then the user can declare:

  ```xml
  <demo:door name="MyGlobalDoor" isLocked="true" color="red"/> (1)

  <demo:config name="myConfig" door-ref="MyGlobalDoor"/> (2)
  ```

  <table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>A <code>Door</code> is declared as a global element of the application</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>The <code>config</code> is declared separately, referencing the global <code>Door</code> element by name with the <code>door-ref</code> attribute</td></tr></tbody></table>