SVNAnt Undocumented Attribute

Just a quick note to mention that while incorporating SvnAnt into my Ant build scripts I needed to find a way to pass the '-force' switch as I would to the command line client for an export operation.

Although the SvnAnt documentation doesn't mention the ability to pass this switch to the <export> nested tag, I noticed the <delete> tag supported a separate force attribute. I tried it out with the <export> tag and it worked a treat.

SVNAnt on Vista Gotcha

I thought I would quickly blog this issue for anyone else struggling to get SvnAnt working on Windows Vista. I have been trying to streamline my deployments using Ant running within Eclipse and as an important part of that task I wanted to integrate my source control. I attempted to use the SvnAnt task to perform operations (such as export, commit, etc) on my Subversion repository.

However I've just spent over an hour trouble-shooting a problem with this task. The cliff notes version of the resolution is this simple realisation:

You can not use the 'command line' (as opposed to JNI) interface on Vista. Read on for the background.

SvnAnt allows you to specify two ways of connecting to SVN. Using the command line interface (effectively executing the command line binary) or using a native library (javahl) through JNI.

My initial approach was to try to use the command line. the subversion binary was already on my path and I knew it worked OK. Although the JNI implementation is reportedly more performant I tried to attack the simplest approach first.

However while experimenting I kept getting the simple error:

Cannot use javahl nor command line svn client


Documentation on the web (provided by my friend and yours, Google) provided me many references to this problem. It seems that with respect to the command line client interface, the PATH environmental variable must include the subversion binary directory. This had me scratching my head, since the subversion binaries were on my path. I began investigating whether the path variable was not available or different, either because I was running Ant via Eclipse run as administrator, or because Eclipse was spawning Ant in its own JRE.

After a lot of investigation, I discovered in my case this was a complete red-herring. On Vista, the subversion executable svn.exe requires an environmental variable SystemDrive that the SvnAnt task purposefully strips as described in this post by John E. Leon Guerrero. So the bottom line is that it is not possible to use the command line interface into Subversion from SvnAnt on Microsoft Vista.

John goes on to describe how to use the DLL distributed with Subclipse for the JNI interface by adding it to the path. This worked immediately for me.

To restate: You must use the JNI/Javahl interface into Subversion if you intend to use SvnAnt on Microsoft Vista.

As a side note, when debugging a possible Ant environment issue, either within Eclipse or from the command line, consider passing the ‘-diagnostics’ argument, which produces a nice output of the environment Ant is running in.

Hope this helps someone!

Using NTLM Authentication with CFHTTP

Anyone who has done a significant amount of work within company intranets in a microsoft network environment will at some point have lamented the lack of the NTLM support in CFHTTP and the administrator scheduled task and system probe functions.

Intranets within microsoft environments have always had a key advantage - that when webservers are set to use integrated security, no user logins are required. Clients using Internet Explorer are automatically authenticated, which is a usability and security benefit of immense value. This is due to NTLM authentication, which automatically secures HTTP requests when webservers or web hosted files are set to use integrated security. This is easily done on IIS and achievable on Apache as well. However the ColdFusion tag CFHTTP - the out of the box HTTP client - does not support NTLM authentication, which means that typically special measures have been required to allow HTTP to be viable communication and information gathering tool for ColdFusion servers in MS environments. This problem affects the HTTP requests sent by native ColdFusion Administrator functions such as Scheduled Tasks and System probes as well.

There are two common approaches to allowing HTTP in NTLM and integrated security environments:

• Use an alternative CFHTTP implementation. For example the CFX_HTTP5 custom tag supports NTLM and provides a couple of extra features as well. It is also possible to roll your own implementation using COM objects or .NET assemblies. Of course solving the CFHTTP issue does not help with CF Administrator Scheduled Tasks or System probes.
• Change the security around specific resources in an adhoc fashion to Basic or another less security setting. With many applications using a 'front-end controller' pattern this can mean creating a proxy page. The disadvantage of this approach the complication to your code base, the overall poorer security outcome and the fact that at times you do not have this level administration access to other internal resources you wish to connect to.
  

