Feature Request: Make generic Tab object handling easier

[voltaek]

When instantiating an object of any of the various types of Tabs in the C# SDK, e.g. Checkbox, Text, SignHere, etc., it would be great if the TabType property of them was already populated with the underlying tab type that the API recognizes, e.g. "checkbox", "text", "signHere". As the tab type is already determined by using that specific class anyways, this property seems like it could just be a public constant string property for each class. The result of this would be that when serializing the object to JSON for use later, the 'tabType' property key and value would be included, and the JSON could then be easily used generically - with no other data required - by this or another SDK (such as the PHP one) to parse out the 'tabType' property and know which class to instantiate from the SDK and then populate with the property values from the same JSON.

A secondary part to go along with this that would be appreciated is to have all the Tab classes conform to an interface that contains at least some of the properties that all the tab type classes share. This would streamline generic handling of class objects when instantiating from JSON and other such situation where we're dynamically creating tab object from stored data. I know that the different tab types have a variety of differing properties, so even just some of the overlapping ones being interface properties would be greatly appreciated. Some properties that could be nice to have on the interface would be: tab type, tab ID, document ID, tab label, tab group labels, tab order, anchor string, anchor units, anchor offsets, x and y position, font, tooltip, name, etc. (I'm pretty sure most of these are used across all tabs, and I'm sure there are more that they all have, but I can't find any documentation on what is or is not guaranteed to be shared across them all in the API docs).

Thank you.

[esilva600]

Hello,

We noted your suggestion and the JIRA Ticket DCM-8774 was created to check the feasibility of this Request, and implement the requested changes if positive.

If you need further help or clarification you can reach out at the Support Portal using the Ticket as a reference:
https://support.docusign.com

Cheers,

[LarryKlugerDS]

Note that you don't need to set the TabType property when making a request. It's set on responses.

Why do you think you need to do so?

[voltaek]

@LarryKlugerDS It's not that I think we need to set the TabType property for the purpose of making a request; it's that it would be nice if the serialized JSON string of the tab object contained all the data one would need to recreate an object of that same tab type, regardless of SDK you used. So by having the TabType appear in the JSON serialized from a SignHere object, for example, in the C# SDK, if that JSON was stored somewhere and then used from somewhere else, let's say a different app/site that uses the PHP SDK, you could simply reference the TabType out of the JSON in order to determine the tab object to create for that platform/language.

As it stands now, I'm storing the DocuSign tab type (the camel-cased string, e.g.: 'signHere') in a separate column in the database record that is storing the tab JSON, so when I pull the tab data I can reference the tab type to instantiate the correct tab object and then apply the JSON properties to the object to end up with a populated tab object. So for me, it's a solved problem, but it would be nice to have the serialized JSON fully represent the tab without having to have the C# type injected as a non-standard property like one could do with something like Newtonsoft.Json.JsonConvert.SerializeObject(signHereTabObject, new JsonSerializerSettings() { TypeNameHandling = TypeNameHandling.Objects });, which puts a non-platform-generic (and JSON-library-specific-functionality-coupled) '$type':'DocuSign.eSign.Model.SignHere, DocuSign.eSign' property into the generated JSON.

So at this point, the interface part of my requested feature additions would be more useful / clean up our code the most. That way when I have to assign the document ID to all of the tabs we've created I could do it generically.

In terms of handling the variety of tab objects that we generate, though, I think a really nice thing to have would be an easier way to put a tab object into the Tabs container object. Right now we have to resort to a big switch statement of all the tab type objects we use to look at the tab type to determine the specifically typed List property on the Tabs object to put the tab object into, and then we have to ensure that the property has already has a List of that specific type, e.g.: List<SignHere>, assigned to it before we can add the tab object to that list property. Just something like an AddTab() function on the Tabs class that took an object would be great. Internally it could use reflection to determine the tab type of the object, instantiate and assign the proper List<> object to the proper Tabs object property, and add the tab object you gave it to it. Sure, this might need its own switch statement in it for the tab types, but then at least it's hidden away in the library and users don't have to maintain it when a new tab type is added or something. Additionally, this would be another case where having all the tab classes conform to an ITab (or some similar name) interface so you could have the parameter of AddTab() be of that interface type instead of a base object, but I digress.

Hopefully that makes what I'm trying to do with the tabs a little more clear; just looking for more generic ways of handling them. We're currently using the C# SDK as part of our report-generating service and adding the ability to have the report sent out via DocuSign, so we have to store all the tabs for the report in the database along with the report details.