Fill the demo data in SAIL on click of a Button.

Hi Ram,
You can still pass the data from the process and on click of a button you can fill those data across the form fields -OR- you can simply use a local variable and simply define the value inline.
First you need to create a local variable that is used to fill out the form and assign the process variable (option#1) or defined local variable (option#2) to the local variable (used to fill out the form) in the saveInto of the buttonWidget.

Here is how the form definition should look like for option#1.

load(
local!formData,

a!formLayout(
label: "Registration form",
contents: {
a!textField(
label: "Name",
value: local!formData.name,
saveInto: local!formData.name
),
a!textField(
label: "DoB",
value: local!formData.dob,
saveInto: local!formData.dob
)
},
buttons: a!buttonLayout(
primaryButtons: {
a!buttonWidget(
label: "Fill",
style: "PRIMARY",
submit: false,
saveInto: {
a!save(
local!formData,
ri!cdt
)
}
)
}
)
)
)

Hi Ram,

I do something similar for demos. There are a few different methods I've used:

load(
  local!demoData,
  a!formLayout(
    label: "Demo",
    contents: {
      a!sectionLayout(
        contents: {
          /*Populate from a button anywhere in the content*/
          a!buttonLayout(
            primaryButtons: {
              a!buttonWidget(
                label: "From Content Button",
                style: "PRIMARY",
                submit: false,
                saveInto: {
                  a!save(
                    local!demoData,
                    {
                      field1: "field1FromContentButton",
                      field2: "field2FromContentButton",
                      field3: "field3FromContentButton"
                    }
                  )
                }
              )
            }
          ),
          /*Populate from dynamic link*/
          a!linkField(
            label: "Link Field",
            links: a!dynamicLink(
              label: "From Dynamic Link",
              saveInto: {
                a!save(
                  local!demoData,
                  {
                    field1: "field1FromDynamicLink",
                    field2: "field2FromDynamicLink",
                    field3: "field3FromDynamicLink"
                  }
                )
              }
            )
          ),
          a!textField(
            label: "Field 1",
            value: local!demoData.field1,
            saveInto: local!demoData.field1
          ),
          a!textField(
            label: "Field 2",
            value: local!demoData.field2,
            saveInto: local!demoData.field2
          ),
          a!textField(
            label: "Field 3",
            value: local!demoData.field3,
            saveInto: local!demoData.field3
          )
        }
      )
    },
    /*Populate demo data from form button*/
    buttons: a!buttonLayout(
      primaryButtons: {
        a!buttonWidget(
          label: "From Form Button",
          style: "PRIMARY",
          submit: false,
          saveInto: {
            a!save(
              local!demoData,
              {
                field1: "field1FromFormButton",
                field2: "field2FromFormButton",
                field3: "field3FromFormButton"
              }
            )
          }
        )
      }
    )
  )
)

I will suggest you better solution for demo.
On form load pull old data from db and initialize local variable and on save into of first field initialize ri!varible(CDT type) and remaining value gets auto fill with respective field and value.
No need to click on button. 

HI,

I am describing a method to populate demo data.

1. Create a local variable in load() in SAIL code. It can be a CDT or a dictionary (adhoc data structure). Example: local!formData 
2. Have a rule input of the same datatype to this SAIL interface. This has to be of same type as the variable created in #1
3. Assign the demo data (form data to this variable) by binding to rule input variable created in #2. Example: first textbox can be bound to ri!formData.name, second textbox to ri!formData.age etc. This will ensure that when the form is first opened it will be blank.
4. Have a button which when clicked will assign the local variable created in #1 to the rule input created in #2. Say the button name is "Populate data". In this button, have a saveInto. In the saveInto, you can save the local variable created in #1 to the rule input created in #2. You will use the a!save() function for this. Example: a!save(ri!formData, local!formData)

Once the user clicks on the "Populate data" button, the demo data will be populated.

The above method I have suggested does not require any database data or process data.
We are simply using local variables.

In fact - this is also a good way to prototype SAIL forms and test them as you are developing them.
You can start developing SAIL forms before the related process models/CDTs are created/database schema is finalized using this method.

There is no need to create the rule to return CDT value
local variable in load created with type constructor should be fine.
If say CDT is Employee, you can create local variable of type Employee like this:

load(

local!anEmployee: type!Employee( id: 123, name: abc, /*rest of CDT fields and values */ )

/*rest of the code */
)

Note: if CDT is not created, you can use the dictionary (adhoc structure). Even CDT is not a must.


And then you can save it in rule variable when the button is clicked.

In actual implementation - 90% of the times the data comes from rule inputs which come from activity class parameters of the user input task in the process model.
The additional rule creation step that you have mentioned is just returning you a CDT.

Please go through the approach I have suggested, in my approach I am already specifying to use the rule input of type CDT/dictionary.
It is just the source of inputs to the SAIL components which in real projects also comes from rule input variables (and not expression rules).

Now those rule input variables are passed by the caller (which maybe a user input task, another parent expression rule/a parent SAIL interface etc.)

It's up-to the caller to decide what and how to pass the rule inputs (any of the above methods).

You never know in advance how it will be called in a real project implementation.

So - creating an expression rule for just returning a test CDT instance offers no advantage.