While installing Trac the other day (a long an drawn out process I should blog about) I was reminded of another, more elegant solution - Using a dedicated NTLM-aware proxy server. A dedicated proxy server can convert your CFHTTP basic authentication to NTLM and since it is dedicated it can be configured to only accept requests from your ColdFusion server machines. The proxy server required can be lightweight and some circumstances can easily share your ColdFusion server machine.

All ColdFusion HTTP services (CFHTTP, Scheduled Tasks and System Probes) support the definition of proxy server settings, so your end point URLs can be maintained and on the receiving end your can use the automatic authentication to determine with confidence the end user (the CF server) that is accessing the resource.

The specific NTLM-aware proxy server that I experimented with was a Python based server called NTLM Authorization Proxy Server. Other implementation surely exist however, which I'll endeavor to do some more research on and blog about here.

Overall I think the usage of an NTLM proxy service as I describe is a more elegant and consistent approach which minimises the impact of this unfortunate issue on your code base and your approaches to security. Let me know what you think.

Printable Web Pages with CSS

Many blogs and websites I view do not print well directly from the browser. Having printable pages is a good thing© for many reasons that all revolve around making your pages accessible to a wider audience in more situations. Besides, we like the radical notion that a browser's print button might actually be used now and then.

Designing your pages so that they print acceptably direct from the browser is not impossible, but you will find the ease will vary from site to site and the types of data that need to be printed. Flowing, textual data is easily printed; wide tables, inline scroll bars and pre-formatted text are not.

If you have developed your site with semantic mark up there may be an easy solution you have not considered. When importing stylesheets into your pages you have the option of specifying the media (output contexts) the stylesheet should be applied for. If you don't specify this, the browser assumes your stylesheet is valid in all situations, which can lead to undesirable outcomes (that is, completely unreadable printed web pages).

By specifying the media attributes of the stylesheet imports, you can control how the browser attempts to style printed output. Vast improvements in the output quality can often be achieved simply by not providing a stylesheet for print media and letting the browser defaults style your page.

Choose Where your Stylesheets Apply

How does this work? Lets assume you currently import a single stylesheet in your HTML. You might have done so using the following markup:

<link href="screen-style.css" rel="stylesheet" type="text/css">

When a user attempts to print your page directly from the browser, the browser attempts to use your styles in the rendered output. If this stylesheet was designed for online use, this can include CSS rules that are difficult to render in the fixed-width, fixed background colour environment of the printed page. The result can be terrible. A Possible Quick Fix - Disable Stylesheets for Printing

A possible quick and easy improvement is to turn off defined styling - relying on the browser's defaults - for non-screen media. We do this by being more specific in our link tag:

<link href="style.css" rel="stylesheet" type="text/css" media="screen">

For a list of recognised media types, refer to the media types W3C web page.

The media attribute specifies that this stylesheet is only suitable for use on a computer screen, so the stylesheet is ignored when the document is to be printed. Often this is provides a dramatic improvement.

How Does it Look?

For an example of page that uses this technique, open your print preview on this blog page.

UPDATE 30-May-2009: Since this blog is now on Blogger this is no longer true. Blogger needs smarter printing!

TODO: Ask Blogger to improve printing

Your mileage may vary, depending on the quality of the mark up you have used in your page. The order of your HTML markup, its semantic value and your use of CSS for screen layouts will all have a large effect on the readability of your page sans-stylesheet. (This is where you find out why best-practice rocks).

These factors and why impact stylesheet-less printing are described below:

Considered Source Order

Source order - the order in which items appear in your markup - becomes important, because the browser lays elements out in the order they appear in your HTML. Ideally, your markup is already ordered to optimise viewing in mobile devices or text browsers anyway. If it is not, you should consider changing it. CSS layout techniques can achieve a range of effects with any source order, so ordering your markup effectively should not be restrictive. You will want to consider placing elements like sidebars and vertical advertising at the bottom of your document, after the content.

CSS Layouts

