August 2009 - Posts
Every now and then, when I prepare my self to a lecture, or when I need to create a demo, I need to produce some “content” on my MOSS site.
Since it is quite a tedious task to produce 10-15 pages, I wrote a small code snippet that will do this task for me.
The basics – creating pages with code
Here is the basic C# code:
- using (SPSite site = new SPSite("http://joeysh-srv-pt:100"))
- {
- using (SPWeb web = site.OpenWeb())
- {
- //Get the publishing site, and publishing web
- PublishingWeb pubWeb = PublishingWeb.GetPublishingWeb(web);
-
- //Get the content type for the page
- SPContentTypeId ctID = new SPContentTypeId("0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900B1281BE7EC1A304F977F3595ED435565");
-
- //Now let's get the page layout for that content type
- //Note: assuming only one page layout for that CT
- PageLayout layout = pubWeb.GetAvailablePageLayouts(ctID)[0];
-
- //Create the page
- //Note: assuming page doesn't exist yet
- PublishingPage newPage = pubWeb.GetPublishingPages().Add("newly_created_page.aspx", layout);
-
- //Add the title and description. Those are special fields which doesn't exists in the SPListItem for that page.
- newPage.Title = "Page created with code";
- newPage.Description = "This page was created solely with code";
-
- //Now set some fields' values
- newPage.ListItem["DetailedDescription"] = "This is a very good product description";
- newPage.ListItem["Price"] = "50.99";
- newPage.ListItem["IsOnSale"] = "Yes";
-
- //Update the item, check-in and publish
- newPage.ListItem.Update();
- newPage.ListItem.File.CheckIn("Created automatically");
- newPage.ListItem.File.Publish("Created automatically");
- }
- \
I think the code is really straight forward. After getting an instance of the desired site collection, I’m getting a publishing web object (line 6). This is done to get access to some of the publishing method, which the basic SPWeb doesn’t expose.
In line 20 – 31, I’m filling in some content in the page’s fields. Note that the “title” and “description” fields are getting different attention. The reason for that, is the they both comes from the base object, and not from the content type’s list item.
The last important part is to update the list item, and check in the new file. The update part is simple – a page is a list item, and hence it needs to be updated, just like any other list item.
The check-in and the publish, is unique to pages, and the reason for that is versioning. Unlike regular list items, pages can save versioning information, therefore you should check them out for editing and check them back in when you done. When you create a new page, it is automatically checked out on you.
I would suggest you leave the remark there, and/or add something more descriptive, just so you can recognize you pages later.
Creating multiply pages with code
This is actually a very small extension to the code above.
All I add is a function that will fetch some content from an Excel file, or XML or any other source, it might even be just another list inside your SharePoint. The point is that those data sources, are easier to edit and you can easily just drop as many rows as you like.
So, my code differs very little, first, I get a list of items from my data source:
- //Get some data from any data source
- //'SingleRow' is some data structure. It can be anything:
- //XML, DataRow, any class or object, etc.
- List<SingleRow> pagesToCreate = GetPagesContentFromSource();
-
And then I rap the page-creation-code in a loop, so it looks like that:
- //Now loop the data source, and create a page for each item
- foreach (SingleRow currentRow in pagesToCreate)
- {
- //Create the page
- //Note: assuming page doesn't exist yet
- //The page name is creates using the data source's title
- PublishingPage newPage = pubWeb.GetPublishingPages().Add(currentRow.Title + ".aspx", layout);
-
- //Add the title and description. Those are special fields which doesn't exists in the SPListItem for that page.
- newPage.Title = currentRow.Title;
- newPage.Description = currentRow.Description;
-
- //Now set some fields' values
- newPage.ListItem["DetailedDescription"] = currentRow.DetailedDescription;
- newPage.ListItem["Price"] = currentRow.Price;
- newPage.ListItem["IsOnSale"] = currentRow.IsOnSale;
-
- //Update the item, check-in and publish
- newPage.ListItem.Update();
- newPage.ListItem.File.CheckIn("Created automatically, page title: " + currentRow.Title);
- newPage.ListItem.File.Publish("Created automatically, page title: " + currentRow.Title);
- \
Note that I’m only wrapping the lines that do the actual creation. I don’t want to create instances of sites on each iteration, of course. Furthermore, since I’m creating pages of the same type, the Content Type and the Layout doesn’t change as well.
You can, of course, make the code even more sophisticate, and choose different pages’ layouts and different content types.
Last week, Matrix launched its own blogs’ site – blogiX.
I have a new blog there, about SharePoint, content management and so on.
The blog is in Hebrew, and I will post there some translated posts from this blog, and some originals.
New blog’s address: http://portals.blogix.co.il
Enjoy reading.
This post was suppose to be part of the Validating WCAG 2.0 post. But due to the length of the combined post, I decided to split them.
SortSite by Electrum is a complete testing tool for web sites. It isn’t free, but it isn’t very expansive either - the standard version cost 149$ (complete price list).
It stands alone, and doesn’t require Internet access (there’re couple of information frames that pools data from the web site, besides those, everything will work).
The application checks many things:
- Accessibility
- Browser Compatibility
- Broken Links and Errors
- Web Standards
- Search Optimization (Pro edition only)
- Legal Compliance (Pro edition only)
- User Experience (Pro edition only)
The interface is very simple, and it looks just like a browser. Just type in the address of the page you wish to check, and hit the “Check” button.
Each page in the application includes clear explanations of how to achieve the basic functionality of that page.
As an example, here is the “Rule Settings” page (click to enlarge):
Configuration
In the “Choose Rules” dialog, you can select which rules and guidelines to check:
The accessibility section offers checks for WCAG 1, WCAG 2, and Section 508. You can select which level you wish to support, and check to that level.
You can assemble a list of check you wish to run and export it. Later on, you can import it back to run that set of tests again. This can be very useful, if you want different set of checks for different development phases. The import/export is done using the links on the bottom of the dialog.
Check results
The result page will show you a summary of all the checks conducted on the page.
Drilling down to the accessibility report, will show the accessibility check report.
On the top of the page there’s an accessibility status summary table, showing you how the site stands on each level and version checked.
Each error, offers a link to the guideline it self, from the WCAG guidelines pages. Clicking the link will open the page inside the application, which makes it easy to quickly check the description of that error.
Clicking the errors on the left, will show you the pages on which the error was found.
Each page has a separate report; clicking the link, will navigate to the single page’s report, showing the error it self, the line number on which the error exists, piece of the HTML code, and a fix suggestion.
Summary
Over all this is a very good tool for checking many aspects of your web site.
Although it isn’t free, I think it worth its price. You can use it for 30 days, using the trial version, before you decide.
But if you need to check many sites, conducting the same tests over and over, I think it will defiantly save you some time.
Earlier this week, I’ve published my post about Fujitsu Accessibility assistance. One of the problems with this tool is that it still checks only for WCAG 1.0.
In fact, most of the tools out there, are still aimed at WCAG 1.0.
Following the post, I was asked for a tool that will validate WCAG 2.0. Since I actually need it my self, I didn’t need much more to get on the search.
ATRC Web Accessibility Checker
The “ATRC Web Accessibility Checker” is an online validating tool from the “Adaptive Technology Resource Centre”.
It is completely free, but since it works only on-line, you should have Internet access. You can, as a workaround, save your rendered file to a static HTML file, and upload that file.
The interface is very simple:
Just type in the URL for the site you wish to check, select the options you want, and hit “Check It”.
After a while (it will take quite a few seconds) you will have a tabbed report on the bottom of that page, which looks like that:
Each error, is marked with the line number in the checked HTML. Note that if you are checking an Asp.Net page, the line number wouldn’t be same as your mark-up, but as your rendered HTML result.
The “Repair” section of each error, offers a method to repair that error.
Clicking the error’s title link, will open a popup window with a detailed explanation of the guide line and repair method.
If you need an offline tool, read about SortSite - web site testing tool
When you develop an accessible site, you would probably incorporate the accessibility test into your QA phase. This is a standard practice, and it is a good practice.
However, you might want to test your code yourself, while still in development. This is a good practice too. If you’re running unit tests on you C# code, why wouldn’t you do something similar for your HTML code?
If you are developing within Visual Studio, the IDE highlights some elements, and offer some tests for accessibility.
But if you don’t use Visual Studio (developing Java maybe?), you need some external tool.
There are many tools that can do automatic checks on your web page. Most of them aren’t for free, or if they are free, they are on-line (which might be a problem, if you are on a secured network).
I was working with a development project, and I need some tools, so they can check for accessibility themselves, before my final test.
After not much of searching, I found out the Fujitsu Accessibility Assistance toolset.
There are 3 tools on that set:
Web Accessibility Inspector ColorSelector ColorDoctor I’m going to focus only on the first and last, as ColorSelector is merely a color-picker and not really an accessibility tool per se.
Both tools are completely stand alone, and they don’t need no Internet access. Both are built with Java, and you will have to download Java runtime to get it to work.
Web Accessibility Inspector
This tool will perform an automated check for WCAG 1.0 (no WCAG 2.0 support yet). The interface is very simple as you can see below:
You can select to check a folder (where you HTML or ASPX files are located), including sub-folders, with the option to drill one layer, two layers or all layers. You can check the level of compliance you wish to check, or to customize the check list, to check only specific guide lines.
A word of caution: do not hit the “version…” button. Due to some bug, it hangs the application (at least it did on my machine).
If you hit the “Setup the environment…” button, you’ll get the following screen:
Here you can setup the browser to use for the check and when watching the result file, setup proxy (if you’re checking your site on-line), and so on.
One of the coolest thing in my opinion, is that the result are being presented as an HTML page, which you can save, print, or send by mail. I’m using it to produce a check list of errors to my team.
The result file shows a summary table, with internal links, to the problem found.

As you can see, the tool checks not only the main file, but also the supporting files (i.e. CSS files, and JaveScript).
Just below that table, you can get a quick view of how many errors you need to fix, to meet each compliance level.

Each error found, is being described in details, including the line number, the compliance level for which this guideline belongs, and a link to the guideline itself on the WCAG web page.
Color Doctor
Now this tool, is a simulation tool, design to show you how your site will be seen in the eyes of a person, having types of color blindness deficiency.
As with the first tool, the interface is very simple:
Just type in the URL to your page (it can be local) and hit the “Go” button. Choose the type of deficiency you wish to check for, and hit the “Convert image”.
Note that only the left pane is scrollable. If you scrolled the left pane, you will have to click the “Convert image” once more. Marking the “Real-time conversion” will scroll and convert the right pane, while you’re scrolling the left pane. Note that the conversion process is heavy, and the scrolling wouldn’t be smooth.
You can use this tool to check images you’re about to use on your site. Just replace the URL with the full path to the image file (i.e. “C:\someFolder\somefile.jpg”) and everything else is just the same.