Skip to main content

Hi Nintex Community,

 

With a long Memorial weekend, a short week, a wrong turn (involving serializing the Forms object model) I wasn't able to finish my next XML code sample until late last night. So I will be able to verify, write it up, and post everything by this next Friday. This is a small application that generates valid form XML with a limited subset of controls. I plan on including some common Word and HTML form controls: single and multi-line text box, list box, a check box, choice box, and in Nintex Form parlance, a label control. The application will take a tiny XML file that lists the controls, control-specific values (such as label text), control dimensions, and generates form XML. I can see this process being re-purposed to create a batch conversation process for HTML forms, or converting Microsoft Word forms (in the open office format), or Adobe Acrobat forms.

     In addition, I'll also publish a general reference for back-end attributes for each of the standard forms controls. After that I will finally get on to the JavaScript reference for the Forms On Prem 2013 SDK. Also I've been listening to all your comments regarding PowerShell cmdlets and methods using PowerShell to manage or publish forms. That is on my list, as well as creating custom run time functions,  but let me know what else I should cover. Thanks.

 

Cheers!

Matt

Hi Matt,

Just got a closer look on forms SDK. I'm looking for a way to automatically publish form xml on a content type instead of a list. I didn't found this in the SDK is (or will it be) possible in the future?

Thanks

Roman


Hi Roman, Thanks for your question. The publish end point accepts an optional property, the contentTypeID and the associated list or document library. You can specify the contentTypeID in the request JSON. For information on the end point, please check out PublishFormXML. The request body contain JSON that would look something like, along with the form XML:

   {

       "listId": "{DB0ECEE6-117D-4519-986E-020A9BE6A7E3}",

      "contentTypeId": "0x0101000728167cd9c94899925ba69c4af6743e"

  }

In the code sample, PublishFormExample, you can find contentID specified in the GetFormFromFileAndPublishToList() method, here is the full signature: GetFormFromFileAndPublishToList(string fullFilePath, NfClientContext destinationCtx, string destinationListId, string destinationContentTypeId).

Does that help? Or did you try it, and it didn't work... (the story of my life! )

Thanks again for your note.


Hi Matt,

We have a project where the form is associated to the content type only. Every list item associated to this content type will automatically use the associated Nintex form. As the listId seems to be a required property this seems to be not supported (I did not try it).

Thanks

Roman


Hi Roman, Nintex Forms are always associated with a list, and so even if you are primarily interacting with and thinking about the form XML in terms of the contentTypeId, the form is still contained with in a list. The reason the contentTypeId is a supported parameter is to allow for interaction with multiple Nintex Forms that have been associated with a single list via content type. Cheers, Matt


Hi Matt,

Just made a test if this option is still available:

... it is. If I attach my Nintex form on this content type every usage is automatically associated with my form. If I set this content type to be used any List this form is used. This is a feature we used if we dynamically create lists in subweb with custom content types. It would be great if we were able to deploy this form automatically using the REST api.

Thanks

Roman


Hi Roman, I will have to do some research to find out for sure, and if I find out I'll see if I can make it work. The reason I think it should work is that if you can edit the forms using the Nintex Forms Designer (which opens when you click Edit form with Nintex Forms), the designer itself calls the web service to perform some of these functions. However yeah it may not work esp. if there isn't any List ID involved in the Site Content Type scenario. I'll try to get back to as soon as I have chance to try it out and see what is going on. Thanks again for your time in clarifying your question. Matt


Yep it is not supported with the API at the root level of the site since it is not contained in a list. You'd think that the contentTypeID would be enough, but no dice. Sorry it took some time to check it out for sure. Thanks again for drawing my attention to this use case as well. I wasn't that familiar with it. I let the product team know what you were asking about. Also, if you wanted to, you could make a feature request in User Voice. Cheers, Matt


Reply