Rick Strahl's Web Log

Forcing Client Windows to pop up as Windows in Tabbed Browsers

Rick Strahl — Tue, 22 Jul 2008 20:05:01 GMT

By default if you open a new window in Tab based browsers like FireFox 3 or IE 7 new windows pop up in new tabs. In most situations this is the desirable behavior, but sometimes it's in fact required to get a new window to pop up on the desktop and get it activated immediately.

I ran into this situation today in a complex Intranet application that basically allows editing of several sets of related data simultaneously to content in the 'main' window. While I fully agree with the the school of thought that believes too many windows in Web UIs are evil, in this situation I really couldn't see good alternatives. Alternatives are opening in Tabs (not acceptable if more than one window gets opened at a time) or using DOM internal pop up windows (ala HoverPanel). The latter also isn't really acceptable as the pop up forms are rather complex and page management would get increasingly complex to manage in a single page especially since often times the SAME forms are popped up with different data.

So in the end I decided separate windows are probably the best choice. It's been a while since I had last thought about this so I figured a quick window.open() would be all that's needed but as I found out, that only opens new tabs. How do you 'force' windows to open as windows rather than in a new tab?

As it turns out it's quite simple to do - you can specify a few parameters in the window options to effectively force the window to pop up as a window instead of loading into a tab:

var childWindows = [];

function showApplet(appletName,id)

   var win = window.open( String.format("applet.aspx?applet={0}&id={1}",appletName,id),
                          "_blank",

                    "resizable=yes,scrollbars=yes,width=800,height=600,status=yes" );

   win.focus();  // force active

   childWindows.push(win);  // save for later release

Any time window.open() specifies parameters that are explicitly attributable to a 'window' - like resizable, scrollbars or height or width - the window does in fact get popped up as a window. Omit any of these window specific parameters and the window loads using the browser's default settings. Note the win.focus() which is useful in forcing the new window to be activated. This is especially useful if you create only one new window and repeatedly load content into it as these windows generally do not come to the top of the desktop window stack.

Speaking of default settings, window loading can also be controlled via the browser settings. In FireFox you can specify whether to open windows in tabs or in a new window:

Other browsers have similar options.

However, the above code snippet allows overriding these settings so there really should never be a reason to choose the Open in New Window option.

Cleaning up Opened Windows

Note that when building your own applications and forcing windows to pop up it's often also important to remove windows again when you're done with your page, or after an operation has completed. In my app scenario for example I had to close a window after some action occurred in the child window or a final Save operation occurs in the main window for example.

So it's useful to keep track of windows opened in a page and then maybe even automatically close the child windows when the page is navigated off of. You'll notice in the code above that windows are stored in a childWindows array, which is done for precisely this reason. To close out all windows the following code is used:

function unloadChildWindows()

    for (var x=childWindows.length-1; x > -1; x--)

        var win = childWindows.pop();

        win.close();

        win = null;

$(document).ready(function(){

    $(window).unload( unloadChildWindows );

});

which runs through each of the child windows and closes them. If you want to automatically close all windows when the page is closed or navigated off of you also hook the window.unload event and fire this function - here using jQuery to fire the event and route it to the function.

All that said, it shouldn't be often that you need to pop up windows on a Web page. It's a bad Web UI practice in general, but in those occasions that you must it's usually a requirement that can't be worked around. Hopefully this will be useful to you in those rare circumstances.

Posted in HTML JavaScript

DevMaven Ads on the Web Log

Rick Strahl — Mon, 21 Jul 2008 08:56:13 GMT

If you've been visiting here for a while, you may have noticed that the advertising on this Web log has been cut down quite a bit recently. At the beginning of the month I decided to switch off from the mish mash of advertising that I was running previously, which included Google Adsense, Steve Smith's Lake Quincy Network, James Avery's The Lounge Network network and some of my own ads. Advertising here has brought in a small amount of side income that has roughly covered the hosting of the site and a little bit extra. While it's not been a lot of money it's always been enough to make me teeter on the side of the $ signs to put the ads onto the site, but it required the mish mash to provide even this small stream of revenue . At the same time the amount taken in seemed small in comparison to the amount of content that is actually provided here - it's hard to gauge the worth of ad space of course, but I was actually considering turning off advertising altogether at some point because of the whole disproportion between ad payout and what the Ad services charge advertisers and what gets paid back to publishers (especially Google and Adsense which is an abomination - Google is getting rich of both advertisers and publishers because of it).

So a couple of months ago I started talking with Steve Smith about advertising and some of the pain points for publishers and advertisers alike and started throwing some ideas around about a few different approaches to serving ads. Steve's really the guy with the ideas, but there was a bit of back and forth and I liked what I was hearing. I've been frustrated with the advertising publishing I've been doing for a variety of reasons and was in fact thinking of just dropping the whole thing. However after talking with Steve a bit I decided to see what he'd come up with.

The end result is what now has become DevMavens which is a highly focused and somewhat exclusive advertising arrangement that serves ads to only a few member sites that are part of the DevMavens network and includes only a small number of advertisers at any given month. The concept of this type of specialized network isn't new (in fact, The Lounge used a similar model), but what is different for me at least is that the payback for the publishers is a bit larger than the typical CPM network. For me, the payment arrangements result in a significantly higher payback for running ads and as a bonus it requires only a single, relatively small ad on each page of the Web log.

I hope you'll agree that this single ad format is much less distracting than the 6 or so ads that were running previously on all the pages here, so hopefully this won't be just a boon for me but also for those of you who kindly come to visit this Web log frequently and actually click through into the site either from the RSS feed or from search results. I'm also glad to be working with Steve, who's been great to work with in the past for ad tuning and pinging on advertising issues in general, as well as just being a good developer friend I talk to from time to time about dev issues anyway.

Love Hate Relationship with Ads

Advertising for me is a love/hate issue and it's ironic because I tend to think of advertising as the root of a lot of problems on the Web. So in a way it's a bit hypocritical to whore space on this site to advertising. But yet the lure of some recurring side income is always very enticing. The reality is that a lot of effort has gone into the nearly 1000 posts that have made it into the Web log and there's a certain amount of profit potential there even as the content keeps growing. It seems a waste to throw that away and the income is maybe an added incentive to keep at it, especially on those stretches when writer's block or very busy schedules seem to get in the way.

There's no telling whether the DevMavens campaign will continue to pan out, but for the moment this definitely is a big improvement on all fronts as it simplifies things, makes for a cleaner layout and doesn't hurt the bottom line. Woot.

