Form Descriptor Object

[Anonymous]

OK, I'm missing something. It's probably obvious, but I'm not seeing it.

MktoForms2 has a method called newForm() which looks potentially useful. It takes a Form Descriptor Object as an argument. But aside from the quick "as created by the Marketo Forms V2 editor" mentioned at the end of it, I don't see a definition for it or even where to get one so I can look at it. I went through the form editor, closest reference I could find was the form embed code, which isn't it. None of the other methods listed on the page return one. Plenty of ways to get a Form object, but that's not it (I tried and it errors out).

So, what did I miss? Where do I get my digital claws on a Form Descriptor Object?

[SanfordWhiteman]

getForm returns form descriptors. The REST Asset API can manage descriptors. A descriptor is simply the serialized representation of a form's fields/rules/layout/etc.

[Anonymous]

I thought I replied to this yesterday. Well that's consistent with the rest of the day I was having, I guess. Anyway:

I tried MktoForms2.getForm() before posting. Didn't work. It got a Form Object, as described in the docs, but apparently that's not the same as a Form Descriptor object, because when I fed the received Form Object into MktoForms2.newForm() it died with a TypeError inside the minimized Marketo js file. But even had it worked, .getForm() requires the Form object to have already been created before it gets it. I was looking for a way to create the Marketo Form Object before rendering the form itself, hopefully completely stopping it from rendering until and unless necessary.

But thanks for the pointer to the REST API. I've wandered around in there before, looking for something else, but I remember there are several JSON structures in there, so perhaps I can hack together something based on one of those that will work. If not I'll probably have to fall back on a .loadForm() call; it'll work for me, after a fashion, but if I could get newForm() to work the way the docs let me think it works, it'll be cleaner.

(Context: I'm trying to pull multiple forms, then show a particular one after a user's action. It's cleaner if I have them all in hand, just waiting to be rendered. The best alternative I've found involves rendering *all* of them as hidden, then moving and/or revealing them after user action dictates which form should appear. It works, and yields a faster apparent response time than waiting to load the form until after the user acts, but it seems like it would be still faster and feels cleaner to me if I only render the one I need to render. I won't know if there's an actual speed gain until I'm able to test both approaches, hence this. IOW, I have two ways that work in front of me and I'm looking for a better way. Yes, as a matter of fact I *am* fussy, why do you ask?)

[SanfordWhiteman · Accepted solution]

I'm not talking about MktoForms2.getForm().  I'm talking about the /getForm JSONP endpoint. In the inner JSON is a form descriptor.

I absolutely would not use live REST API calls to pull form descriptors for rendering. It's designed for editing.

[Anonymous]

OK, but that seems to bring up an obvious follow-up question:

Why wouldn't you do that? I'm curious about why because if, as it appears, the only way to grab a Form Descriptor object is via the REST call, and the purpose of the MktoForms2.newForm() method is to create a Form object from the descriptor, it would seem Marketo intends it to be used that way. Is there a reason to create a Form object aside from eventually rendering it? If not, and getting the Form Descriptor with an eye toward rendering it is a Bad Idea, it kind of makes the newForm() method pointless.

There's an implied overhead in the REST API involving authentication, I know, which makes that approach costly in the use case of a single form on a page. But it seems to me that overhead falls away in a use case where there are multiple copies involved, such as in a single-page app or a design positioning multiple copies of possibly multiple forms on the same page (as in header/footer position of a simple sign-up form, or a tabbed interface involving the existence of forms in each tab). Or, for that matter, a use case where a server grabs the Form Descriptor objects itself before shipping them to the browser with the rest of the page code for rendering (giving a server the possibility of grabbing several objects while the authentication token is still valid, thus reducing the overhead to practically nil on a server with a reasonable traffic volume). Is there another reason I'm missing?