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

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!!

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!

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.

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