Something I meant to include in yesterday's post was around the steps I'd taken to get TypeKit working with the new GoogleApi WebFont Loader hosted version.
As I'm not using Google AJAX api decided to just call the file directly, but I couldn't seem to get it to work using the docs on GoogleApi using the WebFontConfig object, however following the directions on the Git hub seemed to work better:
Call the webfont.js file:
<script type="text/javascript"
src="http://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js"></script>
Then call load on the WebFont object:
WebFont.load({
typekit: { id: 'gjb1flq' }
});
Passing in your TypeKit Id, (not the Kit Id as is implied in the docs).
To reduce the "Flicker of Unstyled Text" I then added the following to my CSS:
.wf-loading h1 { visibility: hidden; }
.wf-loading h2 { visibility: hidden; }
.wf-loading h3 { visibility: hidden; }
.wf-loading #logo p { visibility: hidden; }
.wf-loading code { visibility: hidden; }
.wf-loading pre { visibility: hidden; }
.wf-active { visibility: visible; }
Basically, as the web fonts are loading, the WebFont.js applies the .wf-loading style to html element, then once they are all in, applies the .wf-active style.
Rather than following the guidance on the git hub page (which suggests having the base state of the h1 hidden, and only showing it when the fonts are active) I've gone down this route, so if the script fails to load, or is turned off, the titles, code, etc will still show, albeit in their default fonts.
If I really wanted to I guess I could implement font based activation as well, using the .wf-adelle1adelle2-n7-active event.
Filed under: AJAX
Ok, this one's pretty easy really, Initially we were just running with Stefan Großner's tips and code samples for using friendly URLs everywhere, and his hints on How to enable AJAX with MCMS and ASP.Net 2.0.
This was generally working fine for us, the page was requested by the ScriptManager calls, the ScriptManager in the master page hooked into the request, read the query strings it was looking for, rendered out the correct JavaScript, and stopped the page execution - all as you'd expect.
However, as development of the site progressed, we then built a control that allowed us to show or hide its child controls based on whether a MCMS placeholder on the posting contained any content - for example, we have an article page that can optionally display an image, and the image can optionally have a caption appearing below it - if there's no image, then everything under it should naturally float up the page, and the same for no caption. As there's a certain amount of html and css needed to get this to work, it's nicer if this isn't rendered out if there's no image, hence this control. However, to get this to work properly, with nested conditional controls, we needed to do our magic in the AddParsedSubObject method which runs before the ScriptManager did it's stuff - and if you try and call the posting templated directly without a CMS context (all those NR querystrings) and then try and access the CMS objects it all goes belly up.
Thankfully, there's a simpe solution - the ToolkitScriptManager that is part of the ASP.Net AJAX Control Extensions has a very nice property on it: CombineScriptsHandlerUrl - by default the ToolkitScriptManager will attempt to combine all the required scripts into one nice big script, instead of lots of little ones - and this property tells it what page it should call to do this - I think technically you should use an .ashx page for this - although an .aspx page with the ToolkitScriptManager on it works just as well - there's some detailed information on the CombineScriptsHandlerUrl here. Setting this property to a non-CMS page has fixed all our problems.
Another nice feature in ASP.Net 3.5 is the ScriptManagerProxy - this allows you to place a ScriptManager (or ToolkitScriptManager) on your master page and then place the ScriptManagerProxy in the page or user control as required. This means that to register a client script block instead of writing something like:
var scriptManager = ToolkitScriptManager.GetCurrent(Page);
if (null != scriptManager)
{ scriptManager.RegisterClientScriptBlock([...]); }
You can just call the local ScriptManagerProxy with the same methods. All very nice.
Part of the Series: The joys of using .Net 2.0, .Net 3.0 and .Net 3.5 with MCMS
Filed under: AJAX
Well, I suppose I’d best admit it – otherwise there’ll be no more blog posts for a while. The current project I’m working on is still in MCMS – an issue with the clients deadline and us get the team up to speed with MOSS really – however we are using the latest versions of the framework – so that means ASP.NET 2.0 on the server, and taking advantage of the features in .Net 3.5 where appropriate.
The main things we’re using so far are:
(Seeing as the first item on that list has been sitting on my hard drive for about two weeks now, I guess this is going to be an instalments piece - I’ll update the list with links as things are posted)
Filed under: AJAX
Getting AjaxPro (CodePlex Start Kit) to behave in the Global Assembly Cache (GAC). While the means to do this are available in the Starter Kit, the "Quick Guide" doesn't really cover the main points here.
If you need to deploy AjaxPro to a web server via the GAC here are the key points to remember:
Modify your web.config as follows (this is for the .Net 1.1 version, for the .Net 2.0, just change "AjaxPro" to "AjaxPro.2"):
In configSections block add the following:
<sectionGroup name="ajaxNet">
<section name="ajaxSettings"
type="AjaxPro.AjaxSettingsSectionHandler,
AjaxPro,
Version=6.10.6.2,
Culture=neutral,
PublicKeyToken=4735ae9824c7d3ec" />
</sectionGroup>
Remember to update the version number to the version you are using - Michael Schwarz is quite prolific with his releases.
Then add the following as a direct child of configuration:
<ajaxNet>
<ajaxSettings>
<urlNamespaceMappings useAssemblyQualifiedName="true" allowListOnly="false" />
<debug enabled="false" />
</ajaxSettings>
</ajaxNet>
The key element here is the useAssemblyQualifiedName="true" attribute. This tells the AjaxPro library to output the calls to your AjaxMethods as fully qualified paths - with the version number, culture and public key information.
Finally, add the following block as a child of the system.web element:
<httpHandlers>
<add verb="GET,POST"
path="AjaxPro/*.ashx"
type="AjaxPro.AjaxHandlerFactory,
AjaxPro,
Version=6.10.6.2,
Culture=neutral,
PublicKeyToken=4735ae9824c7d3ec"/>
</httpHandlers>
Again, updating the version number as required.
You can then follow the rest of the quick start guide to set up your first AjaxPro page.
I'm going to write up a note on error reporting tomorrow hopefully, but the key point here is you'll notice that I left in the Debug element in the ajaxNet section, set the value to true and you will be able to retrieve the stack, trace and lines from the exception as well as just the message.
Filed under: AJAX