If you are still using table based layouts you will find this tip is not very helpful. Without overriding the default styles with a stylesheet, tables used for layout appear as they would had they semantic meaning. CSS Layouts simply disappear on the other hand, generally serialising the page output. In the fixed width setting of the paper page, this is often the best way to prevent content being cut off at the edge of the page.

Semantic Markup

Semantic use of HTML has its advantages, and this is one of them. The default styles applied by browsers are generally highly readable, so if you have used lists, headers, blockquotes and other tags semantically in your document, it will still be readable without the stylesheet rules.

Stylesheets Specifically for Printing

So if option 1 is simply to suppress use of the a stylesheet for printing, the next option is to provide a stylesheet dedicated to printed output only alongside the screen-only sheet.

<link href="screen-style.css" rel="stylesheet" type="text/css" media="screen">
<link href="print-style.css" rel="stylesheet" type="text/css" media="print">

A more practical approach might be to selectively override rules from a master spreadsheet for print situations only. This drastically reduces the amount of duplicate code you need to maintain.

<link href="common.css" rel="stylesheet" type="text/css">
<link href="print.css" rel="stylesheet" type="text/css" media="print">

Many sites already separate layout stylesheets from typography. This can be especially useful to further minimise repetition:

<link href="typography.css" rel="stylesheet" type="text/css" media="screen,print">
<link href="layout.css" rel="stylesheet" type="text/css" media="screen">
<link href="print.css" rel="stylesheet" type="text/css" media="print">

Regardless of the approach, the differences you might want to implement in printed outputs might include:

• Hiding unwanted elements, like sidebars, forms and advertising
• Removing background and foreground images that would not print well
• Ensuring readable fonts with high-contrast font colours and point (pt) specified font sizes
• Removing or resetting fixed widths on elements
• Using advanced (and increasingly supported) CSS rules to insert URLs inline after hyperlinks, or special print-only messages about the context of the printout.

Having a print-only stylesheet is an effective way to retain some custom styles for printing, but this method does increase the amount CSS code that needs to be maintained, so it may not be appropriate for all situations.

Not the Answer for Everything

Some printing requirements will not be helped by these stylesheet methods. When printed outputs must have explicit pagination or wide areas of tabulated data, other approaches (such as providing a PDF) may be more appropriate.

Having said that, this approach to managing your print outputs is relatively easy to understand and can be provided very quickly to every page on a website. Printing web pages directly from the web browser is an easy operation for users of your sites and applications to understand, and generally does not break the flow of their browsing experience. For textual pages such as articles and blog entries, this approach is ideal.

Let the Users Know

If you do go to the effort of ensuring your page can be printed, make sure you let the users know. Years of unsuccessfully printing web documents has permanently dissuaded many users from ever even attempting to print a web page directly.

Letting the users know that the document can be printed directly can be as simple as providing a link which opens the print dialog, such as:

Print this document

I would suggest placing this link at the top and bottom of the page, especially if the page content stretches "below the fold".

In Summary

We can gain a lot of control over how our pages appear when printed directly from the browser, as we have seen. Using semantic, intelligently ordered markup, simply excluding our stylesheet from print operations can produce an effective result in many cases. For more control, a print-only stylesheet can be used. There may still be some pages that are difficult to master the printing of from CSS alone, but most textual content will print with excellent results. Remember to let the users know that they can print your page.

My Article on SitePoint

For anyone interested SitePoint have published an article I wrote titled Creating Scalable Applications with ColdFusion Components.

If you have any feedback or comments, let me know for next time.

Many thanks to Matt and Amy (from Sitepoint and Adobe respectively) who edited my work.

Brush Up on your Web Standards

ColdFusion developers need to know and keep up with Web Standards

For some time I have been thinking about blogging something to this effect.. but I have not had a blog (which is an impediment to this sort of thing).

Recently Richard Davies (which is a brilliant last name) blogged here about his own puzzlement at the lack of web standards talk within the CF community. I agree. The discussions simply do not seem to come up. After looking at some open source CF projects recently I am beginning to believe we should talk more about Web standards and how to used them in building web applications.

Note 30-May-2009: There was originally another page of commentary on this topic but it did not come across in the import process.