PLEASE NOTE: These forums are no longer utilized and are provided as an archive for informational purposes only. All support issues will be handled via email using our support ticket system. For more detailed information on this change, please see this blog post.

If you only realized how close you are to automagic sync'ing to 3rd Party APIs!!

  1. d4le
    Member

    It would be almost automagical if you could get the parameter 'InputName' field from the post_submission hook (as well as the fields value of course).

    To see how freakin' easy this almost is... you create a form, in the advanced features you change the "Parameter Name" of each field to match your 3rd Pary's API naming convention. Now there's no name space collision at all -- as long as you can get the form_meta with the post_submission data.

    There's one big hitch! You don't always follow the "Parameter Name" -- convention! In the special 'First Name, Last Name' -- set, you call them "Field Parameter Name", and their key in a subarray is now 'name' not 'InputName', that's the only major change I see.

    By automagic I mean, you'd only have to fill in the 'Parameter Name' for each field you want mapped to the 3rd Party api -- spelled exactly correct for the 3rd Party API

    Then I wouldn't have to write a custom mapping function for each form, I could just loop through the Parameter Names, and map them EXACTLY. Plus they're already sanitized!

    I could solve routing problems with a hidden field with the Parameter Name that matches the 3P's form names.

    Oh, it'd be so easy!! Can't you feel it?

    And the main benefit: The automagic 3rd Party mapping could written as a function/plug-in, and the user only needs to activate it, then set the Parameter Names correctly in the wp-admin of gravity forms! That's it. That's automagic. No php for the end-user to change, modify or create new forms -- nothing after that.

    For instance,

    [id] => 6
                         [label] => Product Inquiry Reasons...
                         [inputName] => InquiryReason

    If you got back from gforms_post_submission, the submitted value and the 'InputName', well then, you're almost done! No need for custom mapping of field '6' to you 3rd Pary's name space built by hand on a form-by-form basis using numerical IDs -- that's a dangerous mapping, using IDs is like using 'goto' statements in a situation like this where a user could delete a field, then put it back, but wait, it's a new ID now! Now you're whole hand-built mapping is busted.

    Many of these 3rd Parties are paid services, if they have a point-n-click sync'ing with your plug-in, they'll recommend it instantly to customers. Customers have already paid for their service, what's another $50-$200.

    Oh, and perhaps you'd let users assign default 'Parameter Names' to the built-in fields in a settings page. Then 'First Name' could always 'FirstName' if your API needed it.

    I'm not asking you to change any deep structure, just give me access to the 'Parameter Name' in the post_submission, and we're DONE!! It's that easy.

    Thanks!!

    Posted 9 years ago on Wednesday November 18, 2009 | Permalink
  2. d4le
    Member

    Here's the pseudocode, a little more steps would be need to map the InputNames to an array, but you get the picture...

    $form_meta comes from post_submission hook, with submitted data this time (not like pre_submission)

    $form_routing_name
            = $form_meta->InputName['3rdparty_form_name']->value;
    
    // not necessary unless 3rd Party is very strict on submissions
    unset $form_meta->InputName['3rdparty_form_name']
    
    for each $key $value of an item with an InputName {
    $query_string .= '&$key=$value'
    }
    
    // your 3rd Party plug-in or function:
    send_to_3rdParty ( $form_routing_name,$query_string,'post');

    DONE!!

    Posted 9 years ago on Wednesday November 18, 2009 | Permalink
  3. Seems like a great idea. Adding the form meta to the gform_post_submission shouldn't be a problem, and it will also solve the issue that the form_id is not currently not available in that hook.

    If you have the form meta and the entry array, you can do exactly what you want. You will be able to search the form meta for fields with non empty parameter names and then lookup their value using the field id and the entry array.

    Posted 9 years ago on Wednesday November 18, 2009 | Permalink
  4. d4le
    Member

    Don't forget the non-standard naming convention of the First Name, Last Name built-in fields, they will cause a problem being in another level deep in the array and the Parameter is called 'name' not 'InputName' as you've standardized on the other fields...

    [label] => Name
                        [adminLabel] =>
                        [type] => name
                        [isRequired] =>
                        [size] => medium
                        [errorMessage] =>
                        [inputs] => Array
                            (
                                [0] => Array
                                    (
                                        [id] => 1.3
                                        [label] => First
                                        [name] => FirstName
                                    )
    
                                [1] => Array
                                    (
                                        [id] => 1.6
                                        [label] => Last
                                        [name] => LastName
                                    )
    
                            )
    Posted 9 years ago on Wednesday November 18, 2009 | Permalink
  5. d4le
    Member

    That's not a fatal flaw, you can check to see if 'inputs' is there and if its an array, if so, the mapping function needs to keep walking, but it'd be much easier if 'name', was 'InputName' for sanity's sake.

    Either way, as long as [InputName] and [inputs] are mutually exclusive, putting in flow control in the mapping function for it won't be a problem. Not quite as elegant as it could have been, but the end result will still be automagical.

    I would suggest you never do that again! It's great to have 'groups' of built-in inputs for the fancy drag-n-drop interface (bravo, BTW), but you should do it with 'meta' stuff, not violate the encapsulation of the key/value form field standards.

    What you could have done instead is add a hierarchical field, not overload the id to accomplish two different things.

    Regardless, this is so close to automagic integration, I'm so happy!

    Posted 9 years ago on Wednesday November 18, 2009 | Permalink
  6. I am not a big fan of how that "inputs" array came out, to be honest. It creates a non-standard situation where you need to check for that special case many times.
    I am curious to hear your opinion on how to come up with a structure that is able to consistently handle fields with one input (i.e. text field) and fields with multiple inputs (i.e. name and address). You said "you should do it with 'meta' stuff". How exactly would you create that meta?

    Posted 9 years ago on Thursday November 19, 2009 | Permalink
  7. d4le
    Member

    I thought about different ways to do it with the least refactoring (because I want this feature now! ;) ). I'd use fieldsets for the atypical instance of the 'Full Name' predefined field. This is really close to what you're already doing. The only difference is to make sure the array is flat when it comes to getting return values out when submitted, so it can be iterated over easier.

    A fieldsets (or do it with division tags that act like fieldsets, depending on your styling).

    <fieldset>
        <legend>Name:</legend>
           <label for="first">First Name</label>
           <input type="text" name="first" id="first" />
           <label for="last">Last Name</label>
           <input type="text" name="last" id="last" />
    </fieldset>

    Basically if a form field returns a value from the form, we want its details in the top-level of the meta_form data with a Parameter Name (inputName) attached to it. That's the immediate goal, and it's pretty easy to achieve with your existing structure I believe. We're fine if the top level of the array has some extra entities in that don't get a returned value when submitted. There's no problem with selects, checkboxes, and radio buttons being another level deep and another array structure, because they already defined on the top-level of the meta_form array and return a single value ultimately when submitted (no changes are needed, they already have the 'Parameter Name' field on the first level, too).

    This isn't the ideal way to do, you'd probably want fieldsets and fields in separate classes ultimately. But this way would be the least effort to create from your existing model, because you already have exceptional 'types' in the model that don't return key/value pair, like the 'input' field which is already acting like a fieldset, but not in an ideal way.

    The fieldsets (or division) could belong to the same data model as the regular fields, with the exception of it's 'type'. If you were building from scratch you'd probably create a separate class for fieldsets. But since you're already this far along, I'd just add an additional 'type' to your data model.

    Now where you have [type] => text, or [type] => email, you'd have [type] => container, or [type]=>fieldset (I'd do both fieldsets and divisions for flexibility)

    Form fields within a fieldset, have a parent_id and a sort_order property. A null value would be the equivalent of 'parent_id=0' for all top-level fields. sort_order starts at 0, and increments down. The reason you want to have a parent_id attached to the field and not children attached to the fieldset is so you can delete and add elements simply by changing there parent_id, this also keeps two different fieldsets from containing the same fields accidently. This will keep your older stored submitted data intact, too. If you move a field from one fieldset to another, the value still sticks with the form field ID, and not the fieldset. A fieldset is really part of the view in the design pattern of HTML forms.

    You treat the fieldset like a parent category with it's own descendant hierarchy -- View-wise. Technically you can reconstruct the fieldset's children in the Controller from their parent_id and sort_order.

    The way you'd know the fieldset for 'Full Name' (with id=1) would contain the 'First Name' and 'Last Name', is because each contained field would have a parent_id=1, and sort_order 0 and 1 respectively.

    THE OLD inconsistent way for 'inputs':

    [0] => Array
                    (
                        [id] => 1
                        [label] => Name
                        [inputs] => Array
                            (
                                [0] => Array
                                    (
                                        [id] => 1.3
                                        [label] => First
                                        [name] => FirstName
                                    )
    
                                [1] => Array
                                    (
                                        [id] => 1.6
                                        [label] => Last
                                        [name] => LastName
                                    )
    
                            )
                    )

    BECOMES:

    [0] => Array
                    (
                        [id] => 1
                        [label] => Name
                        [type] => Fieldset
                 or
                        [type] => Container // <div> 
    
                    )
    
    [1] => Array
                    (
                        [id] => 2
                        [label] => First
                        [type] => text
                        [inputName] => FirstName
                        [parent_id] => 1
                        [sort_order]=> 0
                    )
    
    [2] => Array
                    (
                        [id] => 3
                        [label] => Last
                        [type] => text
                        [inputName] => LastName
                        [parent_id] => 1
                        [sort_order]=> 1
                    )

    Anyway, the end result is to give the post_submission hook a consistent array with the Parameter Names and field_ids so it can match up with the submitted form data and iterated over.

    Posted 9 years ago on Thursday November 19, 2009 | Permalink
  8. D4le,
    Thanks for taking the time to write this. Your solution does provide a consistent way of handling the "fieldsets". I am just not sure that it would make things easier, especially in the admin where all three items in your array needs to be pulled back together and act as one "block". You would ultimately be able to do it, because of the parent_id mapping, but it would take a little work to do.

    If I had to do it again, I think I would standardize on the "inputs" array and make every field use it. So a text field would would have the inputs array with one item. The name would have the same inputs array with 2 items, etc...
    That way, your key/value mapping would always be down in that level (consistent) and you would still keep fields grouped together (easy to manage in the admin).

    Anyways, we do plan on doing a complete re-write at some point to clean some of these things up, but for now it will have to stay this way.

    I did add the $form object to the gform_post_submission hook. I understand it is not all you wanted, but should be enough to get you where you want to go.

    Thanks again for your support.

    Posted 9 years ago on Friday November 20, 2009 | Permalink
  9. OW_bookshop
    Member

    Hi,

    I think I have a similar problem to the one mentioned above i.e. I'd like having to avoid mapping things to ID numbers and do it rather by some sort of consistent name. Sounds like this will be easier in the future which is good to know.

    Just want to doublecheck something from above. When you say:

    "I did add the $form object to the gform_post_submission hook"

    do you mean that is currently in there somewhere or that it will be available in future releases somewhere? I'm running 1.3.6...

    thanks,

    andrew

    Posted 9 years ago on Monday December 7, 2009 | Permalink