Posted in ISV Personal

Buying a new Server

Rick Strahl — Sat, 19 Jul 2008 21:07:10 GMT

It's time to retire my existing Web Server which is going on 7 years now. The box that this site is running on currently is an old style 2ghz Pentium 4 box with 1 gig of memory and it's starting to creak at the edges pretty hard with a few off and on failures to power and the system board components (lthe clock seized to work a few weeks ago). As of late the box has been locking up on a few occasions - and in fact just as I started writing this post today it just locked up again. Thankfully the lockups are not hardware fatal and the machine keeps on ticking after being rebooted by the ISP staff, but clearly this box is reaching the end of its hardware life cycle and usefulness.

I've been meaning to upgrade the box for a while, but frankly there's really not been a compelling reason to do so until recently. Even with the fairly large and various amount of stuff running on this server including the WebLog, our message board, a large variety of sample applications, my West Wind Web Store (in various different versions actually <s>) and a bunch of smaller internal applications, it never seizes to amaze me that this underpowered box does as well as it does. The other reason I'd been holding out as long as I had has been waiting for Server 2008. I wanted to wait for the new OS to update to save myself from an update in the future and having more synchronicity between Vista on the desktop and the 2008 server on live site.

Anyway, it's time to get a new box and I'm kind of torn between the choices on what to get. The last box was a home built box that cost me somewhere around $500 to build at the time. It was an emergency replacement box swapped in for a slowly failing server at the time and it just somehow worked out as the permanent replacement. I'd say for the years of services it's done that was a good price to value effort. The old box was basically a desktop box that my ISP at Gorge Net in Hood River has been kind enough to co-locate for me.

The question now is though what to get for a new box. I've been leaning towards just building another box with an Intel Core Quad processor and a gobs of memory, plus some high performance drives for best performance, but things have changed with processor designs significantly over the last few years with chips running super hot. So I'm seriously wondering whether a desktop processor is a good idea for an always-on server environment. Additionally I'm really pressed for time as I have a two week window to get the components, build the box, run a burn in and then move everything from the old server onto the new box while I'm actually in Hood River with physical access to the box. Finally, I'm not all that keen on building my own boxes anymore especially in regards to getting those monster processors installed and properly set up for cooling and optimal tuning. My last home brew installation of an internal office server took me way longer than I care to admit to get the machine into stable operation and while that kind of experimentation was fine for a desktop box I can fuck with anytime, I don't have that privilige with a server at a (somewhat) remote location.

So, I guess I'm asking for a some experienced advice amongst you, my dear readers.

Some of the choices I've been toying with are:

Build my own

If I build my own box the price is probably the lowest and I get exactly what I want, but as I mentioned above I am a little worried about component overheating and life time. Pricing for what I'm looking at looks to be around $600 or so for a Intel Core Quad with 4gig and two SATA drives plus a new box and a beefy power supply. The price is right but I'm not sure if this is still a good idea.

Another option is to buy a bare bones, pre-installed system that has Box and CPU mounted and ready to go. But in briefly looking around I didn't find a lot of choice in this space from most of the component vendors, so this is probably not an option.

Get a Desktop Box from Dell or some other Vendor

Pricing a box that has similar components (minus extra drive and maybe additional memory) from Dell costs roughly the same, but there's less control over the components. It's amazing how cheap boxes have become. Effectively the pricing doesn't seem too much more than home build but I'd probably have to do some component swapping to get the high end drive and memory upgrades still. The advantage for me though is that I don't have to wait for components to show up and build the box and hopefully get a reasonably tuned box that I can just install the OS on and be done with.

Here's with what I came up with at Dell:

Dell Inspiron 530
Intel Core 2 Quad Processor Q6600 (8MB L2 cache,2.4GHz,1066FSB), Genuine Windows Vista® Home Premium Service Pack 1
Unit Price
$728.00

Genuine Windows Vista® Home Premium Service Pack 1 (will be dumped)
Memory
4GB Dual Channel DDR2 SDRAM at 800MHz- 4DIMMs
Keyboard and Mouse Bundles
Dell USB Keyboard and Dell Optical USB Mouse
Monitor
No Monitor
Video Cards
ATI Radeon HD3650 256MB
Hard Drives
500GB Serial ATA Hard Drive (7200RPM) w/DataBurst Cache™
Floppy Drive and Media Reader
3.5in Floppy Drive
Mouse
Mouse included with Keyboard purchase
Network Interface
Integrated 10/100 Ethernet
Optical Drive
16X DVD+/-RW Drive
Sound Cards
Integrated 7.1 Channel Audio
Warranty & Service
1Yr In-Home Service, Parts + Labor, 24x7 Phone Support
Sub total:$728.00

Looking over prices what it would cost me to build a box with similar components it's not going to be any cheaper, even if I end up replacing the drive with something faster later on. <shrug>

The question again is just how much can you trust a desktop box (especially from Dell and Inspiron) to last in a server environment today? I've had good luck with non-server boxes in the past with all of them lasting close to 5 years before they got obsolete.

Get a Server Box from Dell or some other Vendor

While at Dell I also checked out the servers and prices there also seem reasonably decent for a mid range non-rack server. For a quad core 2.5ghz Xeon with a similar configuration (plus 2 drives unfortunately) I'd end up with something like this:

PowerEdge T300
Quad Core Intel® Xeon® X3323, 2.5GHz, 2x3M Cache, 1333MHz FSB, No Operating System
$1,666.00 Save $688 on select PowerEdge™ T300 servers through Dell Small Business.
Memory
4GB DDR2, 667MHz, 2x2GB Dual Ranked DIMMs
Primary Hard Drive
250GB 7.2k RPM Serial ATA 3Gbps 3.5-in Cabled Hard Drive
2nd Hard Drive
250GB 7.2k RPM Serial ATA 3Gbps 3.5-in Cabled Hard Drive
Hard Drive Configuration
Onboard SATA, 1-4 Drives connected to Onboard SATA Controller - No RAID

Floppy Drive
No Floppy Drive
Network Adapter
On-Board Dual Gigabit Network Adapter
CD/DVD Drive
16x DVD-ROM Drive, Internal, SATA
System Documentation
Electronic Documentation and OpenManage CD Kit
Chassis Configuration
Chassis with Cabled Hard Drive and Non-Redundant Power Supply
Hardware Support Services
3Yr Basic Hardware Warranty Repair: 5x10 HW-Only, 5x10 NBD Onsite
Power Cords
Power Cord, NEMA 5-15P to C13, wall plug, 10 feet
TOTAL:$978.00

