Answers.Body: <p>When you're dealing with that many fields it's definitely a non-trivial undertaking but Craft does have all the tools you need to pull it off.</p>
  
  <p>Your plan B is probably the most solid option. Make a new section that houses the skill entries and then set up all the radio buttons on it you'll need.</p>
  
  <p>You can put fields on Users directly but it gets weird as they don't act like entries in some respects.</p>
  
  <p>Getting all the fields <em>into</em> Craft is probably another topic that you'll probably want to do programatically.  However,  after you have them all in the CMS, it's relatively straightforward to spit out all the fields for a particular entry type in a section. </p>
  
  <p>To do that: </p>
  
  <pre><code>{# get the section by handle #}
  {% set section = craft.sections.getSectionByHandle('skillRecords') %}
  
  {# fields are set on entry types of sections to get all the entry types #}
  {% set entryType = section.getEntryTypes %}
  
  {# loop through the fields in the first entryType's fieldLayout Model #}
  {# if you have more than one entry type, use 1, 2..etc #}
  
  {% for fieldLayoutField in entryType[0].getFieldLayout().getFields() %}
  
      {# get the field from the id #}
      {% set field = craft.fields.getFieldById(fieldLayoutField.id) %}
  
      {# grab the type of field from its className #}
      {% set fieldType = field.className|replace({'craft\\fields\\':''}) %}
  
      {# output the field #}
  
      {% switch fieldType %}
  
       {% case 'RadioButtons' %}
       &lt;fieldset&gt;
       &lt;legend&gt;{{ field.name }}&lt;/legend&gt;
  
      {% for option in field.options %}
  
          {% set selected = entry is defined ? 
                            field.value == option.value : option.default %}
  
          &lt;label&gt;
              &lt;input type="radio"
                  name="fields[field.handle]" value="{{ option.value }}"
                  {% if selected %}checked{% endif %}&gt;
              {{ option.label }}
          &lt;/label&gt;&lt;br&gt;
  
         {# you'll probably  want to make other cases depending on what you're doing #}
      {% endfor %}
      &lt;/fieldset&gt;
  
    {%endswitch%}
  
  {% endfor %}
  </code></pre>
  
  <p>That's a pretty simple example with zero styling so you'll obviously want to make it your own. As with anything in Craft, the front end and the UI is up to you.</p>
  
  <p>You might consider splitting up the questions into pages (eg 30 per page) and save the form after every page (either in the user's browser or to Craft itself). Vue or even jQuery can help you do that.</p>
  
  <p>I'm not sure what the performance aspect is going to be when it comes to 120 fields. The most performant way would be to setup your own table with its own values but that goes down the rabbit hole of plugin development.</p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-06-17T15:57:06.730Z
Answers.Text: Thank you for taking the time and for the perspective. The sample code will come in handy. What I'm currently doing is meeting with the client and seeing how this might be simplified, as some question has come up whether or not the rankings of each skill are needed, or just a yes/no. That would allow for just simply a category field. So, we're vetting some of this out in the field before going to far down any one path. Thanks again.
Answers.UserDisplayName: Mosswalker
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-06-18T03:14:50.870Z
Answers.Text: For sure, simpler is almost always better when you can get away with it!
Answers.UserDisplayName: RitterKnight
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2020-06-16T20:59:13.233Z
Answers.LastActivityDate: 2020-06-16T20:59:13.233Z
Answers.UserDisplayName: RitterKnight
Body: <p>I'm working on a new project that requires users to fill out a lengthy survey to assess their skills. These skills will then be used to query for users with a front-end interface. My question has to do with how to store these ~120 skills and query them later.</p>
  
  <p>Each skill with have a range of values such as:</p>
  
  <p><strong>Skill:</strong> Crosscut Saw Experience 
  <strong>Possible values</strong>: 0) none 1) performed with supervision 2) performed independently 3) Have Supervised 4) Trainer</p>
  
  <p>So, that first makes me thing of radio button fields. The issue is that there is about 120 of these skills that need to be recorded for each user with a front-end form. And, the must be the ability to quickly query user based on skill/skill level.</p>
  
  <p>At first I considered a static Super Table, but I don't believe querying that is easy or efficient, based on other questions I've browsed.</p>
  
  <p>Plan B is to create a Skills channel, creating ~120 skill records, related to each user. This would make querying simple a matter of finding records relatedTo a skill. But how to create all these records on the front end as the user is filling out a form?</p>
  
  <p>I've not used any of the form plugins, such as Sprout Forms or Freeform. Anyone have any experience with these that might shed some light?</p>
  
  <p>Any other suggestions on how to best go about this?</p>
  
  <p>Thank you for any ideas or advice.</p>
  
Tags: <form><solspace><table-field><best-practice>
Title: How to relate a long survey to a user and later query by values
ThreadText: # How to relate a long survey to a user and later query by values
  
  (Asked by: username_0 on 2020-06-16)
  
  I'm working on a new project that requires users to fill out a lengthy survey to assess their skills. These skills will then be used to query for users with a front-end interface. My question has to do with how to store these ~120 skills and query them later.
  
  Each skill with have a range of values such as:
  
  **Skill:** Crosscut Saw Experience
  **Possible values**: 0) none 1) performed with supervision 2) performed independently 3) Have Supervised 4) Trainer
  
  So, that first makes me thing of radio button fields. The issue is that there is about 120 of these skills that need to be recorded for each user with a front-end form. And, the must be the ability to quickly query user based on skill/skill level.
  
  At first I considered a static Super Table, but I don't believe querying that is easy or efficient, based on other questions I've browsed.
  
  Plan B is to create a Skills channel, creating ~120 skill records, related to each user. This would make querying simple a matter of finding records relatedTo a skill. But how to create all these records on the front end as the user is filling out a form?
  
  I've not used any of the form plugins, such as Sprout Forms or Freeform. Anyone have any experience with these that might shed some light?
  
  Any other suggestions on how to best go about this?
  
  Thank you for any ideas or advice.
  
  **Tags:** form, solspace, table-field, best-practice
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2020-06-16. Score: 2 | Accepted answer
  
  When you're dealing with that many fields it's definitely a non-trivial undertaking but Craft does have all the tools you need to pull it off.
  
  Your plan B is probably the most solid option. Make a new section that houses the skill entries and then set up all the radio buttons on it you'll need.
  
  You can put fields on Users directly but it gets weird as they don't act like entries in some respects.
  
  Getting all the fields *into* Craft is probably another topic that you'll probably want to do programatically. However, after you have them all in the CMS, it's relatively straightforward to spit out all the fields for a particular entry type in a section.
  
  To do that:
  
  ```
  {# get the section by handle #}
  {% set section = craft.sections.getSectionByHandle('skillRecords') %}
  
  {# fields are set on entry types of sections to get all the entry types #}
  {% set entryType = section.getEntryTypes %}
  
  {# loop through the fields in the first entryType's fieldLayout Model #}
  {# if you have more than one entry type, use 1, 2..etc #}
  
  {% for fieldLayoutField in entryType[0].getFieldLayout().getFields() %}
  
      {# get the field from the id #}
      {% set field = craft.fields.getFieldById(fieldLayoutField.id) %}
  
      {# grab the type of field from its className #}
      {% set fieldType = field.className|replace({'craft\\fields\\':''}) %}
  
      {# output the field #}
  
      {% switch fieldType %}
  
       {% case 'RadioButtons' %}
       <fieldset>
       <legend>{{ field.name }}</legend>
  
      {% for option in field.options %}
  
          {% set selected = entry is defined ? 
                            field.value == option.value : option.default %}
  
          <label>
              <input type="radio"
                  name="fields[field.handle]" value="{{ option.value }}"
                  {% if selected %}checked{% endif %}>
              {{ option.label }}
          </label><br>
  
         {# you'll probably  want to make other cases depending on what you're doing #}
      {% endfor %}
      </fieldset>
  
    {%endswitch%}
  
  {% endfor %}
  
  ```
  
  That's a pretty simple example with zero styling so you'll obviously want to make it your own. As with anything in Craft, the front end and the UI is up to you.
  
  You might consider splitting up the questions into pages (eg 30 per page) and save the form after every page (either in the user's browser or to Craft itself). Vue or even jQuery can help you do that.
  
  I'm not sure what the performance aspect is going to be when it comes to 120 fields. The most performant way would be to setup your own table with its own values but that goes down the rabbit hole of plugin development.
  
  > **Comments:**
  > **username_0**: Thank you for taking the time and for the perspective. The sample code will come in handy. What I'm currently doing is meeting with the client and seeing how this might be simplified, as some question has come up whether or not the rankings of each skill are needed, or just a yes/no. That would allow for just simply a category field. So, we're vetting some of this out in the field before going to far down any one path. Thanks again.  
  > **username_1**: For sure, simpler is almost always better when you can get away with it!  
  
  ---
  
  