Windows Live Writer Plugin: Imtech Word Count

December 20th, 2007 by waldek mastykarz

Reading the Windows Live Writer wish list forum I have stumbled upon a request for a Word Count plugin. As the request has been done quite a while ago and there hasn't been any response yet I have decided to make one myself. As the solution wasn't that difficult I was able to stuff making it between work and personal stuff.

WordCountPlugin

The plugin I have made works pretty simple: it grabs the selected text, removes any HTML elements (the string you get in the plugin method, contains the source view of a post content), decodes HTML entities and then makes the count using Regular Expression. It's the first version of the plugin and I might have missed some exceptions as I'm not a professional editor myself. Let me know if you have any suggestions or improvement/extension ideas.

I have already posted the plugin to the Live Gallery. Yet somehow I don't believe it's going to be available there really soon (the Find & Replace plugin still isn't by the way…), so I have put it at our CodePlex site as well.

Windows Live Writer Plugin: Imtech Find & Replace

December 18th, 2007 by waldek mastykarz

I use Windows Live Writer to post on my blog. Sometimes I just miss the Replace functionality which in my opinion is a must-have of each content editor – even the Notepad proves it. If I'm not wrong the Live Writer development team has promised to include the Replace in the next version. As a developer you have two options: waiting or just doing it yourself. I have chosen for the second one….

ReplacePluginDialog

The Find & Replace Plugin I have made support plain search as well as Regular Expressions. Furthermore you can do a replace on the Preview (F11 View) or the Source (SHIFT+F11 View).

You can download the Plugin from our CodePlex site. I have posted it to the Live Writer Plugins gallery as well, but I don't know how long will it take to have it published. In the meanwhile be the first one to have it: Imtech Find & Replace in Windows Live Writer.

ReplacePluginAbout

I have wrapped the Plugin in an MSI installer. Just run the setup and the Plugin with be automatically put in the Plugins directory of Live Writer.

Windows Live Writer Plugin: Convert RGB color to Hex

December 17th, 2007 by waldek mastykarz

Since a while I've been using the Windows Live Writer. Though it's a nice and handy tool that works way better than any web interface, it misses some functionality like pasting the code from Visual Studio, Search and Replace, etc.

Some time ago I have found a nice plugin to paste the Visual Studio keeping the formatting, yet there is one downside to it. This blog doesn't support the colors definition using the rgb syntax, like: style="color: rgb(0,0,255)". Community Server renders the colors properly in it's edit mode (preview mode of Tiny MCE) but the text is all black after publishing. After doing the replace by hand a few time, I have decided to write my own Live Writer Plugin to do it for me.

All I need to do now is to Select All and then click on the plugin to do the job for me. Writing the Live Writer plugins isn't very difficult and you can do it easily within a few minutes. I suppose the mechanism is quite powerful yet the most simple things like replacing can be done by writing a few lines of code.

You can download the plugin from the CodePlex site. I haven't wrapped the plugin in any fancy installer. Simply unzip it and put it in the Plugin folder of the Live Writer and it will automatically appear on your Insert bar.

Using WebClient in SharePoint context

December 17th, 2007 by waldek mastykarz

Recently while working on one of my projects I needed to use the WebClient in order to obtain a rendered version of a Publishing Page using a url. My environment consisted of an Publishing Site using Active Directory authentication and it's extend equivalent using Anonymous Access as well. My goal was to obtain the rendered page before it's published to be able to check the standards compliance of the rendered code.

As I have coded the most basic piece of WebClient usage:

byte[] response;
using (WebClient wc = new WebClient())
{
    wc.UseDefaultCredentials = true;
    response = wc.DownloadData("http://SharePoint/Pages/default.aspx");
}

I have discovered I've received from the response the rendered version of the published version (1.0) instead of the current minor version (1.1). As I've been logged in using valid credentials and I've configured the WebClient instance to use default credentials I couldn't figure out the reason of this behavior.

After a while trying some other approaches out I have noticed I've been using the Site Collection using Anonymous Access. After changing it to the editors Site Collection (the one without AD authentication only) I have finally retrieved the major version of the page. It turned out that whenever possible the WebClient will try to make the request without any authentication. It will use the credentials only if asked by the server – what will never happen by the way if the anonymous access is turned on.

I think it's definitely something you should remember if you work with the WebClient within SharePoint. WebClient is a very useful feature still it might just spare you some precious minutes trying to figure out why it doesn't work as you would expect it to.

W3C Validator for SharePoint 2007

December 15th, 2007 by waldek mastykarz

SharePoint 2007 is a very extensible development platform. Thanks to its flexibility the developers keep coming with new features which extend the user experience. One of the areas where the things are still missing is the Web Content Management: accessibility in particular leaves plenty of challenges to be tackled and features to be added by the accessibility enthusiasts and developers. One of these is the W3C Validator for SharePoint 2007.

As I've mentioned some time ago we are busy here at Imtech ICT Business Solutions designing, developing and testing our own accessibility toolkit for SharePoint 2007. As the whole solution works perfectly I have started looking for some other ideas on how to extend it and enrich the editors' experience. One of the ideas I've got was incorporating the W3C Validator support into SharePoint 2007.

First of all the requirements. As it's supposed to be editors' tool it needs to reside on the Publishing Console. It's supposed to validate the page: preferably before it's published so an editor can correct his mistakes if any found. Then the report: embedded into SharePoint 2007 or just a redirect? As embedding might enhance the total experience it would require you to provide new versions of the SOAP response parser (as the response you get from the W3C Validator is in the SOAP 1.2 format). Because most of the people dealing with accessibility and standards compliancy are familiar with the generated output that's the approach I have chosen.

As our toolkit targets the Dutch standards you might be asking why we haven't chosen for that one. Well, the Dutch Quickscan supports URL's only. And because one of the requests was validating the page before actually publishing it it's a no go unfortunately.

Completing the first step was quite straight forward: simply edit the CustomQuickAccess.xml file. The provisioning of such an alteration is slightly more challenging as the XML file is being provisioned by one of the Publishing Features and you are not allowed to replace during the provisioning a file provisioned by another Feature. And still, even if it was allowed, it wouldn't definitely be the best practice as the file can already contain other buttons. Replacing the file would remove them from the Publishing Console. Luckily I have done this before and could reuse a method I wrote which is comparable to the WebConfigModification method but then allowing me to edit any XML file.

W3CValidatePageButton

The validation process turned out to be the most challenging of the whole solution. Looking back at the requirements you will notice that I mentioned validating the page before actually publishing it. Posting the complete page which can contain the Site Actions menu, the Publishing Console and more of the inaccessible items which are required for the proper working of the editors area is unfortunately a no go. Taking this into consideration leaves you with two possibilities.

First of all I've been thinking on iterating through the collection of fields available within the Content Type of the requested Publishing Page. Obtaining the values and making a new HTML page of them would be an option. The biggest downside of this approach is that you skip the rendering part of the value: remember once stored value can be displayed in many ways within a Page Layout using various Web Controls and Web Parts. Querying for a value is unfortunately not enough as it passes that stage of rendering and doesn't check whether a control alters the value making it inaccessible/incompliant. So then I came up with another approach.

If you take a look at the client-side DOM accessible by JavaScript you can see that you are able to obtain an element iterating through the DOM nodes or using for example the element's ID. Using this approach would allow you to query the page as it is (including the SharePoint menus and toolbars) and then simply pick the content within the given element and send it to the W3C Validator. That led me to a new requirement: be able to set the ID of the content wrapper. We are definitely going to reuse this feature in other projects and because we work with different designers we need to have the possibility to configure this property.
Realizing this task was not really difficult using the Ted Pattison's best practices for developing application pages. As this feature would eventually make part of our compliancy toolkit I have decided to extend the configuration page we already have.

CompliancyToolkitConfiguration

Then again, validation itself using server side DOM. Using the resources available within the .NET framework you are left with the MSHTML assembly if you want to use some DOM features in your .NET code. It does work, but you need to fix its interpretation of your document as it alters it stripping for example quotes from some attributes. Another challenging part is getting the instance of an HTMLDocument. In a Windows Application you would use an instance of the WebBrowser to do this, but does it remain the only way even if you have nothing to do with System.Windows.Forms and all you want is a plain instance of HTMLDocument? Luckily it isn't. But let me leave you something to research.

Anyway, with the content of the rendered page accessed using server-side DOM, it was the time to send it to the W3C Validator to get the results.

Instead of choosing for the immediate redirect to the W3C Validator I have put another application page between: just to have a status view and to be able to catch any exceptions or errors the validator could have encounter while obtaining the requested Publishing Page and parsing its content.

W3CValidatorValidating

The whole concept works pretty good. The user is being redirected to the W3C Validator and can precisely see what the reasons of the problems are if any found. In our case: 100% valid thanks to Imtech SharePoint Compliancy Toolkit.

W3CValidatorCompleted

Incorporating the W3C Validator for SharePoint 2007 in SharePoint self we hope to enhance the editors' experience and make the editing of compliant content easier by allowing them to validate the content they have entered way earlier in the editing process. I hope that I have given you a little idea on how the SharePoint 2007 environment can be extended to make it more user-friendly.

The W3C Validator for SharePoint 2007 is a part of the Imtech SharePoint Compliancy Toolkit. The other ideas I have mentioned? Well, these will follow pretty soon.

Extending the SharePoint:FieldValue WebControl

December 9th, 2007 by waldek mastykarz

How many times did you try to incorporate some extra rules or formatting into Page Layouts? Formatting a date is just one of the many examples solving which can cause you spent many hours trying to using the out-of-the-box available controls. The SharePoint:FieldValue is probably the most commonly used control, especially in Page Layouts where you don't want to use the Edit-in-place experience. Yet this control doesn't have any customization or formatting possibilities. That's why some time ago me and my colleagues at Imtech ICT Business Solutions have thought about creating our version of this control with some more formatting properties. As soon as we have created it, we have started benefiting from it: because we had the code of it, extending it with extra functionality is just a piece of cake. Anyway, let me introduce you the Imtech:PageProperty control.

I would like to guide you through a process of creating a simple yet powerful custom WebControl. At the end of this post you should be able to use the example we will build here and extend it with new functionality to make it fit to your needs.

I assume you know the basics of working with WebControls within SharePoint 2007. Furthermore I assume already have a project, which builds into an assembly. I also assume that it's content is available within SharePoint. If you are a beginner in SharePoint and have questions about these steps, please react in the comment so others will be able to learn from it too.

We start by creating a new public class deriving from the System.Web.UI.WebControls.WebControl class to provide the basic functionality of a WebControl:

using System;
using System.Collections.Generic;
using System.Text;
using System.Web.UI.WebControls;
using System.Web.UI;

namespace WebControls
{
    [ToolboxData("<{0}:PageProperty runat="server" />")]
    public class PageProperty : WebControl
    {
    }
}

Then you need to define the attributes to use within the control. If you look at the SharePoint:FieldValue control, you see you can pass the name of the field of which the value you want to display. This guarantees the flexibility and reusability of the control. Let us do the same:

private string _Property;

[Bindable(true), DefaultValue(""), Localizable(false)]
public string Property
{
    get { return _Property; }
    set { _Property = value; }
}

Because we have called our control PageProperty I have chosen for the name Property instead of FieldName, but you are free to choose the one which suits you most.

Let's test the control now. At this stage the control should be able to display the value of the Field passed through the Property attribute. To display this value we need to override the Render method of the control. Another option would be overriding the RenderContents method but it would cause your control to render a span or any other element around the contents which isn't desired in WCM scenario's when you deal with predefined layouts.

protected override void Render(HtmlTextWriter writer)
{
    try
    {
        writer.Write(           SPContext.Current.Item[Property].ToString()        );
    }
    catch { }
}

Let's move on with adding the formatting logic. In our control we have decided to split this routine in two pieces: defining the type of the value and passing the desired date format. Without the first part you might end up trying to format a text string as a date. Let us define the two properties we require. Second of all choosing for this approach will allow you to use various formatting routines for various data types.

public enum PropertyType
{
    String,
    Number,
    Date
}

private PropertyType _Type;
[Bindable(true), DefaultValue(""), Localizable(false)]
public PropertyType Type
{
    get { return _Type; }
    set { _Type = value; }
}

private string _Format;

[Bindable(true), DefaultValue(""), Localizable(false)]
public string Format
{
    get { return _Format; }
    set { _Format = value; }
}

I have chosen for an enumeration to pass the data type to ensure the input within this attribute more easily. Using a string would work as well. Still it's not a best practice typing the possible values over and over again.

As we have the required attributes we can move on to actually implementing the formatting routine. We will do it by extending the Render method we have defined at the beginning.

try
{
    string fieldValue =        SPContext.Current.Item[_Property].ToString();

    switch (_Type)
    {
        case PropertyType.Date:
            fieldValue =               DateTime.Parse(fieldValue).ToString(Format);
            break;
    }

    writer.Write(fieldValue);
}
catch { }

The switch block contains only one case at this moment. You could easily extend it though for example with extra logic for formatting numbers.

The control is ready. You can use it within your Page Layouts as follow:

<Imtech:PageProperty Property="Modified"Format="d MMMM" Type="Date" runat="server"/>

The last piece is to register your newly created control within all Page Layouts or simply once in web.config – approach I prefer.

The PageProperty WebControl allows you to replace the SharePoint:FieldValue control. Extending it with new features will allow you to box the functionality and avoid unnecessary complicated constructions in your Page Layouts or queries. The downside is you need to be a developer to do this and you must be allowed to deploy custom code on the web server.

So, How many HTML elements can YOU name in 5 minutes?

December 8th, 2007 by waldek mastykarz

79HtmlElementsIn5Minutes

79 is my score, what's yours? Though it's not really a job interview exam, it's nice to refresh the knowledge once in a while. There are more than 79 elements in HTML 4, so it seems like I need to grab my HTML 4 book again…

Imtech Test Content Generator v1.3.0.0 (free SharePoint 2007 tool)

December 7th, 2007 by waldek mastykarz

Testing the editors area in SharePoint 2007 isn't really convenient. Image you would like to check whether the overview Web Part you have made really shows 100 items per page. Copying the items in the Explorer View might be a solution, still it's that handy when it comes to testing various Content Types and Page Layouts. Another scenario you might want to test is scheduling: does my page become available at the given timestamp? Yes, you can test this using the SharePoint 2007 interface, but still I think it can be done much easier.

ImtechTestContentGenerator_1300_001

When it comes to testing custom Web Parts, overviews and the rest of the editing features within SharePoint 2007 I have developed Imtech Test Content Generator v1.3.0.0: a tool which helps me creating a given number of pages. As parameters I can set the desired Page Layout and content within the page. One click on a button, a cup of coffee and a couple hundred of items are there for me: Checked In, Published or even Approved if I want to.

ImtechTestContentGenerator_1300_002

Imtech Test Content Generator v1.3.0.0 is free and you can use it without any restrictions.

Download Imtech Test Content Generator v1.3.0.0 from our CodePlex site.

Webrichtlijnen (WCAG 1.0 Priority 2+) Accessibility in SharePoint 2007

December 1st, 2007 by waldek mastykarz

Last Thursday I gave a presentation about accessibility in SharePoint 2007: the existing challenges and my approach to it. I have been invited by the Dutch Information Worker User Group to share my experience with other Dutch developers. Standing on the other side on such an event was my first time. I have to admit I did find it quite exciting and didn't really know what to expect of it – being a developer it's not really your daily job to speak for a group of over 40 people. For those of you who didn't have the chance to attend my presentation let me give you a brief overview of the contents.

Developing SharePoint 2007 solutions is quite different as soon as you take accessibility into consideration – especially if it's as highly leveled as the guidelines in the Netherlands. It's very important that you understand the way the whole platform works before you begin designing and developing an accessible solution. SharePoint 2007 and ASP.NET 2.0 both don't support it out of the box. It is possible though but quite challenging. Understanding the plumbing of both platforms will make your life way easier.

Choosing for an accessible Internet facing site built upon SharePoint 2007 has major impact on the design and development phases. You have to start with designing an accessible User Interface which will eventually make big part of the delivered User Experience. Then the difficult part comes: translating the drawings and sketches into HTML, CSS and JavaScript. At this stage you will be creating the solid baseline for the whole solution. Failing at delivering of accessible translation would make achieving the desired accessibility level impossible.

Another big challenge is the design and development of the required functionality such as custom controls and web parts. As a developer you have the full control of the generated output. On one hand you need to incorporate the pieces of the User Interface translation into the controls – as the code has been delivered at this stage it's not really difficult to do. Controlling the rendered output of the control is a way bigger challenge. You need to watch out that your control won't render a span around a div etc. In other words: as a developer you have to fully understand the accessibility standards – not only the Dutch Webrichtlijnen but WCAG 1.0 as well. Furthermore it's really helpful if you have at least a bit of experience with working with CSS. As I've mentioned: Development will never be the same…

Developing an accessible SharePoint 2007 solution is worth all the effort. You can achieve about 50% of the weight loss on each response and that's only the beginning. Other very important benefits are the interoperability of the data and improved querying by search spiders.

Accessibility in SharePoint 2007 is challenging. The worst part is: there aren't any solutions that will guide you during the development process. At this point of time you will have to do it on your own. Lately release of AKS 1.0 doesn't change anything. The delivered 12.1 version of the BlueBand master and the CSS files can give you a vague impression of an accessible site but you will still need to begin from scratch if your customer will ask for an accessible Internet facing site.

The good news is: it is doable. Last Thursday I have finished the beta 2 version of my own toolkit supporting accessibility in SharePoint 2007. While it helps a lot not only as it comes to accessibility but improves performance as well, it's still not the total solution you might've expected. Using an accessible UI translation and taking accessibility into consideration while developing custom controls will let you achieve the very nice score of 118 (125 is the maximal score on the Webrichtlijnen check). What about the remaining 7 points? That's why I needed the toolkit. As you get errors on the output rendered by the SharePoint 2007 rendering engine you don't have much choice than overriding it or cleaning it up.

At the end of the next week the first Webrichtlijnen accessible website we have created here at Imtech ICT Business Solutions will come on-line. Together with the site I will try to post a 'How we did it?' article about the process we went through and the challenges we have faced.

If you are interested in accessibility of SharePoint 2007 based solutions you can download the my DIWUG presentation. It's partly in English and partly in Dutch. Let me know if the mix makes is impossible to follow: I will translate the sheets into English.

First 100% Webrichtlijnen (WCAG 1.0 Priority 2+) compliant SharePoint site – almost there

November 29th, 2007 by waldek mastykarz

As I have recently mentioned, here at Imtech ICT Business Solutions we are busy with first 100% Webrichtlijnen compliant Internet facing web site based on SharePoint 2007. Earlier this week we have finished the development en begun testing the solution. Yes, we have discovered a few undocumented features which we have immediately resolved. Anyway testing for compliancy with the Dutch government's guidelines was a serious part of this project and it was my job to achieve this goal.

As I have mentioned earlier I have developed a toolkit which helps gaining enough control over the generated page output just to make it compliant and yet still working. Furthermore I have taken a look at the response of each request and decided to clean this one as well. As a result I have taken the response size from 788kB down to 303kB! That's more than 50% per request on the home page only!

During the development we did have to consider the compliancy. For a moment it looked like we would be getting problems with custom controls' events linked through in-line JavaScript. Using our client side script library we have succeeded to preserve the same link using unobtrusive JavaScript though.

The last one were the Web Parts. I have to admit: I have hoped AKS would help me on this one. A bunch of good guys working on a serious compliancy solution for SharePoint and they have admitted there would come over 20 Control Adapters shipped with AKS. When I got the AKS release in my hands and installed it, I really got disappointed: yes there are 25 Control Adapters inside AKS and nope: not even one for the Web Part Zone! Because the Render method of the SharePoint's Web Part Zone is obfuscated there is no way to have a look at the way Microsoft deals with the rendering. I hoped HiSoftware would have access to that part of SharePoint and would do some good job on it. Unfortunately not, not even a trace of it. As giving up on the compliancy challenge wasn't really an option for me, I have decided to give it a try myself and deal with it myself. The outcome? I will present it tonight @ DIWUG. And for those of you who are not going to attend this session: keep watching this blog.