which seems reasonable for a server. Components as a whole seem a little less powered than the desktop counterparts, but I suspect the Xeon processors are better optimized for server operation and heat dispersion for running in always on scenarios.

Unfortunately in various configurations I haven't been able to get exactly the config I'd like to see so I probably have to call Dell to fine tune a little bit if possible or at least ditch the third drive for a 10k boot drive.

Looking for Feedback

The environment will be almost purely for hosting my own Web applications, mostly ASP.NET applications running SQL Server as a data backend all local in this case plus a few older COM based Web applications. There are obviously more expensive solutions available especially in rack mount form but I'm incined to think that most of the server boxes are just badly overpriced for what performance they provide. Am I totally off my nut on that or does that seem reasonable at all?

I thought I'd take advantage of the vast pool of folks out there and I would love to hear some thoughts on what's worked for you in small shop server installs focused purely on Web Servicing for small to medium level Web load.

West Wind Ajax Toolkit updated

Rick Strahl — Tue, 15 Jul 2008 19:46:32 GMT

I've finally had some time to update the West Wind Ajax Toolkit to version 1.90. A number of these changes I've written about and have updated previously, but this update finalizes a number of these updates into a full release. There are a number of enhancements to the existing functionality as well as a few new helper components that I'm finding very useful these days.

As always you can grab the latest version from:
West Wind Ajax Toolkit page

The toolkit consists of a number of controls to provide JSON callbacks and JSON service, popup hover windows, modal dialogs and a few other Ajax based controls. In addition the Toolkit includes a host of utility classes that provide services to ASP.NET AJAX pages including a generic JSON service, a Json Serializer, a ClientScriptProxy that can automatically route to either ClientScript or the ASP.NET ScriptManager, a ScriptVariables class that lets you embed data into client pages easily for client code access, a ScriptContainer for adding scripts to a page consistently in markup and through code, a script minifier and a JavaScript GZIP compression tool and much more.

Following are a few of the highlights of the release's new and changed components.

Improved JsonSerializer

Thanks to the help from Joe McLain there have been a number of improvements in the serialization code of the parser. It now deals much better with array/list de-serialization which previously was a bit shaky. Arrays/Lists are now supported as root objects or as embedded properties in objects. The latter worked before but there were problems with root arrays. A number of string formatting issues in deserialization are also fixed and the date parsing logic can now deal with ASP.NET AJAX/WCF style JSON dates, as well as the proposed ISO date literal and plain old new Date() syntax. Internally the serializer uses the ASP.NET AJAX date format now, but there's a switch which allows generating the new Date() 'code' syntax instead so you can use the serializer for creating fully runnable JavaScript.

ScriptVariables class

I talked about this class some time ago - it provides the ability to easily embed server variables into client side code by way of a client side object that contains these variables. So you get ServerVars.MyVariable with a server set value applied. Values can be applied literally via Add methods or be applied dynamically which reads values out of any object reference or control property.

Values are properly JSON encoded and can then easily be accessed on the client. The object also supports the ability to read these object values - optionally - back on the server side in a Postback if they are changed on the client. This is a great way to persist values without explicitly having to assign them to hidden variables or a field on the form.

You can create multiple server script variable objects as long as they each output a unique name (with the default being ServerVars) and control builders can also use this tool from within control code without interference with application level code by using a unique name.

Optionally this control can also optionally generate properties for each of the controls on a form and provide non-NamingContainer Ids. So even if txtName is inside of a user control you can access ServerVars.txtNameId to get the control name.

I've found this component to be extremely useful as it provides an easy way to embed:

Variable names that are mangled by ASP.NET naming containers - no more <%= txtName.ClientID %>
either explicitly added or automatically generated through AddClientIds()
Pushing down initially loaded data for JavaScript to consume (including complex types)

I've found this class extremely useful in Ajax applications, especially for pushing down sensible control names and avoiding the <%= ClientID %>mess on the client.

ScriptContainer Class

I've mentioned this class in several posts - it's essentially a script manager that's somewhat similar to the ASP.NET ScriptManager, except it doesn't rely on .NET 3.5 and doesn't output MS Ajax scritps by default. It also provides a bit more control with the ability to determine where scripts are rendered: In the header, after the form tag (standard ASP.NET mode) or inline where the control sits. This setting can be applied either to the control in general or to the individual scripts added, which allows you a little more control over how scripts get loaded.

Scripts can be added either in markup or programmatically and there's only a single instance on a page that's allowed so all scripts can be added to the same manager. This means controls, page code and markup can ensure that scripts only get added once. The syntax uses HTML generic controls using <script> tags so there's Intellisense support for the embedded scripts.

Additionally you can specify whether you want to allow min script to be accessed (ie. .min.js files that are compressed or minimized). If you do and the file exists the control will use the minimized files when running the site in non-debug mode.

JavaScriptMinifier.MinfyDirectory Method

This new method can be used to minify all java script files in a directory or directory hierarchy in batch to create min script files. You specify the path the min extension and whether to recurse into child paths and this method will create the min files automatically checking for changes as needed. This works great in combination with the ScriptContainer class by sticking a call to this static function into Application_Start which will check for script changes on startup of the App.

A few JavaScript Helper classes for Formatting

This update also includes a number of simple helper functions for string, number and date formatting. String gets a basic but highly useful .format() function that uses simple C# string replacement (but without format options). Number gets a .numberFormat() function that does decimal and currency style formatting (c,n,f3,n2) and Date gets formatDate that provides basic formatting using the .NET date format specifiers ( ie. MM dd yyyy, HH mmy). This is nothing new, but it's just so damn useful and necessary that it has to be in the utility library.

Additional changes

There are many more small changes and updates especially in the JavaScript library that fix a number of small issues that have been reported and you can find out what's updated here:

What's new in West Wind Ajax Toolkit 1.90

Interested in Feedback

As always I'm interested in feedback on the components and how you might be using them. There's a lot of functionality in this toolkit, yet I suspect a lot of people are taking components out of it and using individual pieces in their own libraries or applications, which is great.

I'm especially interested though in feedback about the new ScriptContainer and ScriptVariables classes as I think they are great generic tools that could be expanded upon a bit more. Feedback can drive this better so if you have any comments post them here or on the support forum

What's Next?

A couple of things really should happen next. First of all the samples of the toolkit are getting reaaaallly long in the tooth. While they work and get the point across, most look crappy and use some rather lame examples. So the samples will be updated at some point shortly.

