Best Practice, lazy loading form data

[GriefCode]

Hey,

I just got a kinda different question, i mostly make some thoughts on parts i program and since i am not that familiar yet with the IPS Framework i wanted to ask here and collect opinions and suggestions.

I basically want to create a form that filters data by every selection.
To explain my dataset a bit more, i got players that playing games on my service. A game has 10 players. Mostly, the players play 3-4 games and then visit the forum to report someone. And I would like to adapt a really easy system.

That does mean the report form should look like this:

1. The reporter picks one of his recent games
2. The reporter picks one of the players of this game
3. The reporter picks a reason, add comment and can submit it

So basically, when a game is selected the second selection box should update to the players of that game.

Now my thoughts on that:

1. Maybe there is already a system that can be used from IPS?
2. I can simply write a javascript class that will lazy load new data on the change event of the first selection box.
3. "Flow System" or "Step to step", simply by controller actions

Furthermore, depending on the selection of the reason i would also add different new form elements that are previously hidden, that would be required to be added as well.

Anyone got an idea/suggestion?  References to existing code would be also really nice 

[bfarber]

The "easy" way would be to let PHP do it with three separate forms basically. We have a Wizard helper at \IPS\Helpers\Wizard which can accomplish this already (it's the step-by-step approach you speak of). You can look at our registration process (applications/core/modules/front/system/register.php) or the Gallery image submission process for a practical example.

The form helpers support toggles already (that is, showing/hiding form fields based upon selections), but if you use the Wizard helper you won't need them really (each step would be one form field based upon the selection in the last step). You can find examples of toggles all over the code base, particularly with ACP controllers where forms are generated (editing groups and most setting pages are good examples).

Having said all that, the nicer approach would be of course to do this with one form and lazy loading the fields using javascript, which would require you to write a javascript controller. It would probably send an AJAX request when a select option is changed as you noted, and the PHP controller would return the next form field UNLESS the number of players in the game is relatively small and limited. If you have few enough players in all of the games combined, you could potentially build the entire form and just use form toggles to handle showing/hiding the player options, but this wouldn't be scalable and you may need to play to fall back to the AJAX approach to get the new form field anyways.

It sounds like overall you're on the right path, and the exact approach you take depends upon how many players you have total across all games, combined with how much work you want to put in both with PHP and with javascript.

[GriefCode]

8 hours ago, bfarber said:

The "easy" way would be to let PHP do it with three separate forms basically. We have a Wizard helper at \IPS\Helpers\Wizard which can accomplish this already (it's the step-by-step approach you speak of). You can look at our registration process (applications/core/modules/front/system/register.php) or the Gallery image submission process for a practical example.

The form helpers support toggles already (that is, showing/hiding form fields based upon selections), but if you use the Wizard helper you won't need them really (each step would be one form field based upon the selection in the last step). You can find examples of toggles all over the code base, particularly with ACP controllers where forms are generated (editing groups and most setting pages are good examples).

Having said all that, the nicer approach would be of course to do this with one form and lazy loading the fields using javascript, which would require you to write a javascript controller. It would probably send an AJAX request when a select option is changed as you noted, and the PHP controller would return the next form field UNLESS the number of players in the game is relatively small and limited. If you have few enough players in all of the games combined, you could potentially build the entire form and just use form toggles to handle showing/hiding the player options, but this wouldn't be scalable and you may need to play to fall back to the AJAX approach to get the new form field anyways.

It sounds like overall you're on the right path, and the exact approach you take depends upon how many players you have total across all games, combined with how much work you want to put in both with PHP and with javascript.

The wizard fits perfectly for me, already build it up on that :-)

Thanks for the idea and input :-)

[HeadStand]

On 12/13/2016 at 8:28 AM, bfarber said:

Having said all that, the nicer approach would be of course to do this with one form and lazy loading the fields using javascript, which would require you to write a javascript controller. It would probably send an AJAX request when a select option is changed as you noted, and the PHP controller would return the next form field UNLESS the number of players in the game is relatively small and limited.

Just throwing this out there... but the above wouldn't work. The form needs to have all elements present when it is first rendered, or the values won't be included when you do $form->values(). Similarly, when you have a dropdown list, you can't just use JavaScript to send back a list of options; they all need to be included when you create the dropdown, or validation will fail (and you get an error message like "This value is not allowed"). If you're using JS to manipulate fields this way, you could just make a dropdown with every possible option included (e.g. all players from all games) and then the JS would just show/hide the appropriate options... but that's a serious pain in the neck.

On 12/13/2016 at 8:28 AM, bfarber said:

If you have few enough players in all of the games combined, you could potentially build the entire form and just use form toggles to handle showing/hiding the player options, but this wouldn't be scalable and you may need to play to fall back to the AJAX approach to get the new form field anyways.

That approach does work, but like you said, not scalable.

+1 for wizards.  

[bfarber]

8 minutes ago, HeadStand said:

Just throwing this out there... but the above wouldn't work. The form needs to have all elements present when it is first rendered, or the values won't be included when you do $form->values(). Similarly, when you have a dropdown list, you can't just use JavaScript to send back a list of options; they all need to be included when you create the dropdown, or validation will fail (and you get an error message like "This value is not allowed"). If you're using JS to manipulate fields this way, you could just make a dropdown with every possible option included (e.g. all players from all games) and then the JS would just show/hide the appropriate options... but that's a serious pain in the neck.

That approach does work, but like you said, not scalable.

+1 for wizards.  

You could work around the first limitation I think, without having tried to do so yet. On the backend when building the form you'd just have some logic like (untested)

// Add the first form element, this is static and unchanging
$form->add( ... );

// If we have the value from that field in the request, this is a submission (probably)
if( \IPS\Request::i()->first_form_field_name )
{
	// Add the second form field, with the appropriate options in it
	$form->add( ... );
}

if( $values = $form->values() )
{
	...
}