Using Apache's mod_rewrite, we can move requests from an old domain to a new one very easily.

As you can tell, this is going to be a nice and easy topic.

Got the go-ahead to deploy Facebook Connect to the site I'm working on, everything certified "Works on Dev" so go to push it to the UAT servers.

This environment is load-balanced and has an F5 firewall sitting in front of it, and proceeded to fall over in spectacular fashion.

The bizarre thing is that FireFox and Chrome are happy, while IE (surprise) throws back the mystic error "Redirect Required" with content of

<meta http-equiv="refresh" content="0; url=[MY URL]>

Hmmm.

Facebook xd_receive and Cross Domain Communication

Facebook Cross Domain comms is based on using IFrames to transport data, see http://msdn.microsoft.com/en-us/library/bb735305.aspx for a full explanation.


On investigation of the Big IP logs, we could see the raw request was flagging a Cross-Domain Scripting attack for the IE request (but not for the FF request). 

My gut-feel is that this could be as a result of an IE security patch which puts a whole lot of extra stuff in the Form variables which then confuses Big IP, but this is a complete and utter guess.

The solution?  Patch a hole in the Firewall.  So not really a solution I'm afraid.

Integrating Facebook Connect with a website, we had a problem where it would work fine under FF/Chrome etc but IE could not display the FBML correctly.  It was still functioning, but instead of the Connect to Facebook button appearing it was only able to render the text, and any other FB content (such as fb:name) was not displayed.

The best part of the day was wasted until we found this http://axonflux.com/fb-connect-not-working-in-ie-f

Make sure that the page where your FB stuff lives has the following namespace declaration:

html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en" xmlns:fb="http://www.facebook.com/2008/fbml"

And yes it was.

Turns out I was adding a style in my code-behind, like this:

               spanImage.Style.Add("background", "url(" + imagesFolder + imgFileName + ")" + " no-repeat;");

The HTML in front, the span already had the background property set.

In IE, the browser happily interprets this as a last-one-in-wins, as so:

<span id="Template_ctl25_contentImageRight_spanImage" class="frame-video float-left" style="background-image:url(_includes/images/content/pictures/pic1.jpg);background:url(/RFL2010/images/about.jpg) no-repeat;;">

whereas FF 'chokes' (correctly?) and disregards the invalid second attempt to set the background.

There will be a genuine technical explanation for this, if anyone knows then feel free to leave a comment!

Been using a CMS called Immediacy, or rather it's new name of Alterian CMC, and with any system of it's kind, there are several idiosyncracies that must be overcome at first.

I've listed my findings below, if you find any are inaccurate or I am mistaken, then leave a commend and tell me so!

It doesn’t like to run under IE8, even on compatibility mode...

 

... well, most of the times it does, but there might be that one template (see event details page for an example) that is completely goosed.  Of course, it doesn’t even boot up in Chrome/FF/Safari, so your safe choice is to run this via genuine IE7.  Either a virtual m/c or Citrix install should be good for this.

 

It can’t handle <div> tags within the editor...

 

... well, it sort of can, but will result in a bizarre problem where any plug-in which spits out <div> tags, and is then subsequently enclosed in <p> tags will fail to persist any changes.  Use tables in your <%--> <--%> tags in the Form.htm or templates. 

 

Page preview looks weird in IE

 

When you preview, it creates its own stylesheet called “PagePreview.css”, hoovers all the styles from your actual stylesheets and puts it in here.  Of course, if you’re over-riding styles to tweak IE, these are going to be over-written, and your page is going to look like a Cubist masterpiece.  Thankfully the preview will work in Firefox, so just copy + paste the URL and you’re able to see what the page actually looks like.

 

Don’t use hyphens when providing Ids to plug-ins

 

For example, don’t use the following:

 

<imm:area name=”unique-name” runat=”server” id=”unique-ID”>

 

The Application caches the root address the first time it is accessed

 

If you have two distinct URLs which resolve to the same application, for example “mysite.co.uk” and “10.100.104.40” then note that the FIRST TIME you access the site, whichever way you access it will be cached by the system.  This can result in the problem whereby it will try and fetch resources using an invalid (unavailable) path. 

 

For example, if the IP address used above is only accessible internally, then clients accessing via the external URL are served up paths to the internal IP address, which results in the editor application seizing up.

 

The CSS is cached until you completely terminate the session

 

And simply logging out doesn’t seem to do this, you must close Internet Explorer entirely.  This only happens with CSS, so if you make a change to the CSS, log out and back in again, these changes are not reflected.  Note that page and plug-in templates (though the code-behind has to be re-compiled) are not cached in this way.

 

Editable Areas must be nested within divs that have explicit widths set

 

A page might preview perfectly well, but within the editor the editable area will only show as a thin dashed line, not allowing the user to edit or see what’s going on at all.  We solved this by explicitly defining a width on the container div.

 

If you get a SOAP error on loading the application/plugin

 