For the next major version there will be a complete reworking of the client library to use jQuery. There's a ton of overlap between wwScriptLibrary.js and what jQuery provides and using jQuery to provide the base and core library would reduce the code in wwScriptLibrary by more than half. jQuery doesn't provide all the utility functionality provided in wwScriptLibrary but there's definitely some overlap. I think most of the higher level components - especially the client side control interfaces - can easily be maintained backwards compatible or with only minor changes even given this major of an update. This will be a major change but it's looking good for keeping the interface intact and not breaking old code. Once this is done it'll be much easier to start integrating more jQyery based components in a similar fashion as the wwDatePicker.

Anyway, if you have any thoughts on any of this please leave a note here or on the message board.

Posted in AJAX ASP.NET

Static Singletons for ASP.NET Controls

Rick Strahl — Fri, 11 Jul 2008 07:19:14 GMT

When building generic ASP.NET Server controls that also provide a sort of API service to other custom controls or page level code, it's often necessary to ensure that only a single instance of a control exists, and that only that single instance of this control or component can be accessed in the context of an ASP.NET request. While this is usually easy to accomplish in actual page code (since you can reference the control or component explicitly), if the API is also consumed by other Server Controls it's crucial that it's easy and efficient to find and access that single instance of a control effectively. This isn't a typical scenario, but it's a common pattern for controls that expose API level functionality in addition to the actual control based markup.

This isn't a new concept (Simone had a great post on this some time ago), but I've run into this pattern so many times and have also gotten a number of questions about this that I thought I'd revisit it here since I just went through the excercise again.

For example, a few days ago I talked about a ScriptContainer control that's akin to the ASP.NET ScriptManager control, but with a few additional features. The idea is that there's a single level API that can be used to retrieve an instance to the ScriptContainer, so that code either in CodeBehind or a customer Server Control has access to that instance sitting on a page.

So, in this example I can reference the wwScriptControl on the page with code like this:

wwScriptContainer script = wwScriptContainer.Current;

script.AddScript("~/scripts/wwEditable.js", true);

and always be guaranteed that I get that single instance of the control whether it's already embedded in the page markup or if not it's created on the fly and returned to me. Incidentally the ASP.NET ScriptManager also does something similar with its GetCurrent() method, but it only returns an instance if there's already one loaded - it's your responsibility to create one and add it to the page otherwise. The wwScriptContainer.Current property here instead always returns a control instance including creating one and adding it to the page when none exists yet.

Another example, where this applies is my ClientScriptProxy API, which returns a single instance of the ClientScriptProxy object that references either a ScriptManager if one is on the page, or otherwise talks to the Page.ClientScript object and so provides the same behavior regardless of which API is available. In this case too I need to ensure that only a single instance of this object exists and that I can always retrieve that single instance from anywhere in code. The ClientScript.Current property serves exactly this purpose.

ASP.NET Singletons and HttpContext.Current

This Singleton pattern can be applied to any ASP.NET control (or even component or Page) that in addition to a markup based control interface also exposes a generic API that scoped to the current ASP.NET request/page executing. In ASP.NET request level state is managed through the HttpContext object which is yet another example of a Singleton.

The basic concept of a Singleton is very straight forward. Here's Simone's example which is as concise as it gets:

public class SingletonPerRequest

    public static SingletonPerRequest Current

get

            return (HttpContext.Current.Items["SingletonPerRequest"] ??

                (HttpContext.Current.Items["SingletonPerRequest"] =

                new SingletonPerRequest())) as SingletonPerRequest;

where the SingletonPerRequest() creates whatever object reference you need to create. The key thing is that the property is static and that it returns a value that is stored on the HttpContext.Items collection.

To understand how this works it's important to understand how the HttpContext object relates to the ASP.NET request flow. HttpContext.Current represents the current ASP.NET Request context and this context is available throughout the course of an ASP.NET request starting with the HttpApplication.BeginRequest pipeline event all the way through HttpApplication.EndRequest(). It also includes module and handler execution which is also part of the application pipeline.

ne important aspect of the HttpContext object is that it also contains an Items collection - an in-process statebag that allows you to attach arbitrary state at any point in processing of a request and access it later. Because HttpContext.Current is static and always accessible any state stored in Items is always available (unless explicitly released) until the end of the request. It's an ideal store for request specific information like for example store an instance reference to a control that should only be accessed through a single reference. IOW, a Singleton.

Long story short for my ScriptContainer example, I can use HttpContext.Current.Items["wwScriptContainer"] to save and instance of the script container control and then implement a custom method or property like .Current to retrieve that single instance.

Here's what this code looks like for ScriptContainer:

public ScriptContainer()

    this._Scripts = new List<HtmlGenericControl>();

    this._InternalScripts = new List<ScriptItem>();

    if(HttpContext.Current != null)

        // *** Save a Per Request instance in Context.Items so we can retrieve it

        //    generically from code with wwScriptContainer.Current

        if (HttpContext.Current.Items.Contains("ScriptContainer"))

            throw new InvalidOperationException("Only one wwScriptContainer is allowed per page.");

        HttpContext.Current.Items["ScriptContainer"] = this;

 public override void Dispose()

    if (HttpContext.Current != null)

        HttpContext.Current.Items.Remove("ScriptContainer");

 /// <summary>

 /// Returns a current instance of this control if an instance

 /// is already loaded on the page. Otherwise a new instance is

 /// created, added to the Form and returned.

///

 /// It's important this function is not called too early in the

 /// page cycle - it should not be called before Page.OnInit().

///

 /// This property is the preferred way to get a reference to a

 /// wwScriptContainer control that is either already on a page

 /// or needs to be created. Controls in particular should always

 /// use this property.

 /// </summary>

 public static ScriptContainer Current

get

         // *** We need a context for this to work!

        if (HttpContext.Current == null)

            return null;

        ScriptContainer ctl = null;

        if (HttpContext.Current != null)

            // *** Retrieve the current instance

            ctl = HttpContext.Current.Items["ScriptContainer"] as ScriptContainer;

            if (ctl != null)

                return ctl;

        ctl = new ScriptContainer();

        Page page = HttpContext.Current.Handler as Page;

        if (page == null)

            throw new InvalidOperationException("ScriptContainer.Current only works with Page based handlers.");

        page.Form.Controls.Add(ctl);

        return ctl;

The idea is that during initialization of the control the control/component is immediately pushed into a Context.Items item and saved. This instance becomes that single instance accessed. In fact, the constructor explicitly checks for multiple instances and throws if more than one is instantiated explicitly. This means you couldn't have multiple markup controls on the page or a markup control and manually create an instance.

