Kendo UI Issue with latest MSCRM Online version 9.0.2.x - kendo-ui

In this post:
Web Resource in Dynamics 365—Kendo UI destroyed by jQuery loaded by ClientGlobalContext.js.aspx
it is stated:
In version 9.0.2.54 of Dynamics 365 online, I found that the newer version of ClientGlobalContext.js.aspx loads its own version of jQuery without checking to see if one is already present.
How can I determine if the newer version of ClientGlobalContext.js.aspx loads its own version of jQuery without checking to see if one is already present?
I believe I may have same issue as in the linked question, but I'm unsure how I could diagnose that I'm in fact facing the same problems.

I suppose a simple way to do that would;
Debugging the page (e.g. F12) and seeing which jQuery files are loaded.
If you know which version of jQuery you expect to be loaded, then you can compare that to which version is actually loaded by calling alert(jQuery.fn.jquery) in your code.
alert(jQuery.fn.jquery)
<script src="https://ajax.googleapis.com/ajax/libs/jquery/2.1.1/jquery.min.js"></script>

Related

Kendo UI and MSCRM Online version 9.0.x not comaptible?

Anyone know if Kendo UI has known problems working in MSCRM Online version 9.0.2? Any word from Telerik about a fix/update? Thanks!!
Our custom MSCRM solution is working fine with MSCRM Online version 8.2.x, but not working with version 9.0.x. Testing appears to indicate problems with loss of Global context items and likely related to ClientGlobalContext.js.aspx.
I noticed a post about what sounds similar (link below).
Web Resource in Dynamics 365—Kendo UI destroyed by jQuery loaded by ClientGlobalContext.js.aspx
CRM 9.0.x introduces (and recommends) new ways of retrieving the FormContext. A lot of the old methods including Xrm.Page are being deprecated.
Here's the list of deprecated methods on MSDN
Instead of Xrm.Page you have to pass the execution context in when you configure your form scripts: Here's the MSDN article
There is a JavaScript analyser in the XRM Toolbox that can be used to identify scripts that contain deprecated code

disabling mootools in joomla 3.2

How can I disable Mootools in Joomla 3.2 without hacking core files? I have already tested this link, but it does not work for me.
Simple way is edit your templates not to include it but some things still require it.
http://pbwebdev.com/blog/removing-mootools-core-js-caption-js-joomla
Newer versions of 3.2.3 remove the tooltip js that was built in mootools but earlier ones will give you a console error if you have forms using it for the tip on the input label.
Also Kunena Forum uses mootools for the profiles and post edit tools, so I tend to write code that just includes it there.
Outside that there are plugins in the JED
http://extensions.joomla.org/extensions/core-enhancements/performance/mootools/22236
I found this page on docs.joomla.org helpful. I was using JHtml::_('behavior.framework') which loads mootools.

Is Kendo UI ASP.NET MVC open source?

I am trying to reproduce an issue with an incompatibility between Kendo UI's DataSourceResponse class and ServiceStack.Text Json Serializer. I can only locate the source code for the client side Javascript.
Does anyone know if Kendo UI's C# source code for ASP.NET MVC is available?
I supposed I could reflect it, but I wouldn't be able to share any of the code in an issue report.
This is covered under the Kendo license agreement: https://www.kendoui.com/purchase/license-agreement/kendo-ui-complete-mvc.aspx
1.3 Source Code. The Software’s source code is provided to You so that you can create modifications under the terms of this Agreement.
1.3.3 You acknowledge that the Software’s source code is confidential and contains valuable and proprietary trade secrets of Telerik. Except as provided for in Section 2.2 of this Agreement, under no circumstances may any portion of the Software’s source code or any modified version of the source code be distributed, disclosed or otherwise made available to any third party.
However, if you're filing a ticket with Telerik directly then they're a first-party, so you should share anything and everything you discover with them.

Internal links with wkhtmltopdf?

I have created a PDF from several web pages using wkhtmltopdf.
Is there a way to link across pages, for example from page 10 to 15.
I tried creating an element with an ID and then an anchor to link to it, but this does not work within the same page or across pages. It turns the link into an absolute URL and tries to open it in a web browser.
I solved this issue by updating the binary that I was using.
I was using 0.8 and switched to 0.11.0 rc1.
Ensure that it is built against QT (the latest binary at http://code.google.com/p/wkhtmltopdf/downloads/detail?name=wkhtmltoimage-0.11.0_rc1-static-amd64.tar.bz2 is.
And then just to be sure enable internal links:
--enable-internal-links
when you call the conversion
i had this issue after installing pathced version of QT
i had wkhtmltopdf 0.9.6, than i also switched to 0.11.0 rc1
then worked fine!
and no need to use --enable-internal-links. you can just turn off this option by --disable-internal-links* by default its on.
Internal links appear only to work correctly in certain builds for certain platforms. With the latest WkHTMLtoPDF 0.12.5 releases the unix builds are OK (at least for Centos and Ubuntu) and internal links are generated correctly BUT windows builds DO NOT work and leave broken links. I don't know why this is and have commented on GitHub accordingly.
Also when multiple html input documents are used any 'internal' hyperlinks between these are broken (all platforms). In other words cross input document links are NOT fixed up. This would be a really useful feature addition (particularly when generating massive reports) but sadly does not appear to be supported as yet.

We are getting "a.tmpl.complete is not a function" with v1.9

We are getting the following error with v1.9 of the profiler.
a.tmpl.complete is not a function
Search and tried looking into issue but so far no luck on what to do to correct it.
Anyone else know what to do?
This is collateral damage caused by the never ending fight for jQuery to get a templating engine.
What happened was that jQuery.tmpl was going to be the templating engine the jQuery team were going to bless. However stuff happened and for whatever reason the current contender may be jsRender.
If for any reason you depended on a particular different implementation of $.tmpl depending on ordering Mini Profiler would either break you or you would break Mini Profiler.
To overcome this I just patched MiniProfiler to use an unobtrusive version of jQuery and jQuery.tmpl. This means you can load whatever version of jQuery you want into your page but MiniProfiler will only use a special "renamed" version of jQuery (stored in the global jQueryMP)
See also: Unobtrusive jQuery html templating

Resources