Aikau 1.0.34 - Form Control Rule Evaluation Updates

cancel
Showing results for 
Search instead for 
Did you mean: 

Aikau 1.0.34 - Form Control Rule Evaluation Updates

Intermediate II
0 9 2,230

Introduction

In my last blog post I said that I would try and provide more frequent updates on Aikau. Just over a week has passed since then and we've released version 1.0.34 at the end of Sprint 34. We didn't deliver a huge amount as we only had 35% availability due to team members’ vacation but there was one addition that I thought was worth mentioning.

Form Control Rule Evaluation

We had a requirement from one the feature teams using Aikau to update the form controls to support OR based evaluation of the dynamic visibility, requirement and enablement behaviour. Previously we had only supported AND based evaluation such that all the configured rules needed to be true but the team wanted to be able to make a form field required if either one of two fields was not empty.

As an aside there was already a workaround to implement this using the “autoSetConfig” capabilities provided in forms to set the value of a hidden field and then use the value of that hidden field as the evaluated target for the rules. However, the updates we've since made are a much cleaner way of implementing the solution

The original dynamic rule capabilities are described in the Aikau tutorial on the GitHub repository so it is worth reviewing that chapter first if you’re not familiar with the concepts before you read on.

So for example you have three fields “accidents”, “convictions” and “details” and you want to ensure that if either “accidents” or “convictions” are indicated that the “details” must be provided. You can set up your basic form controls like this:

{
  id: 'ACCIDENTS',
  name: 'alfresco/forms/controls/RadioButtons',
  config: {
    fieldId: 'ACCIDENTS',
    name: 'accidents',
    value: 'NO',
    label: 'Previous accidents',
    description: 'Have you been involved in any previous accidents?',
    optionsConfig: {
      fixed: [
        { label: 'Yes', value: 'YES'},
        { label: 'No', value: 'NO'}
      ]
    }
  }
},
{
  id: 'CONVICTIONS',
  name: 'alfresco/forms/controls/RadioButtons',
  config: {
    fieldId: 'CONVICTIONS',
    name: 'convictions',
    value: 'NO',
    label: 'Previous Convictions',
    description: 'Do you have any previous convictions?',
    optionsConfig: {
      fixed: [
        { label: 'Yes', value: 'YES'},
        { label: 'No', value: 'NO'}
      ]
    }
  }
},
{
  id: 'DETAILS',
  name: 'alfresco/forms/controls/TextArea',
  config: {
    fieldId: 'DETAILS',
    name: 'details',
    label: 'Details',
    description: 'Please provide the details of your previous accidents and/or convictions'
  }
}

Previously if you’d configured the “requirementConfig” attribute so that the “details” field became required based on the values of the “accidents” and “convictions” fields you would have created the following:

requirementConfig: {
  initialValue: true,
  rules: [
    {
      targetId: 'ACCIDENTS',
      isNot: ['NO']
    },
    {
      targetId: 'CONVICTIONS',
      isNot: ['NO']
    }
  ]
}
‍‍‍‍‍‍‍‍‍‍‍‍‍

However, this would mean that the “details” field would only be required when both the 'accidents' field and the 'convictions' fields were both set to 'YES'. To resolve this you can now update the configuration with a new “rulesMethod” attribute.

requirementConfig: {
  initialValue: true,
  rulesMethod: 'ANY', // NOTE: This the key attribute!
  rules: [
    {
      targetId: 'ACCIDENTS',
      isNot: ['NO']
    },
    {
      targetId: 'CONVICTIONS',
      isNot: ['NO']
    }
  ]
}‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Summary

This demonstrates a few of the things we like about the Aikau framework. First of all we were able to make this change in a single module (alfresco/forms/controls/utilities/RulesEngineMixin) and this new capability was immediately available for all of the form controls.

It is also a completely backwards compatible change. If you didn't specific a “rulesMethod” attribute before then your form models will continue to work exactly as they did before. Our comprehensive unit test suites ensured that we didn't regress any of the existing functionality.

Finally it shows that we’re able to respond to requests as they arrive and to continue to iterate on existing code without needing to constantly re-invent the wheel.

So a full page example of this would be:

model.jsonModel = {
  services: [],
  widgets: [
    {
      id: 'FORM',
      name: 'alfresco/forms/Form',
      config: {
        okButtonPublishTopic: 'SAVE_FORM',
        okButtonLabel: 'Save',
        widgets: [
          {
            id: 'ACCIDENTS',
            name: 'alfresco/forms/controls/RadioButtons',
            config: {
              fieldId: 'ACCIDENTS',
              name: 'accidents',
              value: 'NO',
              label: 'Previous accidents',
              description: 'Have you been involved in any previous accidents?',
              optionsConfig: {
                fixed: [
                  { label: 'Yes', value: 'YES'},
                  { label: 'No', value: 'NO'}
                ]
              }
            }
          },
          {
            id: 'CONVICTIONS',
            name: 'alfresco/forms/controls/RadioButtons',
            config: {
              fieldId: 'CONVICTIONS',
              name: 'convictions',
              value: 'NO',
              label: 'Previous Convictions',
              description: 'Do you have any previous convictions?',
              optionsConfig: {
                fixed: [
                  { label: 'Yes', value: 'YES'},
                  { label: 'No', value: 'NO'}
                ]
              }
            }
          },
          {
            id: 'DETAILS',
            name: 'alfresco/forms/controls/TextArea',
            config: {
              fieldId: 'DETAILS',
              name: 'details',
              label: 'Details',
              description: 'Please provide the details of your previous accidents and/or convictions',
              requirementConfig: {
                initialValue: true,
                rulesMethod: 'ANY',
                rules: [
                  {
                    targetId: 'ACCIDENTS',
                    isNot: ['NO']
                  },
                  {
                    targetId: 'CONVICTIONS',
                    isNot: ['NO']
                  }
                ]
              }
            }
          }
        ]
      }
    }
  ]
};
9 Comments
Active Member
Hi Dave,



I have recently tried to follow the Aikau tutorial you linked in this post from the beginning, but after following the first couple of steps, starting the application with mvn jetty:run, I am unable to login.

I have an alfresco repo application running on port 8080,  but when I try to login it times out. I have tried also with a fresh alfresco repository.



Do you have any hints on this? Does the Aikau tutorial work with Alfresco 5.0.0c (this is the fresh install version I tried it with)?



Thank you very much
Intermediate II
@Massimo... I'm assuming that you can actually log into Alfresco using the Share client as well? The tutorial should work against an Alfresco 5.0.c repository. Are you getting any errors in the logs at all? Are you definitely seeing the XHR request being made from the the browser to the repository?
Active Member
Hi Dave, yes, I can login through share. I actually started to test the tutorial  with my development environment, which is Alfresco 5.0.0.3 enterprise, with the data set that I normally use.

Then, since I couldn't login, I tried the blank, fresh installation of Alfresco 5.0.c.

When I click the login button it fires an XHR request to localhost:8080/alfresco/s/api/login and then it times out, so I get a 408 read timeout in the jetty log.

I hope this answers your questions, let me know if you need anything else.
Intermediate II
@massimo... that looks like an unusual XHR requet that is being made... I would expect to see the request: http://localhost:8090/aikau-sample/service/dologin? (with username/password request parameters)



Just to clarify, you're creating a new client using the mvn archetype as described in the tutorial?
Active Member
[…] all the bug fixes and features added since my last post, in the 1.0.39 release of Aikau we’ve added a useful addition to our forms capabilities that […]
Active Member
Hi Dave, sorry, probably bad explanation on my part.

So, if I use Chrome inspector, I do see the request you mentioned in your comment. But what I think it's happening is that request is relayed to the one I mentioned, and as I said in the previous message, I get a 408 read timeout error in the jetty log.

To answer your question, yes, I am creating a new project with the mvn archetype described in the tutorial.
Intermediate II
@Massimo - it's possible that there are issues with running it against 5.0.c and maybe even 5.0.0.1 as I've not tried those specific versions, but I can't imagine that anything significant changed in the APIs. In fact that client archetype is still using Surf 5.0.d so it seems really unlikely. Are both servers on the same machine?(just wondering if there might be any odd network issues at play)



To be honest, I'm not really sure what to suggest - you're the first person to have reported having a problem getting the client to connect to Alfresco.
Active Member
Hi Dave,



I have a set of radio buttons to which i want to add change event. Whenever i change the radio button selection based on the value certain fields on the form should be hidden. How can i achieve this in aikau



Thanks,

Abhi
Intermediate II