0
-1
-2

We would like to when a form is loaded, update the visibility of specific fields defined in a prefill instruction, so a form has fields

 

field1

field2

field3

 

The instruction says show field 2, hide field1, field 3..      This instruction may change.

 

Composer would say.. business rule/ sfc.updateVisibility .. 

 

What does Maestro say about this ?  Apart from Javascripting it, there is no direct 'updatevisibility.. '

 

One idea seems to be via a dynamic class - how can we get it to act on specific runtime known fields - css selectors ? or some other way

    CommentAdd your comment...

    4 answers

    1.  
      3
      2
      1

      Garry, the kind of imperative approach you are suggesting is not optimal in Maestro (or Composer, as Jye points out). The only way to imperatively change the visibility on other fields is through JQuery-style DOM manipulation. I would not advise this at all. In Maestro (and really all UI programming) a data-driven, declarative/reactive approach is more suitable. This is true for visibility, custom style class rules, etc.

      Let's say I wanted to toggle the visibility of 5 fields on a button click. The change rule of the button would look like:

      data.$fieldsVisible = !data.$fieldsVisible

      And the visibility rule on each field would be:

      data.$fieldsVisible

      You should be able to scale that approach to the required level of complexity.

      If you have a problem which you cannot solve with such a reactive approach in Maestro please provide all the form details and description of the required outcome in a JIRA and we can provide some design advice.

        CommentAdd your comment...
      1.  
        2
        1
        0

        Visibility rules in Maestro are reactive. When the source data changes, the field's visibility will update.

        If you have a problem with a specific visibility rule, please show the code you are using.

          CommentAdd your comment...
        1.  
          1
          0
          -1

          We've discouraged the use of sfc.updateVisibility for quite a while now. It leads to inconsistent form designs between developers and visibility rules which are generally more difficult to reason about or predict.

          Use of these sorts of methods requires knowledge of the event model and the order in which events fire to avoid bugs. For example, what happens when the visibility rule on the field fires after your business rule and changes the visibility to a new state? Or, a new developer is maintaining your form, they look at the field but can't see a visibility rule and are now unsure why the field is being hidden.

          It's better to have the visibility rule on the fields themselves.

            CommentAdd your comment...
          1.  
            0
            -1
            -2

            Thanks Tim, the issue is not around how we assign visibility rules to fields, but rather how maestro can in one single place affect the visibility of a variable number of other fields, ie targeted visibility not source visibility.

             

            Back to the original example, if I have 10 fields on a form, field1, ... 10.           And if (via a prefill) I write out the phrase : "field1, field3"  into a field called 'hideFields' on the form.   I would expect an instruction (previously this was a business rule) to a) loop through the list of fields (field1, field3),   b) resolve them via path assignment, so data.field1, data.field3  (we could write them like that in the first place), and then c) for each one switch off visibility, or as I think in the case you mention above assign a class to the field directly to remove visibility

            All I need to know here I think is for (c) where can we directly programatically assign a class in a loop for a field

             

            This appears to be an unanswered question in the forums, although I can't vouch for searching every single thread...

             

            https://support.avoka.com/kb/questions/45057109/in-maestro-how-to-create-a-custom-style-classes-for-a-group-of-text-fields-for-performing-actions-for-the-same.

              CommentAdd your comment...