Transparent Redirect field name brackets make integration difficult about braintree_python HOT 9 CLOSED

Hi foresto,

The required format of the parameter names apply only to the "name" attribute of the fields. The "id" attribute can be whatever format you prefer. Only the name and value attributes are used when the form is posted.

If the specific web form library you're using doesn't provide an easy way to specify the form element name separate from the id, we'd definitely be interested in learning more details. We're always interested in making the integration experience as easy as possible and feedback like this is very helpful.

Hammer
Braintree Developer

from braintree_python.

Yes, I understand that the "id" attribute doesn't affect Braintree's server.

My point is that, in modern web development, the "name" attribute affects more than just the html and the data that gets posted to a server. A lot of people use web toolkits to simplify / automate form handling, and some of the ways those toolkits make our lives easier rely on "name" attributes being shared with "id" and "for" attributes in the HTML, as well as native class attributes and variables in the programming language that fills the templates. By requiring square brackets in the "name" attribute, Braintree effectively forces programmers to abandon their form toolkits or else (sometimes extensively) rewrite form handling code that would otherwise be automated.

I never claimed that working with Braintree's naming convention was impossible. It's just time consuming, fiddly, error prone, and generally irritating. The opposite of elegant, if you will. If you allowed a more widely-compatible naming convention like the one I suggested, our programmers could spend their time on more productive things.

from braintree_python.

It's probably worth noting that at least one of your competitors who offer functionality similar to Transparent Redirects use an underscore to delimit subfields within "name" attributes. (Similar to what I suggested in my bug report here.) I have no doubt that they chose this approach for maximum compatibility.

from braintree_python.

I see that this issue is now marked as "closed", yet it has not been addressed. You seem to have misunderstood the second use case in my report, and completely ignored the first.

from braintree_python.

Closing was accidental, reopening.

from braintree_python.

We'll be releasing support for using double underscores this week.

from braintree_python.

Hooray! This will allow our Braintree form code to work like all the other form code in our system, rather than re-implementing library functionality in bizarre ways and requiring special knowledge to avoid breaking.

from braintree_python.

I just got a chance to try the new syntax, and it seems to be working quite nicely. Thank you! I hope to incorporate it into our integration code soon. Any chance it will find its way into a future rev of the documentation?

from braintree_python.

On a more personal note, I'm sorry about the strident tone of my earlier message. I had only intended to clarify the nature of the problem I was reporting, and upon rereading, I see it came out a bit harsh. For the record, you folks have been doing an outstanding job of addressing issues as they arise. I'll mind my phrasing next time.

from braintree_python.