https://legacy.forums.gravityhelp.com/topic/optionfunction-to-return-a-more-complex-form-data-structure Gravity Support Forums Topic: Option/function to return a more complex form data structure en-US Sun, 05 Apr 2026 16:20:44 +0000 http://bbpress.org/?v=1.0.1 q https://legacy.forums.gravityhelp.com/search.php https://legacy.forums.gravityhelp.com/topic/optionfunction-to-return-a-more-complex-form-data-structure#post-47184 Tue, 24 Jan 2012 01:12:34 +0000 dnb 47184@https://legacy.forums.gravityhelp.com/ <p>Hi Alex-<br /> Sorry for being so slow to respond to your reply (didn't get an email notification). Let me see if I can answer your questions:</p> <p>1) backward compatibility but providing a non-flat entry object when requested - I appreciate that you are trying to preserve this:</p> <p>There are a number of ways to handle this. A few ideas:</p> <ul> <li>Some APIs (like the old LDAP C SDK) provide additional calls that return extended versions of an object, so you could have explicit hooks that did it ("gform_after_submission_ex()").</li> <li>Some have you pass a flag into the call to request the enhanced version.</li> <li>Some provide helper methods (get_all_values_ex()) that you can call on/from the object.</li> <li>Some sort of global flag (my least favorite idea, where you say $GF::ObjectVersion = 2). </li> </ul> <p>2) where to get the field name if indexing by field names: I'm suggesting you get it from the 'label' (or 'adminLabel' if set) form field value.</p> <p>... or, see my post about a library of helper functions. A helper function that takes in a flat entry object but returns one that is easier to work with would also be viable (albeit a bit of a performance hit). You could imagine something like:</p> <p> $better_entry = make_nice_entry($entry); # bad name, I know<br /> $better_entry['colorcheckbox'] would now be a list ('red', 'blue') based on the form choice.</p> <p>In regard to Ben's response: Ben, could you post a snippet of code? I'm not sure I understand what you are suggesting and why having an entry object that was easier to work with would be a bad thing if backward compatibility could exist for some number of versions. </p> https://legacy.forums.gravityhelp.com/topic/optionfunction-to-return-a-more-complex-form-data-structure#post-46630 Tue, 17 Jan 2012 19:10:44 +0000 Chris Hajer 46630@https://legacy.forums.gravityhelp.com/ <p>Thanks for your thoughts Ben. </p> https://legacy.forums.gravityhelp.com/topic/optionfunction-to-return-a-more-complex-form-data-structure#post-46224 Thu, 12 Jan 2012 11:34:35 +0000 Ben 46224@https://legacy.forums.gravityhelp.com/ <p>I found it easier to do by using the form object and adding code to flip through the entry object when it comes across a checkbox field. It's easy enough that I would think it would be a waste of time and too much trouble for backward compatibility to change the actual entry object. </p> https://legacy.forums.gravityhelp.com/topic/optionfunction-to-return-a-more-complex-form-data-structure#post-45919 Mon, 09 Jan 2012 20:04:06 +0000 Alex Cancado 45919@https://legacy.forums.gravityhelp.com/ <p>Uh oh! Busted.</p> <p>These are some good ideas and I do agree that these changes would make the entry object easier to use. My question is how do we make it backwards compatible? Lots of people are already relying on the entry object in this format. Also, where would you get the field name from to use it as an index?<br /> Thanks for the suggestions. </p> https://legacy.forums.gravityhelp.com/topic/optionfunction-to-return-a-more-complex-form-data-structure#post-45842 Mon, 09 Jan 2012 02:07:20 +0000 dnb 45842@https://legacy.forums.gravityhelp.com/ <p>Super, thanks!<br /> -- dNb</p> <p>P.S. There's no rush (I know one of them is sunning himself as we speak). </p> https://legacy.forums.gravityhelp.com/topic/optionfunction-to-return-a-more-complex-form-data-structure#post-45841 Mon, 09 Jan 2012 02:05:52 +0000 Chris Hajer 45841@https://legacy.forums.gravityhelp.com/ <p>I forwarded this topic to one of the developers to see if we can get some feedback for you. Thanks for your patience. </p> https://legacy.forums.gravityhelp.com/topic/optionfunction-to-return-a-more-complex-form-data-structure#post-45788 Sat, 07 Jan 2012 20:21:12 +0000 dnb 45788@https://legacy.forums.gravityhelp.com/ <p>Hi-<br /> This is related to my post <a href="http://www.gravityhelp.com/forums/topic/helper-functions" rel="nofollow">here</a> about helper functions for GF. On a recent project, I needed to use the entry object returned by gform_after_submission() to retrieve all of the responses in a checkbox field. As far as I know, the only way to do this is to do a linear walk over the keys in the entry object, doing a string match for the ID of that field as a prefix (i.e. if the field ID is 3, you look for 3.1, 3.2, 3.3, etc.).</p> <p>It would be really great if there was a way to get back an entry object that wasn't just a flat array. Using the example above, something like:</p> <p> <code>$entry[3] = [ {3.1&#39;s value}, {3.2&#39;s value}, ... {3.x&#39;s value} ];</code></p> <p>would be awfully spiffy and make the retrieval of all of the values returned from a multi-valued field much easier. </p> <p>If you want to get really fancy, it would also be great if fields could also be referenced by name, so that one could do:</p> <p><code>$entry[&#39;checkbox_field_name&#39;] = [{value1}, {value2}, {value3}...{valueX}] ;</code></p> <p>If there were two fields with the same name, you would suffix the name with the field ID, as in:</p> <p><code>$entry[&#39;checkbox_field_name_3&#39;] = [ {value1}, {value2}, {value3} ... ] ;</code></p> <p>The rationale for this request is code that says:</p> <p><code>$entry[&#39;checkbox_field_name&#39;]</code></p> <p>is much easier to grok than:</p> <p><code>$entry[&#39;3&#39;]</code></p> <p>It also seems a little less fragile to me, since if that field is no longer #3 for some reason, the code doesn't break.</p> <p>Thanks for considering this idea!</p> <p> -- dNb </p>