Upgraded to 7.1. JavaScript error with custom form control?
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.
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.
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.
Hi all,
The problem comes from that the new FormsControl has now a ScriptView and initializes client-side as well. It is trying to initialize your custom control on the client, however, it loads the default inherited control scripts references, which results in your namespace and control, not registered and not defined.
The solution is either to return no scripts - the control will not be initialized client side:
public override IEnumerable<ScriptDescriptor> GetScriptDescriptors() return Enumerable.Empty<ScriptDescriptor>(); public override IEnumerable<System.Web.UI.ScriptReference> GetScriptReferences() return Enumerable.Empty<ScriptReference>(); public override IEnumerable<System.Web.UI.ScriptReference> GetScriptReferences() string assemblyName = typeof(CustomForm).Assembly.FullName; var baseScripts = base.GetScriptReferences(); var all = baseScripts.ToList(); all.Add(new System.Web.UI.ScriptReference("SitefinityWebApp.CustomForm.js", assemblyName)); return all; /// <reference name="MicrosoftAjax.js"/>Type.registerNamespace("SitefinityWebApp");SitefinityWebApp.CustomForm = function (element) SitefinityWebApp.CustomForm.initializeBase(this, [element]);;SitefinityWebApp.CustomForm.prototype = /* --------------------------------- set up and tear down --------------------------------- */ initialize: function () SitefinityWebApp.CustomForm.callBaseMethod(this, 'initialize'); , dispose: function () SitefinityWebApp.CustomForm.callBaseMethod(this, 'dispose'); ;SitefinityWebApp.CustomForm.registerClass('SitefinityWebApp.CustomForm', Sys.UI.Control);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.
Hi,
I am glad the issue is fixed. Meanwhile we added a KB regarding this problem, describing the solution by registering your control client-side and referencing the script. Here it is, for future reference.
Regards,
Nikola Zagorchev
Telerik
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.
Hello Ryan,
Could you please try the code in the KB article, mentioned in the previous reply? I modified the provided code snippets when publishing the KB and made it using the base scripts, which means the core script and validation will be added. The custom form control should inherit from the base one - Telerik.Sitefinity.Modules.Forms.Web.UI.FormsControl , as in the KB and not from the base system control. This should call all base scripts, as well. If the problem still persists, write back to us.
Regards,
Nikola Zagorchev
Telerik
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.
Hi ,
This is because the new forms control is now a ScriptView control and shold be initialized client-side and this needs to be done for the current custom control. With the inheritance, you can also overwrite some of the default functions executed client-side. Actually, the same inheritance and base scripts loading is done automatically when creating a field control or a widget designer by Thunder.
Regards,
Nikola Zagorchev
Telerik
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"
Thanks,
Peter.