I've noticed an odd happening with fragment caching in MOSS 2007: a user control declared in a master page will not be cached but when that same user control is wrapped in a second user control and the wrapper control is declared in the master page, the wrapped control caches as expected.
Things look like this:
Masterpage:
<%@ Register tagprefix="CustomControls" tagName="Container" src="~/UserControls/Container.ascx" %>
<%@ Register TagPrefix="CustomControls" TagName="ToCache" Src="~/UserControls/ToCache.ascx" %>
<CustomControls:Container id="container" runat="server"/>
<CustomControls:ToCache ID="toCache" runat="server"/>
Container.ascx:
<%@ Register tagprefix="CustomControls" tagName="ToCache" src="~/UserControls/ToCache.ascx" %>
<CustomControls:ToCache id="toCache" runat="server" />
The resulting HTML looks like this:
<body>
<div id=”container”>
<div id=”toCache”>... </div> // This caches
</div>
<div id=”toCache”>... </div> // This won’t cache
</body>
The ToCache.ascx user control sets a simple @OutputCache directive in the markup and I can't see anything that would limit output caching in the master page, the hosting .aspx page, or the web.config.
I haven't ripped this apart and tried it in a clean site but I'm definitely experiencing this behaviour within the context of the wa.com development environment. I know MOSS controls (and somehow enhances) output caching but I have yet to look into how this works--as far as I know, I'm using the default output caching configuration.
Update: I wonder if this has anything to do with the control being hosted in a master page instead of an aspx page layout. Slim chance...
Thursday, 21 June 2007
Disabling the "Reply to All" email button
Gotta love it when the CEO sets the technology direction in your office... (the identities of those involved in this memo have been obscured but this is a genuine email). Guess that's the final nail in the coffin for Outlook on my desktop.
Surely there's a Dilbert strip for this?
From: xxx
Sent: Thursday, 21 June 2007 10:25 AM
To: All Staff
Subject: Disabling the "Reply to All" email button
The CEO has requested that Corporate IT disable the “Reply to All” button for all staff in order to assist with email and time management.
We will trial this for a few weeks and then I will seek feedback on how effective this has been and request executive directors to bring the feedback to the executive management team for discussion.
The process will happen progressively over the next few days.
Thanks
xxx
Executive Director
Surely there's a Dilbert strip for this?
From: xxx
Sent: Thursday, 21 June 2007 10:25 AM
To: All Staff
Subject: Disabling the "Reply to All" email button
The CEO has requested that Corporate IT disable the “Reply to All” button for all staff in order to assist with email and time management.
We will trial this for a few weeks and then I will seek feedback on how effective this has been and request executive directors to bring the feedback to the executive management team for discussion.
The process will happen progressively over the next few days.
Thanks
xxx
Executive Director
Wednesday, 20 June 2007
Units of Time
One thousandth of a second = 1 millisecond (ms)
One millionth of a second = 1 microsecond (µs)
One billionths of a second = 1 nanosecond (ns)
See http://www.wilsonmar.com/1clocks.htm for great discussion about time in a networked world.
One millionth of a second = 1 microsecond (µs)
One billionths of a second = 1 nanosecond (ns)
See http://www.wilsonmar.com/1clocks.htm for great discussion about time in a networked world.
Monday, 18 June 2007
Visual Studio 2005 Debugger Won't Break
Ever encounter a situation where the Visual Studio 2005 debugger absolutely refuses to break? I ran up against this problem this afternoon (yet again) and it took me a moment to discover the reason why.
Here's the scenario:
Here's the problem:
The user control in question had an OutputCache directive set to cache the control for sixty minutes. Removing this little devil resulted in a slap of the forehead and allowed the debugger to break as expected.
The OutputCache directive prevents the control being added to the control tree of the hosting page at runtime; ASP.NET loads an existing version from the cache instead of executing the control code.
...kind of a silly problem since the debugger gives you no inidication the control is loading from the cache but it's all too easy to forget about this sort of thing!!! The golden rule I usually try to apply is to hold off on performance tuning until the very end of the development/testing process and this should generally include large-scale caching. Obviously this doesn't apply in a maintenance situation.
Here's the scenario:
- A standard user control with a code-behind file is hosted in an insignificant ASPX page;
- The user control code-behind is doing some work to render the control and also has a handler method subscribing to a button click event;
- The relevant assemblies are built in debug mode and are deployed to a separate development server along with the associated markup files;
- The assemblies on the server are the same version as those on the development workstation;
- The application is configured as it should be in IIS and the debug attribute on the web.config's compilation element is set true;
- The VS 2005 remote debugger is installed and running on the dev server;
- The VS 2005 "client" is attached to the remote server's ASP.NET worker process (w3wp.exe in this case);
- Two breakpoints are set on the user control code: one on Page_Load and one on the button click handler;
- Browsing to the host page doesn't cause the debugger to break (except intermittently, sometimes following an iisreset)...
Here's the problem:
The user control in question had an OutputCache directive set to cache the control for sixty minutes. Removing this little devil resulted in a slap of the forehead and allowed the debugger to break as expected.
The OutputCache directive prevents the control being added to the control tree of the hosting page at runtime; ASP.NET loads an existing version from the cache instead of executing the control code.
...kind of a silly problem since the debugger gives you no inidication the control is loading from the cache but it's all too easy to forget about this sort of thing!!! The golden rule I usually try to apply is to hold off on performance tuning until the very end of the development/testing process and this should generally include large-scale caching. Obviously this doesn't apply in a maintenance situation.
[Update: a few additional tips...
- Double-check the deploy location of your assembly; if it's in the GAC you can deploy to the bin directory until the cows come home but ASP.NET will continually load the assembly from the GAC. Either remove the GAC'd assembly or deploy to the GAC (you can also deploy PDB files to the GAC but you need to drop them under gac_msil using the command line).
- Once you've attached the debugger, bring up the Modules window (Debug -> Windows -> Modules); locate your assembly and verify whether symbols have been loaded and the location where the assembly was loaded.]
Monday, 11 June 2007
Top Ten of Programming Advice NOT to follow
I don't agree with everything here but there are some good points in there...
http://www.chrylers.com/top-ten-of-programming-advice-to-not-follow
http://www.chrylers.com/top-ten-of-programming-advice-to-not-follow
Friday, 1 June 2007
Everything you always wanted to know about Javascript but were too afraid to ask
I’ve been hacking with Javascript since ’97 or so and it always seemed so accessible I never thought about sitting down to actually discover what it’s all about. Between AJAX and widgets and funky calendar controls I've recently came across constructs I'd never seen before—admittedly Javascript is, even after nearly x years, a mystery to me. Or rather it was, until I read this article:
http://odetocode.com/Articles/473.aspx
The article is reasonably short, very concise and explains a lot about the language itself. Better still, the article is targeted at .NET C# developers who know more about classes and method than prototypes. The examples are great as well.
Looks like Javascript isn’t going away any time soon so I’d suggest this article as a great intro to the rest of your life as a Javascript developer ;-)
http://odetocode.com/Articles/473.aspx
The article is reasonably short, very concise and explains a lot about the language itself. Better still, the article is targeted at .NET C# developers who know more about classes and method than prototypes. The examples are great as well.
Looks like Javascript isn’t going away any time soon so I’d suggest this article as a great intro to the rest of your life as a Javascript developer ;-)
Thursday, 31 May 2007
Localizing Web Parts, Custom Controls, and Class Libraries
If you've dealt with the ResourceManager in .NET 1.x--or never touched resources altogether, moving to .NET 2.0 simplifies the process to the point where it all seems too simple. Simplicity is generally a good thing, of course, and once you understand localization in .NET 2.0 you'll probably agree there's no reason why pretty much every application shouldn't be localized from the beginning (I'm in the process of localizing and existing MOSS 2007 site, hence the sentiment just expressed).
Localization is a good thing because it:
Working with resources is really straight forward if you're writing user controls or web pages (apparently WinForms are just as straightforward but I don't know much about WinForms) because both the UserControl class and Page class both derive from System.Web.UI.TemplateControl. TemplateControl exposes the protected GetGlobalResourceObject ( ) and GetLocalResourceObject ( ) methods. When a user control or web page has a resource file available to it, you also get strongly-typed access to the file like this:
Resources.MyResourceFile.MyKey;
(where 'Resources' is some weird namespace that only comes to life when you've got .resx files in your project)
On the other hand, if you're writing web parts, custom controls, or class libraries, you're probably not deriving from TemplateControl (especially in the web part case where you class inherits WebPart). You can still add resource files to you project and use a ResourceManager to pull out the stuff you need but there's an easier way.
Localization is a good thing because it:
- Allows you to refactor hard-coded strings for labels, menus, and so on out of your code and into .resx files;
- Enables your application to display a user interface relevant to users of different languages.
Localization won't translate your interface for you--that still has to be done manually.
Visual Studio 2005 now takes care of all the hard work needed to develop a fully localized app in no time at all. Firstly, it provides a convenient designer for creating resource files through which you can add strings, images, icons, and text/script files. Secondly, any .resx file added to your project are automatically compiled to a .resources file and linked to your main assembly. Finally, a resource file wrapper class is generated automatically, granting you strongly-typed access to the contents of your resource files. What more could you ask for?!?Working with resources is really straight forward if you're writing user controls or web pages (apparently WinForms are just as straightforward but I don't know much about WinForms) because both the UserControl class and Page class both derive from System.Web.UI.TemplateControl. TemplateControl exposes the protected GetGlobalResourceObject ( ) and GetLocalResourceObject ( ) methods. When a user control or web page has a resource file available to it, you also get strongly-typed access to the file like this:
Resources.MyResourceFile.MyKey;
(where 'Resources' is some weird namespace that only comes to life when you've got .resx files in your project)
On the other hand, if you're writing web parts, custom controls, or class libraries, you're probably not deriving from TemplateControl (especially in the web part case where you class inherits WebPart). You can still add resource files to you project and use a ResourceManager to pull out the stuff you need but there's an easier way.
- Create a new class library project; name it MyCustomWebParts or whatever you like. The name you give your project will also become the name of the assembly and be used as the default namespace for any classes you add and any classes added by Visual Studio (this last bit is really important).
- Create a new resource file (Add new item...) named strings.resx in the root of the project (you can also place your resource files in an arbitrarily-named folder but doing so will change how the file is accessed programmatically). Add a new string with a name of labelText and a value of Hello World.
- Create a new class that derives from
System.Web.UI.WebControls.WebParts.WebPart; name it MyWebPart or whatever you like. - Add a CreateChildControls ( ) method to your class and within the method body, instatiate a new Label object and add it too the Controls collection.
- Immediately after the Label is instantiated, set its Text property from the resource file. You do this by referencing [the default namespace for the assembly].[the name of the resource file with no extension].[the resource key name].
- Add or update a globalization element to your web.config file and set both the culture and uiCulture attributes to auto:
<globalization uiculture="auto" culture="auto" />
This works on a regular ASP.NET site but MOSS doesn't automatically assign the browser's current language to the System.Threading.Thread.CurrentThread.CurrentCulture and CurrentUICulture properties so you may wish to do this yourself and forego the above web.config setting. - Build the project and register the web part in a .aspx page--and that's it!
namespace MyCustomWebParts
{
public class MyWebPart : WebPart
{
protected override void CreateChildControls ()
{
Controls.Clear ();
Label label = new Label ();
label.Text = MyCustomWebParts.strings.labelText;
Controls.Add (label);
}
}
}
As mentioned, adding a .resx file to your project prompts Visual Studio to generate a strongly-typed wrapper class for accessing the file; this class is created in the project's default namespace. If your web part or control is the same namespace you don't need to qualify your resource file within the MyCustomWebParts namespace--you can access it directly: strings.labelText. If you've got multiple namespaces in your project (or not) it's probably a good practice to always qualify the resource class name.
If you do drop your .resx files into a folder you'll need to modify the way you reference them:
MyCustomWebParts.MyFolder.strings.labelText;
Either way, IntelliSense will help you out as you go if everything's in the right place.
To tweak performance, you can tell ASP.NET which resources are contained in the default assembly by adding an attribute to your class library's AssemblyInfo file:
[assembly: System.Resources.NeutralResourcesLanguageAttribute ("en")]
And the end result: localized web parts, custom controls, and class libraries. Cool.
Wednesday, 16 May 2007
A comprehensive review of how to make an anchor tag do nothing
What's the best way to fire a javascript event from an anchor tag without mucking up your navigation? For that matter, what's the best way to do anchor tags all together? Have a look at the tests below and review the source before making your own decision (you might want to copy the source out to your html file).
Here's a few things to consider:
- We do not usually want a link to return the caret to the top of the page.
Javascript may be disabled on the client side (but all solutions presented here are javascript-dependent) - Microsoft apparently recommends against using javascript: calls from within the HREF element of an anchor tag and its use may also impact accessibility.
- If using a click event handler, place a hash in the href attribute and a return false; as the final code for the onClick attribute; ensure any preceding function calls can be interpreted and executed or the return false may never be reached.
- Alternatively, use another tag (not an anchor tag) and its onClick attribute.
a (without href) (no underline)
a href="wwww.mysite.com" (normal link)
a href="" (opens containing folder in IE (when run without a web server); scrolls to top of page in FF)
a href="#" (scrolls to top of page)
a href="javascript:" (works in IE but pops up javascript console in FF)
a href="javascript: return false;" (javascript error)
* a href="javascript: void(0);" (works but may cause problems)
* a href="javascript: myFunc();" (works if myFunc () is defined - myFunc does not need to return false)
a href="javascript: myUndefinedFunc ();" (javascript error)
a href="top" (scrolls to top of page)
a href="null" (no underline)
* a href="#bookmark" (works if a name is defined immediately above)
a onclick="return false;" (without href) (no underline)
* a href="" onclick="return false;" (works)
* a href="#" onclick="return false;" (works)
a href="#" onclick="myBrokenFunc; return false;" (javascript error and scroll to top because return false never executes)
* a href="#" onclick="myOnClickFunc (); return false;" (works)
* styled span (works but doesn't "select" on click or change color on visit)
* = A preferred way to do nothing links
Friday, 11 May 2007
Truths
A man in a hot air balloon realised he was lost. He reduced altitude and spotted a woman below. He descended a bit more and shouted, "Excuse me, can you help me? I promised a friend I would meet him an hour ago, but I don't know where I am".
The woman below replied, "You're in a hot air balloon hovering approximately 30 feet above the ground. You're between 40 and 41 degrees north latitude and between 59 and 60 degrees west longitude."
"You must be in I.T," said the balloonist.
"I am," replied the woman, "How did you know?"
"Well," answered the balloonist, "everything you told me is technically correct, but I've no idea what to make of your information, and the fact is I'm still lost. Frankly, you've not been much help at all. If anything, you've delayed my trip."
The woman below responded, "You must be in Management."
"I am", replied the balloonist, "but how did you know?"
"Well," said the woman, "you don't know where you are or where you're going. You have risen to where you are due to a large quantity of hot air. You made a promise, which you've no idea how to
Wednesday, 9 May 2007
The New westernaustralia.com Launched
Cool! Check out the latest site launched by our team here at Tourism Western Australia:
www.westernaustralia.com
The site launched successfully on Sunday and is built on Microsoft Office SharePoint Server 2007 (MOSS 2007). The site is branded to within an inch of its life and plays nicely with the BDC to pull tourism information from the Australian Tourism Data Warehouse.
Well done to the developer team (who, incidentally, started working on with MOSS back at beta 2)!
www.westernaustralia.com
The site launched successfully on Sunday and is built on Microsoft Office SharePoint Server 2007 (MOSS 2007). The site is branded to within an inch of its life and plays nicely with the BDC to pull tourism information from the Australian Tourism Data Warehouse.
Well done to the developer team (who, incidentally, started working on with MOSS back at beta 2)!
Subscribe to:
Posts (Atom)