Tsvetomir Tsonev's blog

RadScheduler for ASP.NET AJAX - Q3 Beta

Tsvetomir Tsonev — Fri, 17 Oct 2008 01:15:05 GMT

The days are getting longer here, at Telerik Central, as we are working hard to bring you the next top-notch release.

Much attention is directed at RadScheduler and we have some good stuff coming down the pipeline. The beta is due today, so we have decided that it is about time to spill the beans.

Looks count, really. That is why we have decided to add a touch of class to RadScheduler and make it a stylish part of your even more stylish applications.

The changes are more than skin deep. The markup and the CSS were simplified and reduced in size for better performance.

A total of three skins will be available in the beta, namely Default, Hay and Office2007. The rest will be ready to shine in time for the full release.

Currently, grouped views can easily get crammed up. But this is no longer the case, as horizontal scrolling will also make its debut in this release. Just set ColumnWidth to the desired value and RadScheduler will do the rest:

The inline template has received some attention too. It is now rendered on the client in order to reduce the number of requests to the server. It can be resized and its not constrained to the cell that contains it.

The advanced template has also undergone some improvements. The inputs are now validated and the client script has been vastly improved. The refreshed design and the addition of animations add to a better user experience. We also provide VB version of the templates.

Last, but not least, we are very happy to announce that we have adopted jQuery and it is starting to make its way into our products, including RadScheduler. It is such a delight to work with and results in compact and maintainable code. It will also make implementing client-side features much faster. And we have the proof coming...

Regards,

The RadScheduler crew.

Working with RadScheduler recurring appointments on SQL server*

Tsvetomir Tsonev — Mon, 04 Aug 2008 11:24:03 GMT

You might have noticed that RadScheduler uses very cryptic strings to describe repeating appointments. We have decided not to reinvent the wheel and in fact this format is closely based on the iCalendar (RFC2445) standard. Here is an example:

DTSTART:20080218T000000Z
DTEND:20080219T000000Z
RRULE:FREQ=MONTHLY;INTERVAL=12;BYDAY=-2MO;COUNT=3;

This rule says: "The event starts at midnight on 18th of February 2008, lasts one day and repeats each year, for 3 years, on the second to last Monday of February". Now say this three times fast.

As much as standards-based those strings are, they are useless if you want to process your appointments on the database server itself. There are many reasons for you to want to do this. You might want to check for conflicting appointments. Or you might need to prepare some statistics for a report.

From version 2005 and up, SQL Server supports Managed Stored Procedures and User-Defined Functions (UDF). This exciting feature lets you plug in your own managed code into SQL Server and use it inside your queries. This is exactly what we need.

The solution we are presenting comes in the form of a managed UDF. This function uses the same recurrence engine as RadScheduler to do the heavy lifting required to evaluate the rules.

The attached file contains a setup script that enables CLR integration, registers the two assemblies (recurrence engine, UDF) and creates the function itself. Full source code of the UDF is included. Be sure to read the section on CLR integration on MSDN. There are good reasons that it is not enabled by default.

Let's see how all this comes together. A common scenario is to request all appointments in a given time range. Here is how we can do this with our function:

DECLARE @@RangeStart as DATETIME
SET @@RangeStart = CAST('2007-03-31' AS DATETIME)

DECLARE @@RangeEnd as DATETIME
SET @@RangeEnd = CAST('2007-04-05' AS DATETIME)

-- Will list all appointments (recurring or not) in the given range
SELECT      a.ID,
            a.Subject,
            ISNULL(o.StartDate, a.Start) as Start,
            ISNULL(o.EndDate, a.[End]) as [End]
FROM  Appointments a
            OUTER APPLY dbo.ExpandRecurrence(a.RecurrenceRule, @@RangeStart, @@RangeEnd) AS o
WHERE -- Include non-recurring appointments in the range
            (a.RecurrenceRule IS NULL AND a.Start < @@RangeEnd AND a.[End] > @@RangeStart) OR
            -- And recurring appointments in range.
            (a.RecurrenceRule IS NOT NULL AND o.StartDate < @@RangeEnd AND o.EndDate > @@RangeStart)
ORDER BY Start

This yields the following results:

ID	Subject	Start	End
24	Meeting with Alex	2007-03-31 06:00:00	2007-03-31 07:00:00
30	Test Appointment	2007-03-31 07:30:00	2007-03-31 08:30:00
15	Technical meeting	2007-04-02 06:30:00	2007-04-02 07:30:00
15	Technical meeting	2007-04-03 06:30:00	2007-04-03 07:30:00
15	Technical meeting	2007-04-04 06:30:00	2007-04-04 07:30:00

