Transparent Redirect field name brackets make integration difficult

[foresto]

This issue is not python-specific, but since I don't see a general Braintree tracker, I'm writing it up here.

The bracket characters in Transparent Redirect field names make Braintree integration rather a pain. Aside from looking confusingly similar to first-class subscripting syntax in various programming languages, I have seen two specific problems so far:

1. They are incompatible with web form construction/validation libraries that use native-language variables to represent form fields. (For example, the WTForms python library.) Since brackets are not allowed in most languages' variable names, creating a Braintree form in a project that uses such libraries requires either laboriously writing form-processing code by hand, or else jumping through hoops to make the libraries work with reduced functionality.
2. They do not conform to the HTML ID and NAME requirements, and therefore produce invalid HTML when used in templating systems that generate <input id=""> and <label for=""> tags from field names.

There are workarounds for these problems, of course, but they make for overly-complicated special-case code, wasted time, and frustrated programmers.

Would you folks consider supporting an alternative syntax for embedding structure in your field names? Separating sub-fields with double-underscores ought to work nicely. For example, instead of writing credit_card[options][make_default] one might write credit_card__options__make_default, which would be no longer than the former syntax and would also work as a variable/id name in every language that comes to mind.

[thehammer]

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

[foresto]

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.

[foresto]

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.

[foresto]

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.

[braintree]

Closing was accidental, reopening.

[braintreeps]

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

[foresto]

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.

[foresto]

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?

[foresto]

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.