Once stored the Item stored reference - if one exists - can then be retrieved in the .Current property getter which checks to see if the item exists and returns it.

Typically the .Current getter is also responsible for creating a new instance if one doesn't exist, but how that's accomplished or whether this is supported can vary wildly especially with controls. Here the code creates a generic instance and adds it to the ASP.NET form's Controls collection. Note that from within a static property you won't have access to the Page instance (ie. no this.Page) so you have to access the Page through the HttpContext.Current.Handler and cast that to a Page object.

But again how that works will depend on your specific scenario. The issue is that if you have a control there may be a number of configuration settings that must be set in order to create an instance 'generically'. In the case of the ScriptContainer a generic version is acceptable, but with other controls configuration may be required. You may also need to know whether the control was returned from an existing instance or whether a new instance was created and so you might have an additional property that returns this fact. Or you can return null from .Current and then explicitly let client code create the new instance and configure it.

Typically Singletons have to worry about potential multi-user issues, but in ASP.NET request scenarios using HttpContext.Current this isn't an issue since the instance stored on .Current is visible only to the current request, which is of course running on a single thread. So multi-threading and locking is not something you have to worry about.

This Singleton like approach is a pattern I use a lot for ASP.NET Controls that I create - it's a very useful tool for caching expensive construction and ensuring that you truly are only accessing a single instance of a control or component. But you can also apply this same sort of thing to Page level code or even request level code.

If you want to take a closer look at the ScriptContainer component you can find it as part of the West Wind Ajax Toolkit download.

Posted in ASP.NET CSharp

Inclusion of JavaScript Files

Rick Strahl — Mon, 07 Jul 2008 11:05:17 GMT

I've been thinking a bit about JavaScript inclusion in the last few weeks as I've been working on quite a few different Web projects that use a fair bit of JavaScript functionality. One thing that I'm still trying to feel good about is how JavaScript is included into pages. There are a number of different ways that script embedding can be done especially with ASP.NET and none of them are really perfect.

So what's the Problem?

The issue is plain and simple, how do you deal with JavaScript inclusion into the page given that you have a fair number of JavaScript files that are bound to change frequently and across multiple projects/applications? My assumption here is that I'm using a few libraries and utility classes both public (jQuery and jQuery plug-ins mainly) and some internally developed support libraries. All in all many pages I deal with have typically 4 - 8 related JavaScript resources in AJAX centric applications with about 15-20 JavaScript resources overall involved in a typical project. In addition there are a few ASP.NET custom controls that depend on some of these Ajax libraries and components.

My project load currently runs about 10 concurrent projects both internal and external and all of them are making use of these same script resources. Keeping versions of both my internal JavaScript libraries as well as external libraries in sync and up to date for each of these applications both in development and online gets to be challenging especially if the files are not necessarily delivered as a unified whole (ie. often I pick and choose which plug-ins to use).

So as you can probably see, it's pretty easy to be in 'script file hell' - I find myself using Beyond Compare quite frequently to compare what's changed across different projects and update scripts precariously. I don't think there are easy solutions to this problem other than being very organized and managing versions as anally as possible but doing so can be a real drag on productivity as I move from project to project wondering if I have the correct current version.

There are many different ways that JavaScript resources can be loaded into pages from the basic manually managed header embedding of each script to using full ASP.NET resource management of all script files used. And plenty of other options in between. Try as I might I have not found a solution that really makes me feel all warm and fuzzy, so I'm curious what you are doing and what works best for you.

But let's review some of the approaches that are available to script embedding. For a specific example, let's take the more generic case of the jQuery library. Here are some of the options you have to get jQuery into your page:

Include in a scripts folder and link via script include as jQuery.js
Include in a scripts folder and link via script include as jQuery-1.2.6.js (ie. version specific)
Link to the version specific file at jQuery.com (typically jQuery-1.2.6.js)
Link to the latest version at jQuery.com (ie. jQuery-latest.js)
Link to some other script hosting site (ie. Google's Ajax Lib API) via script loading
Embed scripts into ASP.NET Resources
Use ScriptManager to load scripts either from Folder or Resources
Use a custom script manager

All of these are options but they all have a few shortcomings as well.

Local Script Files

The most common and easiest to understand approach is to simply embed local script links into the page. Add scripts into the header with <script src="scripts/jquery.js"> and off you go. In many situations this approach is perfectly fine, especially if script files are static and don't change frequently.

<head runat="server">

    <title>Configuration Settings</title>

    <link href="Standard.css" rel="stylesheet" type="text/css" />

    <script src="scripts/jquery.js" type="text/javascript"></script>

</head>

The issue with locally stored script files is that they they need to be updated if files changed. In a single application this is not a big issue. But if you're managing a large number of projects, changes to resusable scripts both of your or third party script libraries can easily become a burden and an exercise in version management. It'd be great if source control would solve this problem, but because resources are often mixed and matched storing a fixed set of script files under source control also doesn't really address this scenario either and wouldn't work very well anyway if the project is already under Source Control.

In addition, if you start using script code as part of related ASP.NET controls that might build on top of client script components and that code has some dependencies on specific versions you can run into subtle versioning problems that are difficult to detect and test for. But even for relatively simple things like the static core jQuery library this can get sticky as new versions are frequently distributed.

Versioning JavaScript files in general is a sticky issue. If you have local files, how do you version these JS resource? For example, many jQuery examples are shown using the version specific file like so:

<script src="~/scripts/jquery-1.2.6.js" type="text/javascript"></script>

This addresses versioning alright but then gets tedious when a new version gets released and all pages referencing this version needs to be updated. Again, with a single file this isn't terrible but now think about 10-20 resources used in an application that are all versioned this not really a good option. The other choice is to use a non-versioned file and just update the files - this is easier for updates but in turn can result in subtle feature incompatibilities if newer esions break old builds/dependencies.

I personally lean towards the latter approach of using non-versioned filenames and take my chances hoping that changes are backwards compatible. In my own libraries even a breaking change is easily caught because I know what was changed intimately, but with third party libraries this can be tricky. For example, while using the jQuery.ui beta versions there many subtle breaking changes that were difficult to catch once the code was migrated to the release version because 95% of the code worked great. Testing JavaScript code consistently - especially UI code - is difficult at best and it's easy to have a subtle bug to not show up until the app is in production for a while.

One Library Path for All Scripts

Another option for 'local' script files might be to store all scripts in one place - say off the root of the Web site similar to the way ASP.NET 1.1 used to store resources in a /WebClient folder - and access them through this single script location. This solves the problem of having to copy versioned files around for each application and having a single store to update third party libraries and modify internal libraries. If there's a single store it's also easier to put the files under source control and manage them effectively.

<script src="/scripts/jquery.js" type="text/javascript"></script>

But this approach also has a few problems. First it's not a generic solution because it requires that you use the same convention across applications. Might work fine for your own applications where you set policy, but if you're working to somebody else specs it may not be possible to dump scripts into a specific consistent location.

It also may not necessarily be Ok to update scripts for every application at once, especially if scripts have breaking changes that might not work with older code not adapted to it. If you work with script files that are dependent on one another and these files are updated out of band it's easy to run into version problems. This is always a concern and not having local copies or linking to a single non-versioned script file is prone to potential version issues. Having local files in each app allows isolation from this version issue that can crop up with a single shared library folder. This issue is probably not a major concern

I played around with this approach some time ago, but tossed the idea because of issues

External Hosting

Another centralized approach is to use external hosting for certain script resources. This is more applicable for public librarires like jQuery, Prototype etc. and some high profile plug-ins available for them. External hosting also offloads the bandwidth for downloading scripts from your site to whatever public site hosting the scripts. Additionally, chances are that these script resources may be already cached in user browsers as the public resources are more widely used by users in general browsing which provides additional performance gains.

For example, you can load the latest jQuery version from:

<script src="http://www.jquery.com/src/jquery-latest.js" type="text/javascript"></script>

or a version specific one from the Google jQuery code repository:

<script src="http://jqueryjs.googlecode.com/files/jquery-1.2.6.js" type="text/javascript"></script>

Most other major libraries also provide similar direct links to libraries so that you can offload loading from your site.

Google recently also started hosting various JavaScript libraries with the Google's Ajax Lib API. This API allows you to load script via JavaScript code in the page and allows you to specify specific version numbers as part of the API call. This is a clever way to get a better handle on versioning as you can potentially use single script file to in your app to load various script files with 'factory' function calls that load each library with the appropriate version. FWIW, it doesn't require Google's API to do this; you can take a similar approach by yourself by creating a small loader script that can be updated for each application (see below on how this can be done with jQuery for example).

The disadvantage for external hosting is of course that you are dependent on an external provider to be up and running 100% of the time and to have adequate bandwidth to serve the script files.The provider can decide any time to remove files or APIs so at that point you may end up with bad links in your code. This is where an API - whether your own or Google's can actually buy some advantage because it can be changed in one place.

Another concern is that scripts loaded across sites can also trigger warnings in the browser in some situations like SSL connections (to non SSL script resources) or strict browser requirements for cross domain loading of any files.

Dynamic Loading

As mentioned above you can also load script dynamically from other script code. For example, it might be useful to load one script from another script to provide dependency loading. In jQuery for example you can do:

/// <reference path="jquery.js" />

$.getScript("scripts/basepage.js");

to pull in additional script code.

One potential advantage of this approach is that you can build a simple loading api that turns scripts into resources with maybe some constants that determine which scripts to load and from where, consistently across an application. Rather than linking all scripts in pages you can call a single script file that handles loading all other scripts.

However, when loading script dynamically it's important to be very careful and ensure that the code in the dependency is not accessed before the script has actually loaded. This can have tricky side effects. In one app I was working on just today pages would call into a loaded script function and it would work just fine the first time the page loaded or when a full refresh occurred, but not when the page was just reloaded via click (ie. most resources are already cached). The difference is that the other scripts are fully cached and so load time is significantly faster and the code executes before the second script page loads. In this case IE fails to see the function on page startup (even in $(document).ready() in jQuery) while FireFox, Opera and Safari properly delay the loading code.

Most JavaScript libraries allow working around this via events fired when the script loading completes. In jQuery there's a handler that can be passed as a second parameter that's a handler:

$.getScript("scripts/wwJquery.js",function() {

    showStatus("Ready");

});

which will reliably cause dependent code to run. But it's not always feasible to tie code to a specific library having been loaded. Often you have to wait on multiple libraries. Oddly I've seen a host of problems with this approach both with jQuery, the Google API while script loading from the page's <script> tags seems to work just fine. Detecting script completion across browsers is tricky especially in IE it appears.

I have this approach on my list of things to play around with someday, but given the mixed results I've seen with load order failures I'm incline to pass this option up completely.

ASP.NET Resources

When using ASP.NET it's also possible to rein in JavaScript resources by building them into ASP.NET compiled assemblies as Resources. Using this approach allows the resources to be stored in a single location that is centrally managed. Web Applications can then access these resources by calling Page.ClientScript.RegisterClientScriptInclude(), Page.ClientScript.RegisterClientScriptResource() or the methods of the same name on the ASP.NET ScriptManager control.

When using resources in a separate non-Web project, the project can be added other solutions and so can be shared across multiple projects which can both read the resources and modify any of them and have the changes reflected in any other application that includes the resource (or more often control ) assembly.

I use ASP.NET resources a lot for a variety of purposes from images to scripts to css files and it's a great way to put everything into one place. But resources are not without their problems either. The worst issue by far is that they produce hideously long URLs that are non-transparent in the page and you can't easily tell what each script file points at. They also take up a fair bit of space (a typical WebResource.axd url can be 150 chars long). Additionally the API to actually load these script files is a code only API that needs to be handled in Codebehind of the page with no HTML page markup equivalent.

Resources are a must if you're building controls that have script dependencies in my opinion and that's how I've been using them. I use my own script library that has both client and server components and the server controls need to ensure that scripts are loaded appropriately into the page. Without resources these controls would have to explicitly require the developer to add scripts to the page which would be a bit hokey. So the control internally loads the appropriate resources itself and in the right order and so ensures that the component is self contained.

On the flip side using resources this way can be a problem if you also use the same library for other coding. The smaller problem is that it's very easy to double load resources when you forget that a component loads the resources internally. Further it's possible that the component loads the resources too late or in the wrong order from what the same page code might require if there are dependencies.

In worse cases there may be issues where there are load order problems where the page control order rather than manual ordering end up determining the order in which scripts load. Again, this can become tricky if you have libraries that depend on each other like say a jQuery and a jQuery plug-in, or my personal library that might depend also on jQuery in certain parts.

Resources also don't work well with Intellisense, except when using them with the ScriptManager control (see below). Otherwise the resource URLs aren't transparent so there's no easy way to embed scripts into other JavaScript resources as /// <script reference="" />.

The big problem is that ASP.NET natively doesn't have a native script loading API that works both for markup and code based script injection. Because the ClientScriptManager is a code only component it's very difficult to coordinate script loading both through markup and CodeBehind or component code and it can get very tricky to coordinate script dependencies loaded from resources if those same scripts also need to be loaded for other code.

ASP.NET Script Manager

Ah, but what about the new ScriptManager control that's part of Microsoft ASP.NET AJAX? It addresses a number of the issues that I've mentioned above. Indeed, ScriptManager provides a mirror interface for most of the ClientScript functions so you get the same functionality as the ClientScript for code manipulation and you get the actual control which can be stuck into a page and provide markup based script injection into the page. You can embed both physical url based scripts links as well as resource links so it's possible to consistently embed scripts from both. The control also detects script duplication and only embeds only a single script reference into the page so it's easier for Markup and Code injected scripts to not generate multiple script references. It's possible to add a script like jQuery into the page and ensure that it doesn't get embedded twice for example.

But ScriptManager is also very problematic. First it's a .NET 3.5 component so it's really and add-on and not universally available. There's also no easy way to detect whether ScriptManager is available in a page without using the ScriptManager in the first place (it's possible but it's a royal pain). ScriptManager also requires a control on the page - it's not a standalone API which complicates using it in generic solutions especially since only one ScriptManager is allowed per page. Finally last but not least the control arrogantly throws the Microsoft ASP.NET AJAX ClientLibraries into the page (at least 28k of compressed script for minmal support) with no option to turn that off. If you're not using ASP.NET AJAX like myself the last thing I want is to get a bunch of scripts I'm not using thrown into my page.

Custom Script Manager

My first thought when seeing ScriptManager's issue of AJAX script loading was to subclass the control. It's easy to turn off the AJAX script injection, but unfortunately ScriptManager can't be subclassed in such a way that it still provides Intellisense because apparently Visual Studio's Intellisense for script Intellisense is hard coded to look for ScriptManager's specific properties. Script Intellisense is quite useful so ontop of the other shortcomings of SM I decided to just build my own.

The control I ended up with is similar in concept, but with better focus on externally hosted scripts.

<ww:wwScriptContainer ID="scripts" runat="server" RenderMode="Header">

    <Scripts>

        <Script Src="Scripts/jquery.js"  Resource="jquery"></Script>

        <Script Src="Scripts/ui.core.js"  AllowMinScript="true"></Script>

        <Script Src="Scripts/ui.draggable.js"  ></Script>

        <Script Src="Scripts/wwscriptlibrary.js"  Resource="wwscriptlibrary"></Script>

        <Script Resource="ControlResources.Menu.js" ResourceControl="txtInput" />

    </Scripts>

</ww:wwScriptContainer>

The control can either be embedded into the page or there's a .Current property that can be used from code that either finds an existing instance or creates a new control and adds it to the page dynamically which is useful for controls that want to embed resources. This gives a single API both for markup and code based embedding.

While working on this there were are a few other things that came up as useful: Optional automatic usage of minimized scripts (.min.js) extensions, abillity to embed all scripts into the page header (or inline, or as scripts) rather than adding into the page, the ability to order scripts by inserting at the end or beginning, as well as determining on a per script basis where it renders (Header, Script, Inline or InheritedFromControl) all of which gives some additional control both for markup and code behind. You can also embed resources but use reference a script on disk (for example in a central Web location) in order to still get Intellisense. The latter isn't as nice as ScriptManager's ability to just work off resource Urls, but at least it allows for some Intellisense of resource based scripts.

The format of the control is a bit ugly - I had to use the <scripts> and <script> tags in order to get Intellisense in pages to work because this is the only way I could figure out how to get Intellisense to work. Using custom prefixes (required for new controls) immediately breaks VS JavaScript Intellisense. The result is that I had to use HtmlControls for the script which means there's no Intellisense. Bummer, but the syntax is easy enough to look up.

This is a relatively new control for me and so far I've only used it with one project, but so far this looks promising. But of course this too is a non-standard way of working - it requires using this control instead of script embedding into headers, but at least the syntax of this control is pretty much based on standard Script tags. In fact, for basic scripts the syntax is identical (ie. like the draggable.js) above. If this sounds interesting to you let me know in comments and I can post more info on this control.

But this control is also not a generic solution. It works well for my internal purposes as well as for a few customers I'm working with but it's not totally satisfying either because of the inconsistencies in Visual Studio. And forcing developers to use a custom control is not my idea of a good design either, but for me at least this control addresses a few key scenarios like script compression and programmatic control over scripts and resources.

No Clear Winning Solution

So as you can see I have no clear answers that satisfy even my own requirements entirely. For the most part I'm still embedding scripts straight into the HTML header and hope for the best. The biggest issues I've run into have been conflicts between some of my controls that rely on script resources and scripts loaded through the header with duplicate loads. Most of this is mitigated by my controls which can disable script loading and defer to manually loaded scripts when needed (ie. all script resources are properties and can be loaded either from resources, a url or not all injected by the control). Tracking these things down though can be time consuming. I'm not there yet but I think using hte above control is likely to fix that problem, but for generic controls requiring this control container to be used is probably a hard sell.

Even the wwScriptContainer control doesn't address the versioning and update scenarios although it does help with managing resource and file based script injection both for markup and controls (at least for my own controls). So I'm still searching for sanity and some input on what works for others who are heavily using scripts.

So, dear reader, what are your thoughts on this issue? Are you also fighting with script management hell? Do you use scripts from raw files, or do you use resources? What about for controls that use these scripts? And how do you manage these scripts if they get used across solutions? There are lots of options available but which ones make the most sense to you and why?

I'd love to hear your thoughts.

Posted in HTML JavaScript jQuery

Permissions Denied to get Property location.toString in FireFox 3

Rick Strahl — Wed, 02 Jul 2008 20:31:15 GMT

Since installing FireFox 3, including earlier betas, I've been getting errors that show up on a host of different sites - including on my own. It appears that most errors are related to the advertising that runs here and more specifically Flash ads. While the errors are harmless enough and don't actually cause any noticeable problems on pages or even the Flash ads, they do show as annoying errors in Firebug.

The errors displayed look something like this and they always seem to point at some baffling unrelated JavaScript content in the HTML document:

The above screen shot is from Yahoo's news page to a linked item and is clearly related to Flash components as evidenced by the script filename. What's interesting is that these errors started showing up only with FireFox 3.0. Running IE or FireFox 2.x never ran into these issues, so it appears that this is related to some new security feature in FF3.

The problem is fairly prevalent and it seems that most of it is related to content loaded into separate frames - as many ad services do. Google Adsense seems a frequent problem as well as other services that use Flash or even HTML based content typically loaded into iFrames dynamically.

I've been searching around for some time trying to determine what causes this error and maybe more interestingly what security setting controls this particular error. I hate seeing errors - any errors in Firebug pop up. While there are a number of hits on this particular error none seem to point at a the same situation I'm seeing here namely with Flash components.

[updated - comments where down this morning and a few emailed comments where sent]

As Dave Ward pointed out in a message earlier today while my comments where down, the issue seems to be related to changes in the Flash player and cross domain policy. He sent this link that explains more and indeed adding a crossdomain.xml file solves the issue:

http://willperone.net/Code/as3error.php

Still this is not very satisfying. While that solves the problem for me on my site (in testing only), it doesn't address the errors on other sites that haven't updated their cross-domain files.

Posted in HTML

Customers and POs from Hell

Rick Strahl — Sun, 29 Jun 2008 09:42:58 GMT

I do most of my business with credit cards and while I realize that the CC companies and merchant banks are making a killing off my sales with merchant percentages, the convenience of having credit card processing fully automated to the point that I often have to do absolutely nothing other than review orders is well worth the extra expense.Credit card processing (or PayPal processing for that matter) is convenient for the customer too, but most of all the process can be mostly automated. I run through my online store and a related offline application which is a very slightly modified version of our West Wind West Wind Web Store to do all my order processing. The process is completely automated except for most software updates which require manual validation. I'm using Authorize.NET with a merchant hookup through MerchantPlus and with this setup life is good. The review rate for these transactions for declines or other CC processing issues is under 2%.

I wish it was all that easy

So the vast majority of customers (a little over 95%) use Credit Cards and things are straight forward and easy. There's an occasional W9 form that gets sent but other than that the process is nearly automatic with minimal effort and immediate confirmation for customers without any need for their interaction either.

But the remaining 5% tend to be highly problematic and take more time to process than the entire rest of the bunch combined (and that's including the occasional chargeback research). The remainder tends to be Purchase Orders with each customer requiring their own setup and configuration. Most of the time these customers will throw you a PO that is 5 pages long with Vendor number, department numbers, not one but 3 PO numbers and instructions of what the order has to look like for the privilege of serving them. To top it off a few recent POs had a Politically Correct questionnaire for Equal Opportunity regulations that apply to my business.

Now I may be extremely arrogant in this, but WTF do these people think? I realize some organizations have strict rules and regulations for how order processing needs to proceed and I can relate to that as long as the requested information is reasonable. Obviously some sort of manual filling is in order and that's understandable. There are organizations that have a clean way to provide vendors to submit the necessary information and provide POs that are 1 page or 2 pages with instructions that can be easily followed and completed in a few minutes and without fuss. No problem there.

But it's those 'other' customers (generally they are the mega institutions or government orders) that are painful and require an hour's worth of form filling and additional research just to satisfy their need for information that is ridiculously out of sync with any requirement for the order processing. Companies and Government organizations that try to completely force their order processing on the vendor for some small one off order seems ridiculous. Here's an example: A couple of days I ago I got this PO Order that was literally 10 faxed pages. In addition, this document required a separate W9 form filled out for a purchase of $199. The whole process was to be set up as a vendor. I sent the form back and told them to send back a 'short form' or order online or else forget it. A few emails went back and forth and in the end they did actually order online by credit card - not out of good manners, but because it saved them $15. So let's see here - these guys value $15 more than the forms they sent me to fill out.

Arrogant, yeah I know. I should be so happy to have customers. But seriously I draw the line when I see customers whose bureaucracy has crazily gone out of hand and is going to make me pay for it. If I had filled out that form I would have easily spent an hour looking up all the various references required some of which did not - uhm feel exactly appropriate. Equal Opportunity Rights are OK to a point, but please give me a break on whether this really makes a difference in placing orders with vendors especially when it's a trivial amount of money on a one off order.

Charging Extra

Because there's a lot of extra effort involved with Purchase Orders we charge a $15 surcharge for their processing. The amount doesn't really cover the extra time spent for any but the most simple PO's, but it's meant to discourage use of POs. It used to be that using credit cards caused a surcharge because of the extra fees a vendor pays (which is actually not allowed by CC merchant contracts), but I actually feel that the opposite is true in this day and age: A credit card transaction typically is cheaper if paper work and routing and excessive back and forth chatter can be avoided. The $15 surcharge is an added incentive NOT to use POs.

Some companies get really pissed off at the surcharge to the effect that they simply cross it off the PO and send it back - without note or comment. And so the PO goes back and forth a few times. And more time's a wastin'.

Another vendor (a reseller) recently contacted me and wanted to know where their order confirmation was for a third party customer. I had filled and submitted their Purchase Order request form ( a 'mere' 5 pages) and sent it back. In the next 3 days I heard from 3 different people in the same vendor company, but not one had confirmed my original PO form that I had requested verification for. Nor did they ever reply to any of my requests like who the heck to send the final download links to. In the end I had talked to 5 DIFFERENT people in the company and only heard back from one last manager who finally figured out to cc the others in an email in his department and get their story straight. Apparently all the bureaucracy is confusing even these folks in THEIR OWN office! It took the customer starting to complain loudly (apparently they had paid the vendor before the PO was even approved) to get these folks off their butt and finally resolve the issue. Incredible.

Is it Arrogant?

Stuff like this happens all the time. 90% of effort for 3% of total order volume.

So here's the question of the day: Is it truly arrogant to say "Enough is enough!" and hold the customer to provide a reasonable PO request? Or is the customer always King no matter how screwed up their process is and whether it's a giant waste of time (both theirs and mine)?

Granted my case is special because I'm a one man shop and handle everything myself. A bigger organization can probably manage better because there's a full time person to handle order processing and knows how to deal with all the crazy forms, but regardless it's still a massive waste of time when 3% of customers cause 90% of the order processing work load - it's so rare that it really sticks out when it happens. In the end it depends some on the amount of an order, but on small orders especially, I tend to give customers some grief to keep things simple that a form can be filled out in a timely manner or tell them to - well, "Stick it!"

Got any good PO stories? I know I have a couple of repeat customers who have personally apologized for the PO practices of their company (one in a rather rather humorous way recently that I unfortunately can't print here)...

Posted in ISV Personal