Browse to <website>/_immediacy/editor/plugins.ashx

 

One of the most useful tips to take note of.

 

Plugins don’t like capital letters in the fields.

 

I reckon it’s also safer not to use auto-properties.

 

If “Please Wait” appears for more than 10 seconds on loading up the editor...

 

... it’s likely hung and you need to hit refresh to give it a jolt.  Be careful not to just quit IE, or you might get the problem below.

 

User is already logged in message appears

 

You need to unlock the user by going into Admin|Web Site|User locking.  This often happens when the app closes without being able to successfully log out.

 

“This plug-in cannot be edited”

 

The plug-ins load asynchronously, so you will likely get this message when you’ve just rebuilt the binaries.  Give it 30 seconds or so to finish doing what it’s doing and try again.

 

 

 

These are my findings so far, and I’m willing to give the product the benefit of the doubt due to my inexperience – some of these problems might manifest themselves due to invalid configurations or code.  Hope this does help anyone who uses this system for the first time.

Interesting article on why Fireworks is better than Photoshop for squeezing more bandwidth out of your site:

http://blogs.popart.com/2009/02/why-aren-t-you-using-fireworks-to-compress-images/

Before I forget, here is a link which shows how to achieve rounded corners in IE

http://msdn.microsoft.com/en-us/library/bb250413(VS.85).aspx

Looking at how to extract data from Google Analytics, there is now a data export API available.  Although this is still in beta, with Google, what isn't?! 

http://code.google.com/apis/analytics/docs/gdata/gdataDeveloperGuide.html

The basic idea is that you split your results according to Dimensions and Metrics; where Dimension supplies the cross-tabulated groupings.  For example, you can analyse your page views by country.

This is all good, until you see how to access it.  There is no official .NET wrapper for this, although there is some code available on Google Code - http://code.google.com/p/google-gdata/source/browse/#svn/trunk/clients/cs/samples%3Fstate%3Dclosed 

Still to test this stuff out though, but will post back the details when I do.

For you propellerheads, there's nothing stopping you from making direct HTTP GET/POST requests.

Looking into creating a widget that webmasters can embed on their own page, I have to decide HOW I'm going to develop this.

The options are:

• IFrame
• Javascript

There's a really good article here that explains the options.

For this very simple widget, right now I'm thinking IFrame, as there's no point in over-complicating things.  But we'll see when the final requirements spec comes round!

Okay, so this is hardly a ground-breaking topic.  But I think it's a valid showcase as to how rich, UI experiences can be delivered via the browser without costing the earth.

Picture the scene - I have a web page with a jquery Grid (FlexiGrid - though I think I will be upgrading to jqGrid due to it's continued developer support - but more on this later) and a toolbar (a very cool Vista style toolbar).

One of the commands available on this toolbar is Print. 

When the user clicks this command, a jquery UI dialog pops up, displaying a selection of valid reports which the user may select.

This reports list is generated from the server.

So, if all of this was to be done as the page loads - well, you can imagine the performance would be unacceptable.  But I want to keep the user experience rich - I don't want them navigating from the grid to another page when they click Print.  So I need to do this using AJAX.

The process is as follows:

 

The Print Button Handler calls the PrintWebService via an AJAX call using some jquery magic as so:

 $.ajax({
                type: "POST",
                contentType: "application/json; charset=utf-8",
                data: "{}",
                dataType: "json",
                url: "http://localhost/PrintService/PrintService.asmx/RenderPrintDialog",

                success: function(data) {
                    $("#printdialoginner").html(data.d);
                    $("#printdialog").dialog("open");
                },

                error: function(xhr, status, errorThrown) {
                    alert(status);
                    alert(errorThrown);
                }
            });

Inside the service, we can get our reports from the server (from the database) at our leisure.  Ish.

Now comes the clever part.  To return the UI, all we're doing is churning back some HTML, right?  But what if we want to be able to visually SEE what we are going to return, at design-time? 

Thanks to Scott Gu, we can get full VS designer support when creating our dynamic UI - check it out - http://weblogs.asp.net/scottgu/archive/2006/10/22/Tip_2F00_Trick_3A00_-Cool-UI-Templating-Technique-to-use-with-ASP.NET-AJAX-for-non_2D00_UpdatePanel-scenarios.aspx

So we create our .ascx controls as normal, pass the path to the ViewManager, and let it get it's hands dirty.  It also keeps a nice, clean MVC separation.

Using this trick, I've been able to deliver a seamless, rich UI without having noticeable effects for the user.  Okay, so there is a slight delay when they bring up the Print dialog for the first time (I know, I've not mentioned caching here but do I need to?) but it's barely noticeable.

A friend who works in web design recently pointed me in the direction of a CSS framework which could greatly reduce the time spent laying out a website.

It's called the 960 grid system, and you can find it here.

Having checked out the demo and introductory screencast, it is definitely something I'll be looking into for doing web sites in the future.