You can see how "Technical meeting" has been expanded into several appointments, according to it's recurrence rule.

Additional resources:

Have fun!

* Applicable to SQL Server 2005 and up

Attached: ExpandRecurrence_UDF.zip

Upcoming features in RadScheduler Q1

Tsvetomir Tsonev — Tue, 18 Mar 2008 10:38:48 GMT

I am very excited to announce that the Q1 release of RadControls "Prometheus" will include major improvements of RadScheduler.

Flexible grouping

You probably are familiar with the "group by resource day view". We referred to it as "Resource View". We now extend this concept further and you will be able to enable resource grouping in every view type - day, week and month. Here is how the week view looks when it is grouped by resource:

In addition, you will be able to specify the grouping direction. The screenshot above demonstrates the default value - horizontal. Here is how RadScheduler looks when using vertical direction:

The new view options require some visual polishing, but we will take care of this in the following weeks.

We are also working on a new view type - a timeline. It will show a time scale on the horizontal axis and the appointments will be optionally grouped by resource.

We plan to extend the grouping further, so stay tuned for more details.

Advanced Form customization

So far we only gave you two choices when it comes to customizing the advanced form. You either had to start from scratch or you had the option to do minor adjustments to the control tree on the fly. These two options cover only the two extremes - minor modifications and total rewrite. We were unable to provide assistance if you wanted to retain most of the functionality, like recurrence editing, and add your own on top of it.

We hope that this will no longer be the case. With the Q1 release we will supply a set of user controls that replicate the functionality of the integrated templates. They are completely self-contained and are logically organized into components. We will help you get started by providing an example and documentation.
The user controls will be included in the upcoming Futures release. It is due next week.

Have fun!

Integrated support for Load-On-Demand from Web Services in RadControls "Prometheus"

Tsvetomir Tsonev — Thu, 31 Jan 2008 00:00:00 GMT

As you may already know, the "Prometheus" counter-parts of RadComboBox, RadTreeView and RadMenu made their official appearance in the Q3 2007 release. The migration to the new code base was an opportunity for us to take a fresh look at the controls and identify the weak spots that needed improvement.

One area that received great attention was the Client-side API. We wanted our customers to be able to create smart and responsive applications and this meant rich client-side functionality. Nothing that can be done on the client should require a trip to the server.

The result is a flexible and powerful API that features:

Ability to add, modify and remove items on the client.�
Persistence of changes done on the client to the server.�
Rich event model.

The new API allowed us to introduce an additional, lightweight load-on-demand mechanism that uses web services to populate the controls. We have tried to achieve maximum flexibility without compromising the ease of use. Let me demonstrate how this is done for RadMenu. The other controls follow the same pattern.

<telerik:RadMenu�� ID="RadMenu1" runat="server">
��<WebServiceSettings Path="ProductCategories.asmx" Method="GetMenuCategories" />
��<Items>
��<telerik:RadMenuItem Text="Products" Value="1" ExpandMode="WebService">
��</telerik:RadMenuItem>
��<telerik:RadMenuItem Text="Purchase" Value="132" ExpandMode="WebService">��
��</telerik:RadMenuItem>
��</Items>��
</telerik:RadMenu>

You only have to configure the path to the web service and specify the method name. Afterwards, the items with ExpandMode="WebService" will be populated through the web service.

The web service has a simple signature. It receives a RadMenuItemData object with basic information about the initiating item and a context dictionary. It has to return an array of RadMenuItemData objects.

[ScriptService]
public class ProductCategories : WebService
{
��[WebMethod]
��public RadMenuItemData[] GetMenuCategories( RadMenuItemData item,
��IDictionary<string, object> context)��
��{��
��DataTable productCategories = GetProductCategories(item.Value);
��List<RadMenuItemData> result = new List<RadMenuItemData>();
��foreach (DataRow row in productCategories.Rows)
��{��
��RadMenuItemData itemData = new RadMenuItemData();��
��itemData.Text = row["Title"].ToString();
��itemData.Value = row["CategoryId"].ToString();��
��
��if (Convert.ToInt32(row["ChildrenCount"]) > 0)
��{
��itemData.ExpandMode = MenuItemExpandMode.WebService;
��}
��result.Add(itemData);
��}
�� return result.ToArray();
��}
}

We are using the item's value to denote the category ID in this example. You can pass arbitrary information to the web service using the context dictionary.

You can see just how easy it is to implement load on demand with the new "Prometheus" controls. And this is just a basic example. You can use the client-side events to further customize the data sent to the web service or to react to communication errors.

The full version of the example is available here.

Team Foundation Server and the missing file sharing (Part 2)

