Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

jesse_orange_newable's avatar

Building a dynamic form - databases or arrays?

I have a project in which Users can register for events and on the event registration page they have to fill in a series of questions that I post to a CRM (Salesforce).

Previously I just had a drop down with question set 1, question set 2 etc and this selection would resolve to a Blade file like question-set-one.blade.php where i manually added the HTML which worked for a time, but it became unmanageable.

We then introduced custom questions so that users could any question they want but these don't map well to the CRM when the fields are CQ1, CA1.

My question is whether its better to do something like this?

Then just make new classes for each set, or, whether to just make a database table wit every available field in Salesforce like label, object, field?

My concern is that this second approach would be laborious for the admin user creating the event.

I suppose you could make a question groups table but is this overkill?

0 likes
1 reply
LaryAI's avatar
Level 58

When building a dynamic form for event registration that integrates with a CRM like Salesforce, you have a couple of options: using PHP classes or leveraging a database. Each approach has its pros and cons, and the best choice depends on your specific requirements and constraints.

Option 1: Using PHP Classes

Pros:

  • Simplicity: Easy to implement if you have a limited number of question sets.
  • Flexibility: You can easily modify the structure of the form by editing the class.
  • No Database Overhead: No need to manage additional database tables.

Cons:

  • Scalability: As the number of question sets grows, maintaining multiple classes can become cumbersome.
  • Hardcoding: Changes require code modifications, which might not be ideal for non-developers.

Option 2: Using a Database

Pros:

  • Scalability: Easier to manage a large number of dynamic fields and question sets.
  • Flexibility for Admins: Admin users can add or modify questions without changing the code.
  • Data Consistency: Centralized data management can help ensure consistency across different forms.

Cons:

  • Complexity: Requires setting up and maintaining additional database tables.
  • Initial Setup: More initial work to define the database schema and build the admin interface.

Recommended Approach

Given your concern about the admin user experience and the potential for a large number of dynamic fields, a database-driven approach might be more suitable. Here's a high-level outline of how you could implement this:

  1. Database Schema:

    • Questions Table: Stores individual questions with fields like id, label, name, type, required, etc.
    • Question Sets Table: Groups questions into sets, with fields like id, name, description, etc.
    • Question Set Questions Table: A pivot table to associate questions with question sets.
  2. Admin Interface:

    • Build an interface for admins to create and manage question sets and questions. This could be a simple CRUD interface using a framework like Laravel Nova or a custom-built solution.
  3. Dynamic Form Rendering:

    • Fetch the relevant question set from the database based on the user's selection and render the form dynamically in your Blade template.
  4. Integration with Salesforce:

    • Map the form fields to Salesforce fields as needed, possibly using a configuration file or a mapping table in the database.

Example Code for Dynamic Form Rendering

Here's a simplified example of how you might fetch and render a form dynamically:

// Controller Method
public function showRegistrationForm($eventId)
{
    $questionSet = QuestionSet::with('questions')->find($eventId);
    return view('registration.form', compact('questionSet'));
}

// Blade Template (registration/form.blade.php)
@foreach($questionSet->questions as $question)
    <div class="form-group">
        <label for="{{ $question->name }}">{{ $question->label }}</label>
        <input type="{{ $question->type }}" name="{{ $question->name }}" id="{{ $question->name }}" class="form-control" {{ $question->required ? 'required' : '' }}>
    </div>
@endforeach

This approach provides a balance between flexibility and maintainability, allowing you to scale your form management as your application grows.

Please or to participate in this conversation.