I performed an upgrade from 7.0 => 7.1. The only issue (so far) that I see is I'm getting a JS undefined exception at the orange highlighted line in the image "sf exception.png". That namespace corresponds to a custom control that I have made, named SitefinityWebApp.Widgets.EmailNotificationForm, that inherits from Telerik.Sitefinity.Modules.Forms.Web.UI.FormsControl.
"sf exception.png" - uses SitefinityWebApp.Widgets.EmailNotificationForm (breaks) "sf default.png" - uses Telerik.Sitefinity.Modules.Forms.Web.UI.FormsControl (works fine)
It seems that in 7.1, there's additional script being generated in the spot outlined in red in the images. This script seems to be responsible for some of the new AJAX functionality related to form submissions. The Telerik.Sitefinity.Modules.Forms.Web.UI.FormsControl JS object is being created and referenced on the page (as an embedded resource). However, my custom control has no such object being defined (one of the WebResource.axd scripts still creates the Telerik.Sitefinity.Modules.Forms.Web.UI.FormsControl object), so this is causing a JS exception.
Is there a new process for using or creating a control that inherits from FormsControl, to make use of the new AJAX? Is there anything I need to add onto my existing custom form control to inhibit this script from being created so that I don't get this error? Thanks.
EDIT: I added a screenshot of the WebResource.axd that creates the Telerik.Sitefinity.Modules.Forms.Web.UI.FormsControl object. This is getting created with the same name regardless of the whether the form control is the default or a subclass of it. There seems to be a disconnect between the creation of it, and its consumption on the page.
I'm seeing this too...clear regression bug, screaming for internal build fix :)
Good. Glad I'm not the only one. I guess I'm holding off on an upgrade until it's fixed. I'll submit a ticket for this as well to get visibility of the issue.
disregard. was getting 500 error on posting.
Same issue here with our custom forms control (see Fenêtre Form Extension @ Sitefinity Marketplace)
I have already submitted a support ticket for this. Hoping you guys come up with a workaround or a bug fix soon.
public override IEnumerable<
var baseScripts =
var all = baseScripts.ToList();
/// <reference name="MicrosoftAjax.js"/>
SitefinityWebApp.CustomForm = function (element)
/* --------------------------------- set up and tear down --------------------------------- */
initialize: function ()
dispose: function ()
Thank you. I appreciate the response. I'll see how this works. Thanks.
Overriding the script references and using the base scripts (second solution) works for me. Thanks.
Ok, I got around to implementing this but it's still a quirky solution.
If I have the GetScriptReferences and GetScriptDescriptors methods return empty collections, I lose client-side validation. This, of course, kinda sucks.
If I reference the script (the empty one that calls base methods in the post above), it still (obviously) doesn't provide client-side validation.
The only way I could get it to work was to find the compiled script at Telerik.Sitefinity.Modules.Forms.Web.UI.Scripts.FormsControl.js, modify the namespace of that to fit my custom control, and reference that from my control. At this point, I now have client-side validation.
What sucks is, not only is this just a copy of what's already in the assembly (just with a different namespace), I have several forms that are custom that will essentially need this same exact script for every custom form control. This is because each control has a name, which needs to be reflected in the namespace of its associated JS file.
For my 4 custom controls, I need 4 (nearly) identical JS files referenced.
Is there a way to force my custom controls to use the native JS? I assume this means I need to fake the namespace that my control is running under. The namespace of my custom control is SitefinityWebApp.Widgets.PopulatableForm and my JS has a namespace for, and creates a identical control for, SitefinityWebApp.Widgets.PopulatableForm based on the same name.
Unless there's a better option. So far, this new pattern sucks. Worst case, I lose client-side validation, which isn't the end of the world.
Thanks! This is better. Being forced to add a script that simply calls base functions isn't great, but it I'll live with it. Thanks again.
Thanks for the info Nikola. This has helped me with creating Field Control, too.
May I suggest that this is incorporated (or linked to) on the documentation page called "build a custom field control implement the client control"