Tsvetomir Tsonev — Fri, 21 Dec 2007 00:00:00 GMT

In part 1 I have outlined the process we have designed to emulate shared files in the TFS. In this post I will explain in detail each step and the tools it requires.

You can download the bits, including complete source code. You can study them or adapt them for your own needs. The usual "no warranties" disclaimer applies.

We have chosen to keep things simple and create a number of tools with well-defined tasks, instead of creating a monolithic solution. We wanted to be able to inspect the intermediate results on each step and to keep the coupling to a minimum.

Finding the shared files

If we are going to do anything about shared files, then we need to know how to find them. A map with their locations would be useful, so we will create one. The first tool should be able to interface with Visual Source Safe, find the shared files and output results in an XML file for further processing. We can name this tool "VSSLinks". Not a very creative name, I admit, but it will have to do.

The implementation is relatively straightforward. We have to walk the desired locations recursively and record the links (shared locations) for each of the files. What we do not need are pinned files (those are shared files frozen at a given revision) and deleted files.

We can also try to determine which is the "original" (or parent) file of each given group of shared files. This information can help us create more consistent branching structure in the TFS repository. For example, if a folder is shared at multiple locations, this information can help us ensure that each location consists only of "children" or "parents", instead of a random mix of both. Unfortunately, the implementation of file sharing in VSS makes this information hard or impossible to get. So it's an educated guess at best.

The tool expects some basic configuration defined in VSSLinks.exe.config file - repository location, credentials, output file and locations file (a simple XML document listing the paths to scan for shared files).

Here is a sample configuration file:

The following locations file specifies that the whole repository should be scanned:

Depending on the repository size, the process can take from minutes to a couple of hours. It is fastest when run locally on the VSS server. When it's done, the output file will look like this:

This map will go a long way, so it pays off to inspect it carefully at this step.

Branching and labeling of the files in the TFS

The cornerstone of our file sharing scheme is a carefully arranged branching structure. In order to create it we need to execute the following steps:

1. Label the parents from the map (created by VSSLinks) with "SHARE".

2. Delete the children (after the migration, they are simply copies).

3. Branch each parent to the locations of its children.

4. Label the children "SHARE-TARGET" to avoid confusion with normal branches.

The tool for this task should use the provided map and prepare a file with commands to be fed to tf.exe (the command-line interface to TFS). This approach leverages the available (and hopefully bug-free) tools and shields us from the complexity of performing these operations through the TFS API. We will call it "AutoBranch". I think I am getting better at naming the tools.

AutoBranch will need some basic data to generate the commands. It includes input and output file, label names, server and project name. We will also prefix our check-in comments with some keyword that will signal our automatic synchronization (explained below) to ignore them. The ignore comment will ensure that if we add shared files after the deployment of the system, they will not be processed by the aforementioned synchronization system.

All the other data we need is in the map file. The tool sorts the links from the map and outputs the different commands in the appropriate order. It groups the operations by type, so the whole process can be completed with only two check-ins, regardless of the number of shared files. Very clean and simple.

The output file contains the generated commands:

At this point we can start the command sequence by executing "tf @AutoBranch.tfc". Note that you have to be running the command from the local folder that the project has been mapped to. Alternatively, you can set UseTemporaryWorkspace to true. In this case, you should run the command from a folder that has not been mapped to a TFS project.

Automatic synchronization

Skipping right to the fun part? I cannot blame you, really. We need some mechanism to inform us that a certain file has changed, so we can keep our shared files in sync. The thing that suits our needs perfectly is TFS notifications. We can easily setup a web service endpoint and subscribe it to check-in event notifications.

We will create an ASP.NET web-site that will host the service endpoint. In the zip file, the tool is called "TFSMergeWS". The web site will also host a bare-bones log viewer, so we can easily track its activity. The application should run in an application pool under an identity that has permissions to check-in into the targeted team projects.

First, we need to subscribe to check-in event notification. We can either use the command-line BisSubscribe utility or the TFS Event Subscription Tool (project's home at CodePlex). Example usage:

BisSubscribe /eventType CheckinEvent /address http://server/path/CheckInEndpoint.asmx /deliveryType Soap /server http://tfsserver:port

So far, so good. Now we have to parse the incoming notifications. I have used the excellent project template from this blog post by Howard van Rooijen to get me started with this task. The template makes easy task of deserializing the XML message into classes.

After the notification is received we have to do some basic filtering. Every check-in that is not part of our project watch list is discarded. So are check-ins prefixed with the keyword "NO-SHARE". The project watch list is located in the Projects.xml file in the App_Data folder. All other settings like the ignore keyword reside in web.config.

The last important piece of information from the check-in notification message is the list of affected files. Once we obtain it, we are ready to do the actual merging. We do it on per-file basis. If the file happens to be a child, we first merge it with its parent and then merge the parent with all its children. In case it's a parent, we skip directly to updating the children.

Simple enough in theory, but the implementation has quite a few obstacles to overcome. For instance, finding the parent of a branched file is not a trivial task.

Here is how the operation log looks like after a shared file has been checked in:

12/03/2007 15:16:52: [123844] Processing checkin for project RadControls by user TELERIK\user1 committed on 12/3/2007 3:16:51 PM.
12/03/2007 15:16:52: [123844] Loaded 10473 files labeled SHARE from the cache.
12/03/2007 15:16:52: [123844] Loaded 24352 files labeled SHARE-TARGET from the cache.
12/03/2007 15:16:52: [123844] Loaded 8284 files labeled PINNED from the cache.
12/03/2007 15:16:52: [123844] Changeset contains 1 file(s).
12/03/2007 15:16:52: [123844] Merging child to trunk:
12/03/2007 15:17:13: [123844] Successfully merged $/Product1/Build/Copyright.txt with $/Common/Copyright.txt. Checking in.
12/03/2007 15:17:14: [123844] Merging trunk to children (3 total):
12/03/2007 15:17:29: [123844] No action needed for $/Product1/Build/Copyright.txt.
12/03/2007 15:17:37: [123844] Successfully merged $/Common/Copyright.txt with $/Product2/Build/Copyright.txt. Checking in.
12/03/2007 15:17:45: [123844] Successfully merged $/Common/Copyright.txt with $/Product3/Build/Copyright.txt. Checking in.
12/03/2007 15:17:45: [123844] ---- Done. ----

We can see how the check-in of $/Product1/Build/Copyright.txt triggered an update to its parent ($/Common/Copyright.txt). Then all of its siblings have been updated with the same changes.

The illusion of free lunch

Most careful readers have probably noticed something by now. The more shares you add to file, the more merge operations it will take to synchronize them. In other words it is an operation with linear complexity and having more shared files will deteriorate the merge time.

Using branches has another drawback. It fails to provide a good abstraction for the purposes of file sharing. The users have to be aware of the synchronization mechanism. They should edit only one file from a shared group at a time in order to avoid synchronization problems. The users should also keep in mind that the synchronization is not instant. In a perfect case they should not have to do any of this.

But given its transitional role, I think that it serves its purpose well. I hope that it will be of use to you too. At least by inspiring you to come up with your own clever automation tools to utilize the features of TFS.

Attachment: TFS_FileSharing.zip

Team Foundation Server and the missing file sharing (Part 1)

Tsvetomir Tsonev — Sun, 04 Nov 2007 19:16:00 GMT

Hello, everyone. First, let me introduce myself - my name is Tsvetomir Tsonev and I work as a developer, here at Telerik. I have spent the last couple of months working on RadScheduler with the great team I am part of.

Another thing that I have been busy with, together with my colleagues, is the migration from Visual Source Safe to Team Foundation Server. I would like to share our experience with you as the process was very challenging in some respects.

Like many Microsoft shops we have been using Visual Source Safe as our primary source control system for a long time. We have long outgrown this solution, but we have delayed the migration to the TFS, as it lacks a killer feature to push the process along. In fact, it misses one particular feature that has wide-spread use in our existing repository, namely file sharing. It is a cheap replacement for proper project structure and for historical reasons our classic RadControls heavily rely on it. For instance, there is shared code between the .NET 1.1 and .NET 2.0 control versions, shared skins and so on.

Microsoft insists that using it is a bad practice and we could not agree more. But a total overhaul is not an option when faced with the migration of quite a huge code repository. To make this practical we needed to find out a way to emulate this missing feature with what is available on the TFS.

After considering all options, we have decided to use a special branching structure as a replacement to file sharing.

The standard migration process makes copies of the shared file to all listed locations. The idea is to pick one of those locations and branch it to the other, replacing the copies. We will also label these branches with marker labels, so we do not confuse them with the regular branches. With this done, all we need to do is to keep the branches synchronized.

The process needs to be automated and require minimum support once the migration is complete. We have divided it in a number of steps and created the necessary tools to get us through them. Let me illustrate it with a diagram.

The most exciting part is the automated synchronization. This is where the TFS begins to shine as its extensibility is unlimited for all practical purposes. The thing that suits our needs perfectly for the occasion is notifications. We can wire our branch synchronization logic to the Check-In event and that is about everything we need.

Stay tuned for Part 2 where I will walk you in detail through the process and the tools we have created for the various tasks.