Blog

Parallel execution of multiple results in Caliburn Micro

Fri, 08 Mar 2013 14:23:22 GMT

by Petr Hošek

While working with Caliburn Micro, we have came up with the need for parallel execution of multiple results. This is especially useful for concurrent load of data from multiple sources (e.g. filter content).

The framework itself contains only support for sequential execution represented by the SequentialResult class. Therefore, to add support for parallel execution, we have decided to implement our own ParallelResult class in the similar fashion.

First of all, we had to implement the IResult interface:

public class ParallelResult : IResult
{
    private readonly IEnumerator results;

    public ParallelResult(IEnumerable children)
    {
        this.results = children.GetEnumerator();
    }

    public ParallelResult(params IResult[] children)
        : this(children as IEnumerable)
    {
    }

    public event EventHandler Completed;

    public void Execute(ActionExecutionContext context)
    {
        throw new NotImplementedException();
    }

    private void OnComplete(Exception error, bool wasCancelled)
    {
        var handler = Completed;
        if (handler != null)
        {
            handler(this, new ResultCompletionEventArgs { Error = error, WasCancelled = wasCancelled });
        }
    }
}

Both constructors resembles the existing SequentialResult class. Now, we need to implement the logic of this class. Our goal is to run all tasks in parallel and notify observers when all tasks have finished. To do that, we have decided to use Reactive Extensions for .NET (Rx), library for composing asynchronous and event-based programs using observable collections.

The implementation looks as follows:

public void Execute(ActionExecutionContext context)
{
    IoC.BuildUp(this);
    var observables = Observable.Merge(Scheduler.ThreadPool, ChildObservables(context).ToArray());
    observables.Subscribe(_ => { }, ex => OnComplete(ex, true), () => OnComplete(null, false));
}

private IEnumerable<IObservable> ChildObservables(ActionExecutionContext context)
{
    while (results.MoveNext())
    {
        IResult child = results.Current;
        yield return Observable.Create(subscribe =>
        {
            IoC.BuildUp(child);
            child.Completed += (sender, args) =>
            {
                if (args.Error != null || args.WasCancelled)
                {
                    subscribe.OnError(args.Error);
                }
                subscribe.OnCompleted();
            };
            child.Execute(context);
            return () => { };
        });
    }
}

Using the ChildObservables(ActionExecutionContext) method, we convert each task (represented by IResult interface) to instance of observable collection. Then, in the Execute(ActionExecuteContext) method, we merge all observable collections and subscribe to resulting obserable collection in order to be notified of its status.

When all tasks finish, OnComplete(Exception, bool) method is called. This method notifies all the clients subscribed to Completed event. This allows instances of ParallelResult class to be composed in the same way as instances of SequentialResult class.

Coproject - a RIA Caliburn.Micro demo, part 2

Tue, 04 Sep 2012 11:09:21 GMT

by Augustin Šulc

In this part, we will create a domain model and a RIA service so that the client application will be able to access data in Coproject database.

For those of you, who would like to see the code running but don't have time to write it, check Coproject codeplex site.

1. Create domain model

In Coproject.Web, create a new folder called Models.

Add a new Entity Data Model called CoprojectModel to it.

In Entity Data Model Wizard, choose Generate from database. Choose the proper database connection (probably Database.mdf) and let VS to Save entity connection settings in Web.Config as CoprojectEntities. Finally set the last wizard step as follows:

Click Finish and wait for the model being created. Then rebuild the solution. Now, the server is able to access database.

2. Create RIA service

Create a folder called Services and add new Domain Service Class called CoprojectService to it.

Then, set the wizard as follows:

Two new files should be added to Services:

The first file contains the RIA service itself. You can see functions like GetToDoItems, InsertToDoItem, etc. Their purpose should be clear.

Set metadata

The other file called CoprojectService.metadata.cs contains several classes like:

internal sealed class ToDoListMetadata
{
	// Metadata classes are not meant to be instantiated.
	private ToDoListMetadata()
	{
	}

	public DateTime CreatedDate { get; set; }
	public string Description { get; set; }
	public string Name { get; set; }
	public Nullable<int> ProjectID { get; set; }
	public EntityCollection<ToDoItem> ToDoItems { get; set; }
	public int ToDoListID { get; set; }
	public Nullable<DateTime> UpdatedDate { get; set; }
}

These are metadata that describe what entities should be transferred to the client, what links are between them, how to localize labels for these properties or how to validate them. Take this as a configuration file for the RIA service. These settings, although written on server, are transferred by RIA Services to the client application and available there too. Now, we have to add some more metadata.

Add attribute [Key] to properties ToDoItemMetadata.ToDoItemID, and ToDoListMetadata.ToDoListID and UserMetadata.UserID. This will instruct RIA Services that these properties are primary keys for these classes. This is essential for updating data and handling links between entities.

Next, update other properties of ToDoItemMetadata to look like:

[Include]
[Association("FK_ToDoItems_ToDoLists", "ToDoListID", "ToDoListID", IsForeignKey = true)]
public ToDoList ToDoList;

[Include]
[Association("FK_ToDoItems_Users", "UserID", "UserID", IsForeignKey = true)]
public User User;

This will make RIA services to link proper entites into the respective references. The same has to be done for ToDoListMetadata:

[Include]
[Association("FK_ToDoItems_ToDoLists", "ToDoListID", "ToDoListID")]
public EntityCollection<ToDoItem> ToDoItems;

Build the solution to make sure that there are no errors. Now, the server side is ready to serve data for client.

Fast switching between ViewModels in Caliburn.Micro

Tue, 27 Mar 2012 13:40:54 GMT

We use Caliburn.Micro on several of our projects and we are quite satisfied with it. The framework is pretty much based on what is described in Coproject series.
As one of our applications grew, we realised that changing between screens takes longer and longer time (blocking whole UI thread). The more screens had been opened the longer it took. Having profiled the application, I found out that the delay is caused by calling MeasureOverride of DataGrid and its columns. Since changing the ActiveItem property of a Conductor causes ContentControl bound to it completely change its content (to render view of the new active ViewModel), I understand it might take some time. But as all views are cached in memory, why it takes so much time?

You can see demo here.

I have asked several questions (StackOverflow, C.M forum, Silverlight forum). Found no solution but at least a hint that the problem is in adding the view to visual tree.

My idea was to create a custom ContentControl that would cache all views so that it can quickly switch between them. After few minutes, I came up with this:

public class ContentHost : ContentControl
{
	private Grid _contentGrid;
	private UIElement _currentView;

	public ContentHost()
	{
		_contentGrid = new Grid();
		this.Content = _contentGrid;
	}

	public object CurrentItem
	{
		get { return (object)GetValue(CurrentItemProperty); }
		set { SetValue(CurrentItemProperty, value); }
	}

	public static readonly DependencyProperty CurrentItemProperty =
		DependencyProperty.Register("CurrentItem", typeof(object), typeof(ContentHost),
		new PropertyMetadata(null, (s, e) => ((ContentHost)s).OnCurrentItemChanged()));

	private void OnCurrentItemChanged()
	{
		var newView = EnsureItem(CurrentItem);
		SendToBack(_currentView);
		_currentView = newView;
	}

	private UIElement EnsureItem(object source)
	{
		if (source == null)
		{
			return null;
		}

		var view = GetView(source);

		if (!_contentGrid.Children.Contains(view))
		{
			SubscribeDeactivation(source);
			_contentGrid.Children.Add(view);
		}

		BringToFront(view);
		return view;
	}

	// logic from Caliburn.Micro
	private UIElement GetView(object viewModel)
	{
		var context = View.GetContext(this);
		var view = ViewLocator.LocateForModel(viewModel, this, context);

		ViewModelBinder.Bind(viewModel, view, context);
		return view;
	}

	private void SubscribeDeactivation(object source)
	{
		var sourceScreen = source as IScreen;
		if (sourceScreen != null)
		{
			sourceScreen.Deactivated += SourceScreen_Deactivated;
		}
	}

	private void SourceScreen_Deactivated(object sender, DeactivationEventArgs e)
	{
		if (e.WasClosed)
		{
			var sourceScreen = sender as IScreen;
			sourceScreen.Deactivated -= SourceScreen_Deactivated;

			var view = GetView(sourceScreen);
			_contentGrid.Children.Remove(view);
		}
	}

	private void BringToFront(UIElement control)
	{
		control.Visibility = System.Windows.Visibility.Visible;
	}

	private void SendToBack(UIElement control)
	{
		if (control != null)
		{
			control.Visibility = System.Windows.Visibility.Collapsed;
		}
	}
}

If you now compare performance of ContentControl with ContentHost, you will see that it works.

I still don’t know why more DataGrids causes other DataGrids to render slower.

What do you think?

Source code.

Coproject - a RIA Caliburn.Micro demo, part 11

Mon, 13 Feb 2012 18:30:12 GMT

by Augustin Šulc

In this part, we will synchronize list after saving data and add some icons. You may continue on your work from older parts, or download updated code from Coproject site.

Event aggregator

Usually, if you want a component of your application to notify other components about an event that occurred, you use standard .NET events. The problem with events is that you always need to access the publisher of an event from the subscriber. What’s more, you also need to unsubscribe from the event. That might be tricky in a complicated application or when the same type of event may come from more sources (for example if you would implement user events logging via events and logger subscribed to these events).

Here comes (again) Caliburn.Micro and its implementation of Event Aggregator. Consider EventAggregator as a component that you subscribe to all kinds of events or that you use to publish an event.

In Coproject, we will use EventAggregator to notify ToDoItemsViewModel that ToDoItem has been changed and thus it should reload data.

First of all, we must create an object that will represent the event. In Coproject client project, create new folder Events and put a new class called ToDoItemUpdatedEvent into it:

public class ToDoItemUpdatedEvent
{
	public int ToDoItemID { get; set; }
	public ToDoItemUpdatedEvent(int toDoItemID)
	{
		ToDoItemID = toDoItemID;
	}
}

Open ToDoItemViewModel and let MEF import an EventAggregator instance:

[Import]
public IEventAggregator EventAggregator { get; set; }

Then update Save as follows:

public IEnumerable<IResult> Save()
{
	(Item as IEditableObject).EndEdit();
	IsReadOnly = true;
	#region Fix DataForm bug
	IsReadOnly = false; IsReadOnly = true;
	#endregion

	yield return new SaveDataResult(_context);

	EventAggregator.Publish(new ToDoItemUpdatedEvent(Item.ToDoItemID));
}

So, after (remember coroutines and yield return) a ToDoItem is saved, we publish event notifying about it. We do not care who subscribes to this event, this is not our business here.

Now, let’s write the other end – an event subscriber. Open ToDoListsViewModel and edit the constructor:

[ImportingConstructor]
public ToDoListsViewModel(IEventAggregator eventAggregator)
{
	DisplayName = "To Do";
	Description = "To-do lists";

	eventAggregator.Subscribe(this);
}

Now, event aggregator will know that it should notify ToDoListsViewModel about events. But what events? It depends on what IHandle<T> interfaces the subscriber implements. Let the view model implement IHandle<ToDoItemUpdatedEvent> and add this implementation:

public void Handle(ToDoItemUpdatedEvent message)
{
	LoadData().ToSequential().Execute(null);
}

Remember that LoadData returns iEnumerable<IResult> so we have to enumerate it to ‘run’ it. Therefore, we wrap it into a SequentialResult and then execute this single result.

The only problem is that LoadData requires a parameter – filter. And this value is unknown to the handler. Fortunately, we can change the source Filter textbox binding from function parameter to property. Add this property to ToDoListsViewMode:

public string Filter { get; set; }

And the remove parameter ‘filter’ from LoadData (take the filter value from Filter).

Build the application – it should run as before, but after saving of a ToDoItem, the list should refresh automatically.

Icons

Let’s give Coproject a little more style – change text buttons to icon buttons.

Open the zip file attached to this post and extract the five images to Assets/Icons. These icons are from Axialis.

Then, open ToDoListsView and edit the LoadData button:

<Button x:Name="LoadData" Grid.Column="1" ToolTipService.ToolTip="Search">
	<Button.Content>
		<Image Source="/Coproject;component/Assets/Icons/Search.png" Height="20" />
	</Button.Content>
</Button>

Well, this works nicely but let’s make it a little more shorter since we will probably use these image buttons quite frequently in our application. To do this, we will create a custom control called ImageButton. Create a new folder Controls and add this control to it:

public class ImageButton : Button
{
	public string ImageName
	{
		get { return (string)GetValue(ImageNameProperty); }
		set { SetValue(ImageNameProperty, value); }
	}

	public static readonly DependencyProperty ImageNameProperty =
		DependencyProperty.Register("ImageName", typeof(string), typeof(ImageButton), new PropertyMetadata(OnImageNamePropertyChanged));

	public static void OnImageNamePropertyChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
	{
		ImageButton button = d as ImageButton;
		string newValue = e.NewValue as string;

		if (newValue.IsNullOrWhiteSpace())
		{
			button.Content = null;
			return;
		}

		newValue = "/Coproject;component/Assets/Icons/{0}.png".FormatWith(newValue);
		ImageSource image = new BitmapImage(new Uri(newValue, UriKind.Relative));
		button.Content = new Image { Source = image };
	}
}

As you can see, we inherited original Button and added a property to it. The reason that ImageName is implemented as a dependency property is to enable it for binding, styling, etc. When the property is changed a new Image is inserted to the button. It would be great to add this image into ContentTemplate by style and just bind its Source property to ImageName, but since in template binding, you cannot use any converters, we would have to set ImageName in the raw form (/Coproject;component/Assets/Icons/Search.png) and that is not what we want. So that is why I’ve chosen this way. Now open Assets/Cosmopolitan/Custom.xaml and add this namespace to it:

xmlns:local="clr-namespace:Coproject.Controls"

And then add this to the end of the file, just above </ResourceDictionary>:

<Style TargetType="local:ImageButton" BasedOn="{StaticResource DefaultButtonStyle}">
	<Setter Property="Height" Value="32" />
</Style>

We are done – get back to ToDoListsView, register namespace for ImageButton as in Custom.xaml and update LoadData button:

<local:ImageButton x:Name="LoadData" Grid.Column="1" ImageName="Search" ToolTipService.ToolTip="Search" />

Update buttons in Toolbar view in the same manner:

<local:ImageButton x:Name="Edit" ImageName="Pen" ToolTipService.ToolTip="Edit" Margin="0,0,5,0" />
<local:ImageButton x:Name="Cancel" ImageName="Undo" ToolTipService.ToolTip="Cancel" Margin="0,0,5,0" />
<local:ImageButton x:Name="Save" ImageName="Save" ToolTipService.ToolTip="Save" Margin="0,0,5,0" />
<local:ImageButton x:Name="TryClose" ImageName="Close" ToolTipService.ToolTip="Close" />

That is all. I hope you like the new look!

Icons.zip

Coproject - a RIA Caliburn.Micro demo, part 10.5

Fri, 10 Feb 2012 21:30:37 GMT

by Augustin Šulc

If you watched CPU usage after implementing BusyIndicator, you might notice major increase in CPU usage on To do module after the list is loaded for the first time.

High CPU usage with BusyIndicator and ProgressBar

It is a common issue with BusyIndicator: Silverlight forum, Silverlight toolkit issue, Appsolo blog but the solution is not obvious or easy to find. So I’ve spent some time and figured out that the excessive CPU usage is caused by ProgressBar that is present in BusyIndicator. After googling for a while, I ran into this forum but that was all about it. Fortunately, recently I saw Silveright TV episode 57. I strongly recommend to watch the video.

Now, let's apply the new knowledge on Coproject. Edit App.xaml.cs

private void Application_Startup(object sender, StartupEventArgs e)
{
	Application.Current.Host.Settings.EnableRedrawRegions = true;
}

Run the application and reload the list (be careful if you have epilepsy!). As you can see, we have a problem.

Now, let's do what was suggested in the video. So, edit ShellView to begin as follows:

<Grid x:Name="LayoutRoot">
	<Border Style="{StaticResource ContentBorderStyle}">
		<ContentControl Style="{StaticResource LogoIcon}"/>
	</Border>
	<Border Style="{StaticResource LeftBorderStyle}"/>

	<TextBlock Text="Coproject" Style="{StaticResource ApplicationTitleStyle}" />
	...

And then just update LeftBorderStyle in Custom.xaml:

<Style x:Key="LeftBorderStyle" BasedOn="{StaticResource LinksBorderStyle}" TargetType="Border">
	<Setter Property="Margin" Value="10,135,25,0"/>
</Style>

Run the application again and you should see we're fine now.

Coproject - a RIA Caliburn.Micro demo, part 14

Thu, 07 Jul 2011 10:57:26 GMT

by Augustin Šulc

In the last part, we created LazyScreen class so that we can load our view models into memory only when they are requested and not right after the application start. In this part, I want to create LazyConductor – a conductor that will support closing of child LazyScreens and then opening new ones instead of removing them from its Items collection.

Please note that this is just a simple demo of an idea I had about lazy screens/conductors and using it in production might need additional code. But if you use it, please let me know (I plan to use it on a real project too, so this post might be updated later according to my experience).

LazyConductor

In the Framework folder, create a new file called LazyConductorWithCollectionOneActive.cs and put the following into it:

public partial class LazyConductor<TScreen, TMetadata>
{
	public partial class Collection
	{
		public class OneActive : Conductor<LazyScreen<TScreen, TMetadata>>.Collection.OneActive
		{
		}
	}
}

From now, every time I refer to LazyConductor, I mean the OneActive class.

Since the difference between the original conductor and our lazy conductor is in the way they close their children, we will override functions dealing with closing/deactivating stuff. When a child is closed, the original conductor removes it from its children collection. Lazy conductor should only call Reset() on the child and activate another one.

Add overriden DeactivateItem function:

public override void DeactivateItem(LazyScreen<TScreen, TMetadata> item, bool close)
{
	if (item == null)
	{
		return;
	}

	if (close)
	{
		CloseStrategy.Execute(new[] { item }, (canClose, closable) =>
			{
				if (canClose)
				{
					CloseItemCore(item);
				}
			});
	}
	else
	{
		ScreenExtensions.TryDeactivate(item, false);
	}
}

If you compare it to Caliburn.Micro source code, you will notice that there is no change. The reason for that is that we just need to alter CloseItemCore function and since it is private, there is no other way.

private void CloseItemCore(LazyScreen<TScreen, TMetadata> item)
{
	if (item.Equals(ActiveItem))
	{
		var next = DetermineNextItemToActivate(item);
		ChangeActiveItem(next, true);
	}
	else
	{
		ScreenExtensions.TryDeactivate(item, true);
	}

	item.Reset();
}

The last line is why we did that – original conductor said ‘Items.Remove(item)’. To make the solution build again, we must add one more function:

protected LazyScreen<TScreen, TMetadata> DetermineNextItemToActivate(
	LazyScreen<TScreen, TMetadata> currentItem)
{
	var next = Items.FirstOrDefault(x => x != currentItem && x.IsScreenCreated);
	return next;
}

Finally add these functions:

public override void CanClose(Action<bool> callback)
{
	var openedItems = Items.Where(x => x.IsScreenCreated);
	CloseStrategy.Execute(openedItems, (canClose, closable) =>
		{
			closable.Apply(CloseItemCore);
			callback(canClose);
		});
}

protected override LazyScreen<TScreen, TMetadata> EnsureItem(LazyScreen<TScreen, TMetadata> newItem)
{
	var node = newItem as IChild;
	if (node != null && node.Parent != this)
	{
		node.Parent = this;
	}

	return newItem;
}

The first line of CanClose is quite important here – we want to check only already opened children.

ShellViewModel

To use our new lazy conductor, update definition of ShellViewModel as follows:

public class ShellViewModel : LazyConductor<IModule, IModuleMetadata>.Collection.OneActive, IShell

Finally, I want to add the possibility to close opened modules. Add this to ShellViewModel:

public bool CanCloseActiveItem
{
	get
	{
		return ActiveItem != null;
	}
}

public void CloseActiveItem()
{
	DeactivateItem(ActiveItem, true);
}

To get the guard property updated, put this code into the class constructor:

this.PropertyChanged += (s, e) =>
	{
		if (e.PropertyName == "ActiveItem")
		{
			NotifyOfPropertyChange(() => CanCloseActiveItem);

		}
	};

ShellView

The last thing to do is to add a close button to ShellView. Open ShellView, add this definition into its beginning:

xmlns:local="clr-namespace:Coproject.Controls"

and put this control to the end of the LayoutRoot grid:

<local:ImageButton x:Name="CloseActiveItem" ImageName="Close" ToolTipService.ToolTip="Close current module"
					Margin="20" HorizontalAlignment="Right" VerticalAlignment="Top" />

And we are done! Open To Do module, edit an item and then try to close the whole module – you will see a warning that you have unsaved changes in the module.

Coproject - a RIA Caliburn.Micro demo, part 13

Thu, 07 Jul 2011 09:44:49 GMT

by Augustin Šulc

By now, you are probably using Caliburn.Micro for your applications and hopefully Coproject helped you to learn it. But if you are creating large business applications as we do, you have probably realized that you need to tweak and extend C.M a little bit. That’s why I would like to continue on this Coproject series while focusing on these advanced features.

As you probably know, ordinary ViewModels hierarchy and thus whole application structure is loaded on the application startup. This is OK for small applications but with larger ones, there might be a memory issue having all ViewModels initialized and not being able to close them. In this part, I would like to describe and test an idea about having LazyScreens.

Lazy screen

The core idea is to have LazyScreen – a sort of a wrapper around ordinary Screens that can be seen in application menu but will load the inner screen only after requested. Possibility to close the inner screen would be also useful to free some memory. Yes, you can close ordinary screens too but then, they are removed from their parent screen (and therefore from its menu), which is not what we want here. If these LazyScreens work, they will be used for main application parts – modules, module navigation screens, etc.

ModuleMetadata

So, let’s open the Coproject source code and see what can we do. First of all, since we want our modules (Home, Messages, To Do , Milestones) be lazy loaded only when requested, their titles cannot be set in their code (DisplayName property) but must be set in metadata. So, open IModuleMetadata and add Title property:

(btw: do you know that you can hit CTRL+, to quickly navigate to any class in the solution? You can even use only capital letters, so write IMM to look for IModuleMetadata).

public interface IModuleMetadata
{
	int Order { get; }
	string Title { get; }
}

Next, update ExportModuleAttribute so that it implements the updated interface:

[MetadataAttribute]
[AttributeUsage(AttributeTargets.Class, AllowMultiple = false, Inherited = false)]
public class ExportModuleAttribute : ExportAttribute, IModuleMetadata
{
	public int Order { get; private set; }
	public string Title { get; private set; }

	public ExportModuleAttribute(int order, string title)
		: base(typeof(IModule))
	{
		Order = order;
		Title = title;
	}
}

Finally, update all module definitions so that the new attribute constructor is used (Home module example follows):

[ExportModule(10, "Home")]
public class HomeViewModel : Screen, IModule

The solution should now build again.

LazyScreen

Having metadata prepared we have to implement the LazyScreen class. Put it into the Framework folder and make its signature as follows:

public class LazyScreen<TScreen, TMetadata> : Screen

In order to have LazyScreen create a new instance of the inner ViewModel (Screen) when requested, we will use MEF class named ExportFactory. This works just as its name suggests – it gives you an export when you request one. What’s more, it provides metadata without creating a new export. So, let’s add a constructor to the class.

private ExportFactory<TScreen, TMetadata> _factory;

public LazyScreen(ExportFactory<TScreen, TMetadata> factory)
{
	_factory = factory;
}

Next, add the most important functionality:

private TScreen _screen;
private ExportLifetimeContext<TScreen> _export;
private object _lock = new object();

public TMetadata Metadata
{
	get
	{
		return _factory.Metadata;
	}
}

public bool IsScreenCreated
{
	get
	{
		return _export != null;
	}
}

public TScreen Screen
{
	get
	{
		lock (_lock)
		{
			if (!IsScreenCreated)
			{
				_export = _factory.CreateExport();
				_screen = _export.Value;
			}
			return _screen;
		}
	}
}

public void Reset()
{
	if (!IsScreenCreated)
	{
		return;
	}

	lock (_lock)
	{
		_export.Dispose();
		_export = null;
		_screen = default(TScreen);
	}
	NotifyOfPropertyChange(() => IsScreenCreated);
	NotifyOfPropertyChange(() => Screen);
}

Now, let’s check, whether this might work. To use this new class, we must update our Shell. First, open ShellViewModel and update it like this:

[Export(typeof(IShell))]
public class ShellViewModel : Conductor<LazyScreen<IModule, IModuleMetadata>>.Collection.OneActive, IShell
{
	[ImportingConstructor]
	public ShellViewModel([ImportMany]IEnumerable<ExportFactory<IModule, IModuleMetadata>> moduleHandles)
	{
		var modules = from h in moduleHandles orderby h.Metadata.Order 
						select new LazyScreen<IModule, IModuleMetadata>(h);
		Items.AddRange(modules);
	}
}

You should notice that we only updated constructor parameter type (from Lazy to ExportFactory), added new LazyScreens from these exports into Items property, and updated base class generic parameter accordingly.

Finally, we must update ShellView too:

Change binding of the TextBlock in the Items ListBox from DisplayName to Metadata.Title
Change name of ActiveItem_Description to ActiveItem_Screen_Description
Change name of ActiveItem to ActiveItem_Screen

Meaning of these changes should be obvious – since there is another layer between shell and modules (our new lazy screen), we must point the controls to the inner view models.

If you now run the application, it should work just as it did before all these changes. Ok, I know that this does not seem like a great achievement :-) but take it as a proof that the original idea might work.

Simplify generics

There is one line in the code I really don’t like – the repeating of generic parameters in ‘select new LazyScreen…’ in ShellViewModel constructor. We could make a use of generic functions to get rid of it. Add the following class into LazyScreen.cs:

public static class LazyScreen
{
	public static LazyScreen<TScreen, TMetadata> Create<TScreen, TMetadata>(
		ExportFactory<TScreen, TMetadata> factory)
	{
		return new LazyScreen<TScreen, TMetadata>(factory);
	}
}

We can update the ShellViewModel constructor:

var modules = from h in moduleHandles orderby h.Metadata.Order select LazyScreen.Create(h);

No big deal but I like it much better now.

Finish LazyScreen

Having proven that LazyScreen works as expected, we should finalize its implementation (mainly delegate actions called on LazyScreen to its inner screen). Here are functions for screen activation and deactivation:

protected override void OnActivate()
{
	ActivateScreen();
}

protected override void OnDeactivate(bool close)
{
	DeactivateScreen(close);
}

private void ActivateScreen()
{
	var activatableScreen = _screen as IActivate;
	if (activatableScreen != null)
	{
		activatableScreen.Activate();
	}
}

private void DeactivateScreen(bool close)
{
	var deactivatableScreen = _screen as IDeactivate;
	if (deactivatableScreen != null)
	{
		deactivatableScreen.Deactivate(close);
	}
}

There are functions for closing too:

public override void CanClose(Action<bool> callback)
{
	var closableScreen = _screen as IGuardClose;
	if (closableScreen != null)
	{
		closableScreen.CanClose(callback);
	}
	else
	{
		base.CanClose(callback);
	}
}

public new void TryClose()
{
	var closableScreen = _screen as IClose;
	if (closableScreen != null)
	{
		closableScreen.TryClose();
	}
	base.TryClose();
}

And for Parent/Child relationship:

public override object Parent
{
	get
	{
		return base.Parent;
	}
	set
	{
		base.Parent = value;

		if (IsScreenCreated)
		{
			SetScreenParent();
		}
	}
}

private void SetScreenParent()
{
	var childScreen = _screen as IChild;
	if (childScreen != null)
	{
		childScreen.Parent = this.Parent;
	}
}

Then update getter for Screen property:

if (!IsScreenCreated)
{
	_export = _factory.CreateExport();
	_screen = _export.Value;

	SetScreenParent();
	if (IsActive)
	{
		ActivateScreen();
	}
}

And add this line just to the beginning of the lock statement in Reset():

DeactivateScreen(true);

So, our LazyScreen is ready. It loads its content only when needed and the rest of the application works properly. In the next part of this series, we will implement LazyConductor so that we can close (reset) LazyScreens.

What do you think about this solution? Have you already solved similar problems?

Coproject - a RIA Caliburn.Micro demo, part 12

Tue, 21 Jun 2011 13:56:43 GMT

by Augustin Šulc

In this part, I would like to use RIA Services a little more and then show you how to customize Caliburn.Micro conventions. Remember to visit Coproject Codeplex site for latest news.

Display metadata

If you remember Part 2, RIA Services use metadata to describe what data should be transferred to the client. But that is not all – you can add things like label text or validation. So, open Coproject.Web/Services/CoprojectService.metadata.cs.

Let’s say we want to change labels in ToDoItem detail:

So in ToDoItemMetadata, update the following properties:

[Display(Name="Task", Description="Describe the To-do task.")]
public string Content { get; set; }

[Display(Name = "Deadline", Description = "The latest possible date the task must be finished.")]
public Nullable<DateTime> DueDate { get; set; }

[Include]
[Association("FK_ToDoItems_Users", "UserID", "UserID", IsForeignKey = true)]
[Display(Name="Assigned user")]
public User User;

If you run the application now you will see the metadata applied:

Note that you could use other named parameters of [Display] to modify auto-generation of DataForms: AutoGenerateField, Order, Groupname. There are other useful parameters – you can check them on MSDN.

Validation metadata

Matadata can be also used for setting validation restrictions. Update the following:

[Display(Name = "Task", Description = "Describe the To-do task.")]
[Required]
[StringLength(40)]
public string Content { get; set; }

[Range(typeof(DateTime), "1.1.2010", "31.12.2019")]
[Display(Name = "Deadline", Description = "The latest possible date the task must be finished.")]
public Nullable<DateTime> DueDate { get; set; }

And now, when you run the application, you can see something like that (note that the Save button is disabled as there are validation errors):

You should look into System.ComponentModel.DataAnnotations for other useful attributes. For example if we set this on DueData:

[Editable(false)]

The field will be disabled for editing even in edit mode. That is how you set your domain on the server so that there is as little as possible of specific code concerning your domain in your presentation layer.

Shared code

As you can see, the User field shows only last name of the user and that is not what we want. This a great opportunity to show you how to use shared code between server and client. All you need to do is to call the file you want to be shared as *.shared.cs. So in Coproject.Web project, create a new file Models/User.shared.cs and set its content as follows:

namespace Coproject.Web.Models
{
	public partial class User
	{
		public string FullName
		{
			get
			{
				return string.Format("{0} {1}", this.FirstName, this.LastName);
			}
		}
	}
}

It is especially important to use this namespace (so that you can extent the partial class created by RIA Services) and to remove using of System.Web (since tis file is copied to the client as-is and there is no reference to this assembly). Now, we can edit ToDoItemView as follows:

<dataForm:DataField PropertyPath="User">
	<TextBlock Text="{Binding User.FullName}" />
</dataForm:DataField>

Note that you can share validators and other logic this way.

Filter on Enter

Another thing I would like to tweak a little bit would be to start filtering right when user hits Enter in the filter text box in ToDoListsView. The easiest way you are probably thinking of would be to add this handler to the Filter text box:

cal:Message.Attach="[KeyDown] = [HandleKeyInFilter($eventargs)]"

and then add this to view model:

public IEnumerable<IResult> HandleKeyInFilter(System.Windows.Input.KeyEventArgs eventargs)
{
	if (eventargs.Key == System.Windows.Input.Key.Enter)
	{
		yield return LoadData().ToSequential();
	}

	yield break;
}

Although this approach would work prefectly, it might not be a good idea to make view model dependent on KeyEventArgs. The best approach would be to customize Caliburn.Micro.Parser.CreateTrigger to support other action s than Event (like EnterPressed, or Gesture Key: Enter that is supported by original Caliburn). But I don’t want to change C.M source here. The last solution I can think of would be to create ExtendedTextBox and add EnterKeyDown event to it:

namespace Coproject.Controls
{
	public class ExtendedTextBox : TextBox
	{
		public event EventHandler EnterKeyDown;

		protected override void OnKeyDown(KeyEventArgs e)
		{
			base.OnKeyDown(e);

			if (e.Key == Key.Enter)
			{
				OnEnterKeyDown();
			}
		}

		protected void OnEnterKeyDown()
		{
			var handler = EnterKeyDown;
			if (handler != null)
			{
				handler(this, EventArgs.Empty);
			}
		}
	}
}

In order to have the default text box style applied to this new control too, we also have to add this to Custom.xaml:

<Style TargetType="local:ExtendedTextBox" BasedOn="{StaticResource DefaultTextBoxStyle}" />

And then we can easily use this new text box in ToDoListsView:

<local:ExtendedTextBox x:Name="Filter" Style="{StaticResource FilterTextBoxStyle}" 
						cal:Message.Attach="[EnterKeyDown] = [LoadData]" />

I, personally, like this way more because view and view models don’t have any clue about views implementation.

Customizing Caliburn.Micro conventions

Since we created a new control, we would like to save some configuration about attaching actions to it and use C.M convention instead. So, open AppBootstrapper, add a call to InitializeConvention() into Configure() and implement it as follows:

private void InitializeConventions()
{
	ConventionManager.AddElementConvention<BusyIndicator>(BusyIndicator.IsBusyProperty, "IsBusy", "Loaded");
	ConventionManager.AddElementConvention<ExtendedTextBox>(ExtendedTextBox.TextProperty, "Text", "EnterKeyDown");
}

The first argument configures to what property should be the respective view model property bound to. So if we name a BusyIndicator ‘Busy’, its IsBusy property will be bound to (viewModel).Busy.

The second arguments describes what property of the control should be taken if this control is set as an action parameter. If you remember LoadData(string filter) then this argument is responsible that the Text property of ‘Filter’ text box was passed.

The third argument configures the default event to start actions.

Now, we can update these two controls in ToDoListsView as follows:

<local:ExtendedTextBox x:Name="Filter" Style="{StaticResource FilterTextBoxStyle}" cal:Message.Attach="LoadData" />

<toolkit:BusyIndicator x:Name="Busy_IsBusy"  Grid.RowSpan="2" />

Note: I am not saying that this is exactly what you should do in your projects, it was just a great example for showing how these things work. You have to think about it and decide yourself – concrete decision depends on many factors.

Opened details counter

I found this quite useful when experimenting with details opening and closing so if you want to, add this code to ToDoListsView, above Toolbar:

<StackPanel Grid.Column="1" Orientation="Horizontal" HorizontalAlignment="Right" Margin="0,-25,0,0">
	<TextBlock Text="Opened details: " Style="{StaticResource StatusTextBlockStyle}" />
	<TextBlock x:Name="Items_Count" Style="{StaticResource StatusTextBlockStyle}" />
</StackPanel>

I think that by now, you are so familiar with the concept that there is no need to describe what this does.

Coproject - a RIA Caliburn.Micro demo, part 1

Tue, 21 Jun 2011 13:50:12 GMT

by Augustin Šulc

In this part, I would like to describe the Coproject application, overview its architecture, and prepare its database.

What will Coproject do

If you know BaseCamp, the idea of Coproject should be familiar to you. For others, let’s say we want to create a simple project management tool. It should help you track current state and progress of a project. We want it to have four modules: Home and overview, Messages, To-Do lists, and Milestones.

Since I want this tutorial to be as simple and clear as possible, we will focus on To-Do lists only. We want the application to show list of To-Do items, filter the list, show detail of selected To-Do item, and edit the item. I believe that for now, it is enough to keep you focused on our goal and I hope I will be able to show how to handle many issues that you usually encounter while developing business applications.

Architecture

Based on the analysis illustrated in the original presentation, Coproject will be a three layered application based on a SQL database, ADO.NET Entity Framework 4, WCF RIA Services and Silverlight 4.

Data source

In this tutorial. we will use a simple SQL database for data storage because this is probably the typical case. Nevertheless, you may use any other data source that is supported by Entity Framework 4. The most important part of the database schema is shown below:

To make it a little more complicated than simple list of items, ToDoItems are grouped by ToDoLists.

Web server

On the application server side, we will use Entity Framework 4 to access data source. If you are not familiar with it, check this site.

To make the data available for the Silverlight client, we will use WCF RIA Services. You can learn more about it here.

The client itself and the services will be hosted in an ASP.NET Web application and thus the client application will be accessible via browser. However, we will also support out-of-browser running.

Client

The client will be implemented as a Silverlight 4 application. It will follow M-V-VM design pattern using Caliburn.Micro framework. It should handle typical business scenarios like: asynchronous loading of data, loading indication, opening and editing of more than one entity at a time, validation, dirty checking, etc.

Getting ready for development

We need to create a database for Coproject. Although you can create a database file in Visual Studio, it is not possible to execute a script on a database through VS. So you can either create an ordinary database on your server (or local Express server) and execute Create script attached to this article, or download already prepared database file Database.mdf and put into App_Data folder of web server that we created last time.

You should be able to double-click it and have it opened in Server Explorer:

Rebuild the solution to make sure there are no errors.

That’s all for now. The next time, we’ll create a RIA service.

Script and Database

Coproject - a RIA Caliburn.Micro demo, part 9

Sat, 19 Feb 2011 15:52:22 GMT

by Augustin Šulc

In this part, we will add a toolbar and handle data saving.

Toolbar

It is a typical scenario that screens have toolbars. These are usually shown somewhere else in the application than their respective view model’s views. In this case, we will benefit from Caliburn.Micro’s feature of having more than one view attached to a view model. You can describe what view you want to show by setting ‘context’ of the view.

So, open the Coproject solution where we finished the last time or download source codes from Coproject site. Add this control to root grid in ToDoListsView:

<ContentControl Grid.Column="1" Grid.Row="0" Margin="10,0,0,0" HorizontalContentAlignment="Stretch" 
				cal:View.Model="{Binding ActiveItem}" cal:View.Context="Toolbar" />

Important is the second line. Since there is already a control called ActiveItem and we want to bind this control to the active item too, we have to use cal:View.Model structure. Even more important is cal:View.Context because it instructs C.M not to use the default view (ToDoItemView in this case) but Toolbar view.

C.M’s default logic for locating context views is: take the default view location (e.g., Views.ToDoItemView), trim ‘View’ from the end, add ‘.’ + context. So it would end up with Views.ToDoItem.Toolbar. And that’s where we have to put our new Silverlight User Control. Then replace its original LayoutRoot with the following:

<Border Style="{StaticResource FilterPanelStyle}">
	<StackPanel Orientation="Horizontal" HorizontalAlignment="Right">
		<Button x:Name="Edit" Content="Edit" Margin="0,0,5,0" />
		<Button x:Name="Cancel" Content="Cancel" Margin="0,0,5,0" />
		<Button x:Name="Save" Content="Save" Margin="0,0,5,0" />
		<Button x:Name="TryClose" Content="Close" />
	</StackPanel>
</Border>

So the structure of the client project should be like:

Context views are bound to view models the same way as default views, so it is not a surprise that now we are going to implement Edit, Cancel, and Save functions (TryClose is already implemented in Screen base class).

ViewModel behavior

We want the detail to be in read-only mode with buttons Cancel and Save disabled. When Edit is clicked, the detail should change to edit mode and disable edit button. This will be done by adding another property IsReadOnly to the view model. So, open ToDoItemViewModel.

First of all, we will add the IsReadOnly property. Since we want it to automatically raise NotifyPropertyChanged, we cannot use the one-line definition, so write this:

private bool _isReadOnly;
public bool IsReadOnly
{
	get
	{
		return this._isReadOnly;
	}
	set
	{
		this._isReadOnly = value;
		NotifyOfPropertyChange(() => IsReadOnly);
	}
}

Implementation of Edit function is very lightweight:

public void Edit()
{
	IsReadOnly = false;
}

Cancel will be only a little bit longer because we need to cancel changes before switching back to read-only mode. We will benefit from the fact that RIA Services entities implement IEditableObject interface. In order to fix a DataForm bug I mention last time, we have to switch to read-only, then back to edit, and finally again to read-only mode:

public void Cancel()
{
	(Item as IEditableObject).CancelEdit();
	IsReadOnly = true;
	#region Fix DataForm bug
	IsReadOnly = false; IsReadOnly = true;
	#endregion
}

In order to implement Save(), we will need SaveDataResult. It is wuite similar to LoadDataResult we implemented earlier. So create new class SaveDataResult into the Framework folder:

namespace Coproject.Framework
{
	public class SaveDataResult : IResult
	{
		public DomainContext Context { get; private set; }
		public SubmitOperation Result { get; private set; }

		public event EventHandler<ResultCompletionEventArgs> Completed;

		public SaveDataResult(DomainContext context)
		{
			Context = context;
		}

		public void Execute(ActionExecutionContext context)
		{
			Context.SubmitChanges(SaveDataCallback, null);
		}

		private void SaveDataCallback(SubmitOperation data)
		{
			Result = data;
			OnCompleted();
		}

		private void OnCompleted()
		{
			var handler = Completed;
			if (handler != null)
			{
				handler(this, new ResultCompletionEventArgs());
			}
		}
	}
}

Now, we can use it ToDoItemViewModel.Save() implementation:

public IEnumerable<IResult> Save()
{
	(Item as IEditableObject).EndEdit();
	IsReadOnly = true;
	#region Fix DataForm bug
	IsReadOnly = false; IsReadOnly = true;
	#endregion

	yield return new SaveDataResult(_context);
}

Finally, bind the DataForm on ToDoItemView to the IsReadOnly property:

<dataForm:DataForm CurrentItem="{Binding Item}" IsReadOnly="{Binding IsReadOnly}" HorizontalAlignment="Stretch">

If you now run the application, you will notice that switching modes works and savings works too (you must refresh the list). There still some issues: opened detail is already in edit mode, all buttons are enabled.

Fixing the first issue is trivial – add this row to the beginning of Setup(int toDoItemID):

IsReadOnly = true;

Guard methods

To fix the other issue, we will use ‘guards’. These are another part of Caliburn.Micro’s ‘Convention over configuration’ system. If there is a control bound to any function of a view model and the view model also contains property or function called CanXXX, it will use this CanXXX function to determine whether it is possible to run the bound function itself. These 'CanXXX’ properties are called guards. Note that C.M will also update availability of invoking controls. So as you can guess, we will implement properties CanEdit, CanCancel, and CanSave:

public bool CanEdit
{
	get { return IsReadOnly; }
}
		
public bool CanCancel
{
	get { return !IsReadOnly; }
}

public bool CanSave
{
	get { return Item.HasChanges && !Item.HasValidationErrors; }
}

We also need to notify when these properties change. So update set of IsReadOnly as follows:

set
{
	this._isReadOnly = value;
	NotifyOfPropertyChange(() => IsReadOnly);
	NotifyOfPropertyChange(() => CanEdit);
	NotifyOfPropertyChange(() => CanCancel);
}

CanSave property depends on the state of Item, so add this line at the end of the Setup function:

Item.PropertyChanged += (s, e) => NotifyOfPropertyChange(() => CanSave);

You can now run the application and see how the buttons get disabled and enabled as appropriate.

Dirty checking

As Close button works too, we should add dirty-checking logic so that we don’t lose unsaved changes when closing detail. This is done using CanClose virtual function. This function is closed when C.M wants to close the screen. It is then up to the implementation what happens but when it is resolved, the CanClose function should call callback with information whether it can be closed or not. Add this function to ToDoItemViewModel:

public override void CanClose(Action<bool> callback)
{
	if (Item.HasChanges)
	{
		var result = MessageBox.Show("Current item was not saved. Do you really want to close it?", 
			"Coproject", MessageBoxButton.OKCancel);
		callback(result == MessageBoxResult.OK);
	}
	else
	{
		callback(true);
	}
}

I know that the question in the message is not ok for buttons OK or Cancel but that’s all we get from Silverlight out of the box. You definitely should implement custom message box (I will talk about it in later posts).

There is one more thing I want to implement: if the detail is closed and its entity is edited, it would be better to cancel the changes. Implementation is very straightforward:

protected override void OnDeactivate(bool isClosing)
{
	if (isClosing && CanCancel)
	{
		Cancel();
	}
}

That is all for toolbar and dirty-checking. It was quite easy, wasn’t it?

UpdateSourceOnChange

I bet you noticed that when editing Content, you have to click somewhere else to enable the Save button. The reason for that is that TextBox in Silverlight updates its binding source only when it loses focus and this cannot be changed as in WPF by setting UpdateSourceTrigger=PropertyChanged. Fortunately, this can be achieved in Silverlight too, but we will need this helper class in Coproject/Helpers:

public static class BindingHelper
{
	public static bool GetUpdateSourceOnChange(DependencyObject obj)
	{
		return (bool)obj.GetValue(UpdateSourceOnChangeProperty);
	}

	public static void SetUpdateSourceOnChange(DependencyObject obj, bool value)
	{
		obj.SetValue(UpdateSourceOnChangeProperty, value);
	}

	public static readonly DependencyProperty UpdateSourceOnChangeProperty =
		DependencyProperty.RegisterAttached("UpdateSourceOnChange", typeof(bool), 
		typeof(BindingHelper), new PropertyMetadata(false, OnPropertyChanged));

	private static void OnPropertyChanged(DependencyObject obj, DependencyPropertyChangedEventArgs e)
	{
		var textBox = obj as TextBox;
		if (textBox != null)
		{
			if ((bool)e.NewValue)
			{
				textBox.TextChanged += TextBox_TextChanged;
			}
			else
			{
				textBox.TextChanged -= TextBox_TextChanged;
			}
		}
	}

	private static void TextBox_TextChanged(object sender, TextChangedEventArgs e)
	{
		var textBox = sender as TextBox;
		if (textBox != null)
		{
			var binding = textBox.GetBindingExpression(TextBox.TextProperty);
			if (binding != null)
			{
				binding.UpdateSource();
			}
		}
	}
}

Your Solution Explorer should show this:

Lastly, we need to use this helper in our views. Open ToDoItemView and register this namespace in it:

xmlns:helpers="clr-namespace:Coproject.Helpers"

Then update the TextBox in DataField bound to Content as follows:

<TextBox Text="{Binding Content,Mode=TwoWay}" TextWrapping="Wrap" Height="auto"
			helpers:BindingHelper.UpdateSourceOnChange="True"/>

And that is really all for this part. Run the application and experiment!

Unity/EntLib interceptors in MEF

Fri, 18 Feb 2011 10:10:35 GMT

By Augustin Šulc

In one of our applications, we use MEF for discovery of component exports. To make it more complicated, we also wanted to use Enterprise Library interceptors for advanced logging, error handling and caching (from Policy Injection Application Block) so we needed to use Unity as well. MEFContrib was a great helper for us so we were able to use (in simplified words) MEF for exports and Unity for imports. Although there were some problems it worked. With the new version of MEFContrib, things became even easier as support for interception and open generics was added to MEF.

The current MEFContrib interceptor implementation uses Castle’s Dynamic Proxy 2 or LinFu as intercepting proxies. But as we wanted to use the original EntLib interceptors that were meant for Unity, I had to add support for Unity’s InterfaceInterceptor to MEFContrib.

Unity Interceptor

To implement UnityInterceptor for MEFContrib, I suggest to download the latest source codes for MEFContrib and build it yourself as the interception and generics support have been extended since the 1.0 release.

Supposing you already have MEFContrib running, reference it in your project and then add this class to your project:

public class UnityInterceptor : IExportedValueInterceptor
{
	public object Intercept(object value)
	{
		var interfaces = value.GetType().GetInterfaces();
		var proxyInterface = interfaces.FirstOrDefault();
		var additionalInterfaces = interfaces.Skip(1).ToArray();

		var interceptor = new InterfaceInterceptor();

		CurrentInterceptionRequest request = new CurrentInterceptionRequest(interceptor, proxyInterface, value.GetType());
		InjectionPolicy[] policies = new InjectionPolicy[] { new AttributeDrivenPolicy() };
		PolicyInjectionBehavior behaviour = new PolicyInjectionBehavior(request, policies, null);

		var proxy = Microsoft.Practices.Unity.InterceptionExtension.Intercept.ThroughProxyWithAdditionalInterfaces(
			proxyInterface,
			value,
			interceptor,
			new[] { behaviour },
			additionalInterfaces);

		return proxy;
	}
}

I will send this code to the MEFContrib team so hopefully it will be integrated into MEFContrib bits.

Then, add the following code to your MEF container initialization:

var catalog = new DirectoryCatalog(System.Web.Hosting.HostingEnvironment.MapPath("~/Bin")); // create your original MEF catalog

var interceptionConfiguration = new InterceptionConfiguration()
	.AddInterceptionCriteria(new PredicateInterceptionCriteria(
		new UnityInterceptor(),
		predicate); // predicate that filters to what export components should be interceptors applied (you will probably use some metadata filtering or omit it)
var interceptingCatalog = new InterceptingCatalog(catalog, interceptionConfiguration);
//use interceptingCatalog (initialize MEF with it)

You are done – now you can use EntLib attributes, for example, [LogCallHandler] on your components and they will work as expected!

E-mail protection on your site

Tue, 08 Feb 2011 12:55:19 GMT

by Míša Hájková

Let’s imagine following situation. You create new modern website and because you are looking for some feedback from your potential customers, your new e-mail address shouldn’t missed. But after some time, you receive first offer for some blue pills, and then next and next and… - and then you’re doing nothing else than deleting spam. That’s because your e-mails are not protected and can be easily harvested by specialized robots called spambots.

What spambots do? It’s easy, they get html of your web page and search for e-mails. Here is small example how spambot should work:

HttpWebRequest request = (HttpWebRequest)HttpWebRequest.Create("website_url");
request.Method = "GET";
using (HttpWebResponse response = (HttpWebResponse)request.GetResponse())
{
 StreamReader stream = new StreamReader(response.GetResponseStream());
 string html = stream.ReadToEnd();
 foreach (Match m in Regex.Matches(html, @"\w[\w\.-]+?@(?:[\w-]+\.)+[\w]{2,4}"))
 {
  Console.WriteLine(m.Value);
 }
}

As you see, it’s really very easy to get your e-mail addresses from your website. You can harvest links from your page in similar way and then harvest e-mails from all of Internet – except pages, where e-mails are protected. Let’s take a look, how to do it.

First question is: Where is the best place for code? Your e-mail protecting code can be placed into overridden Render method of your page or into the same method of base class of your page, or master page. But if you want to protect more websites, or protect non-aspx files such as html, the best way is to use ResponseFilter in new (or maybe your existing) HTTP Module. This HTTP Module can be used in as many sites as you want, you simply copy compiled files into bin directory of your site and register this module in web.config. If you are really brave and want to protect whole your IIS, you can copy your files to GAC and register it in machine.config. Base information about HTTP Modules can be found here: http://msdn.microsoft.com/en-us/library/zec9k340(v=VS.71).aspx.

Let’s show how to create our custom HTTP Module protecting e-mail addresses being harvested by spambots.

First, we need to create basic HTTP Module functionality:

public class EmailFilter : IHttpModule
{
 public void Init(HttpApplication app)
 {
  app.PostRequestHandlerExecute += new EventHandler(app_PostRequestHandlerExecute);
 }
 
 private void app_PostRequestHandlerExecute(object sender, EventArgs e)
 {
  
 }
 
 public void Dispose() { }
}

Methos Init and Dispose must be presented in every class implementing IHttpModule interface. Inside Init method, you see declaration of new PostRequestHandlerExecute handler. It fires right after page is executed and before it is send to the client. This is the right time to modify generated content and send to the client this modified code. Inside PostRequestHandlerExecute we append our new e-mail protecting ResponseFilter to the response stream.

private void app_PostRequestHandlerExecute(object sender, EventArgs e)
{
 HttpResponse response = ((HttpApplication)sender).Response;
 string rawUrl = ((HttpApplication)sender).Request.RawUrl.ToLower();
 if (String.Equals(response.ContentType, "text/html"))
 {
  response.Filter = new EmailStreamFilter(response.Filter, response.ContentEncoding);
 }
}

As you see, we check mime type of response. It isn’t good idea to replace some strings in images, documents or other files non-text files. We want to modify only html. If you want, you can add another conditions, for example if you have some private part of your website (i.e. admin subweb) where e-mail protecting is not necessary, or even unwanted, you can check url of request and pass only wanted parts of website. Inside condition, you see unknown class EmailStreamFilter. That is our next step – create this stream filter.

public class EmailStreamFilter : Stream
{
 Stream stream;
 
 public EmailStreamFilter(Stream sourceStream, Encoding sourceencoding)
 {
  stream = sourceStream;
 }
 
 public override void Write(byte[] buffer, int offset, int count)
 {
  stream.Write(buffer, offset, count);
 }
 
 public override int Read(byte[] buffer, int offset, int count)
 {
  return stream.Read(buffer, offset, count);
 }
 public override bool CanRead
 {
  get { return stream.CanRead; }
 }
 public override bool CanSeek
 {
  get { return stream.CanSeek; }
 }
 public override bool CanWrite
 {
  get { return stream.CanWrite; }
 }
 public override void Flush() { }
 public override long Length
 {
  get { return stream.Length; }
 }
 public override long Position
 {
  get { return stream.Position; }
  set { }
 }
 public override long Seek(long offset, SeekOrigin origin)
 {
  return 0;
 }
 public override void SetLength(long value) { }
}

As you see, Stream Filter is based on Stream object, and it must contain implementation of it’s base abstract methods and properties. Maybe it looks little complicated, but we won’t work with all of this members. All we need is only to declare some new members and modify constructor and Write method, as you see bellow.

public class EmailStreamFilter : Stream
{
 Stream stream;
 Encoding encoding;
 string html;
 
 public EmailStreamFilter(Stream sourceStream, Encoding sourceencoding)
 {
  stream = sourceStream;
  encoding = sourceencoding;
  html = "";
 }
 
 public override void Write(byte[] buffer, int offset, int count)
 {
  html += encoding.GetString(buffer, offset, count);
 
  if (html.IndexOf("</html>") > 0)
  {
   //secure e-mails
   byte[] data = encoding.GetBytes(html);
   stream.Write(data, 0, data.Length);
  }
 }
 
 #region implementation of abstract members of base Stream object
}

As you see in Write method, we simply collect response data as long as we find end of html represented by </html> tag. This is weak part of this solution, but problem is we don’t now size of response data of current page. Valid html is really necessary.

Our EmailStreamFilter is almost complete now. Only we need is replace comment //secure e-mails with some code which will do it :) First we need is some method to find e-mail inside html. You can use, for example, following regular expression:

\b(\w[\w\.-]+?@(?:[\w-]+\.)+[\w]{2,4})\b

It’s easy, and what is more important, it’s fast. Imagine very very large page – you really don’t need some complex expression used in for example in validators, you need combination of reliability but also great speed . Now, what shall we do with captured e-mails? We can simply replace dots and at-signs with their text representation (dot) and (at). After it, all of our e-mails on our page are secured. There are not any e-mails, there are only text representations which can be understood by humans, but not by spambots. If it’s not enough, you can use any other replacement, for example mail – here is at – domain – here is dot – com. Or – you can use images or links to special page with CAPTCHA code. There are many ways to fight with spambots (almost as many, as they know to fight with us).

In this example, we use first method and simple replace dots and at-sign with their text representation.

But because it’s not so comfortable to rewrite this encoded e-mails to real e-mails, we also use javascript to replace text representation of our secured e-mails back to original e-mails. Spambots, as far I now, don’t execute javascript. And why they should? There are many unprotected sites on the Internet and it’s easier to harvest e-mails from them, than lost time with programming script executing spambot.

<script type="text/javascript">var body = document.getElementsByTagName('body')[0]; body.innerHTML = body.innerHTML.replace(/\(dot\)/gm, '.').replace(/\(at\)/gm, '@');</script>

This small script replace all of our secured e-mail addresses to their original format. But only for those clients with enabled javascript, which is now majority of human users. We replace this only in body of html but if you want, you can replace also in head, or you can link external more sophisticated script. You have many possibilities again. Now let’s look to our completed EmailStreamFilter.

public class EmailStreamFilter : Stream
{
 Stream stream;
 Encoding encoding;
 string html;
  
 bool isEmailFound = false;
 static Regex _regEmail = new Regex(@"\b(\w[\w\.-]+?@(?:[\w-]+\.)+[\w]{2,4})\b", RegexOptions.Compiled);
 
 public EmailStreamFilter(Stream sourceStream, Encoding sourceencoding)
 {
  stream = sourceStream;
  encoding = sourceencoding;
  html = "";
 }
 
 public override void Write(byte[] buffer, int offset, int count)
 {
  html += encoding.GetString(buffer, offset, count);
 
  if (html.IndexOf("</html>") > 0)
  {
   MatchEvaluator emailEvaluator = new MatchEvaluator(EmailEvaluator);
   html = _regEmail.Replace(html, emailEvaluator);
   if (isEmailFound) html = html.Insert(html.IndexOf("</body>"), @"<script type=""text/javascript"">var body = document.getElementsByTagName('body')[0]; body.innerHTML = body.innerHTML.replace(/\(dot\)/gm, '.').replace(/\(at\)/gm, '@');</script>");
    
   byte[] data = encoding.GetBytes(html);
   stream.Write(data, 0, data.Length);
  }
 }
 
 private string EmailEvaluator(Match m)
 {
  isEmailFound = true;
  string noScriptEmail = m.Groups[1].Value.Replace("@", "(at)").Replace(".", "(dot)");
  return noScriptEmail;
 }
 
 #region implementation of abstract members of base Stream object
}

And that’s almost all. Last step is registering your new HTTP Module inside appropriate section of your web.config and work is done.

At the end, before comments :), I have one small icing on the cake. Maybe protecting e-mails is not enough, maybe you want to create links from e-mails not inside <a> tag. In that case, only you need is find right regular expression. For example this one:

\b(?![^<]*>)(?!.*</head>)(\w[\w\.-]+?@(?:[\w-]+\.)+[\w]{2,4})\b(?![^<]*(<[^a][^<]*)*</a>)

This ugly string above is regular expression, which find e-mails not inside head, not inside tag attribute and not inside <a> tag (and of course abbr, and other tags beginning with a – yes it’s not perfect, but it may be sufficient for your purposes). All you need then is inserting these two lines of code into right place, and work is done.

static Regex _regNoLinkEmail = new Regex(@"\b(?![^<]*>)(?!.*</head>)(\w[\w\.-]+?@(?:[\w-]+\.)+[\w]{2,4})\b(?![^<]*(<[^a][^<]*)*</a>)", RegexOptions.Compiled);
html = _regNoLinkEmail.Replace(html, "<a href=\"mailto:$1\">$1</a>");

Enjoy it.

Optimizing size of public websites based on Sharepoint

Fri, 04 Feb 2011 18:10:59 GMT

By Míša Hájková

Sharepoint is generally very good platform for intranet applications. But you can meet more and more public web applications based on Sharepoint. Despite my humble opinion, that Sharepoint really isn’t the best choice for this purpose, some of our customers web presentations are based on it.

The biggest problem, I was faced, is many many…. really many parts I don’t need. Default master page in Publishing site contains lot of controls and referenced files, which are useful in intranet, and some of them are also useful for editing content, but visitors of your site really don´t need them – they don´t edit pages, don´t approve them, they only browse pages.

Here is image taken from Firebug showing the overall amount of data visitor’s browser download from our site before it was optimized:

As you see, user download almost 700 KB of data. And most of them are Sharepoint data which are useless on read-only sites.

core.js – good for editing and administrating site, but visitors doesn’t need it;
core.css – our website use it’s own stylesheet, we don´t need another 80 KB which is not used anywhere;
init.js – our read only site doesn’t need it, why visitors must download it?

I check some of sites presented on http://www.topsharepoint.com and few of them are optimized and relatively small, but most of them has really terrible overall size of landing page and all referenced files. Average is about 1 MB, but there are some 3 MB or 4 MB! Yes, most of these files are stored in cache after first load, but problem is mentioned first load. Many users has only limited bandwidth (mobile connection is more and more common). They probably don’t wait five minutes for loading landing page, they close browser’s tab and find another (probably faster) page.

If your website is based on Sharpeoint, don’t be sad, here is solution of this pain.

Important information: This solution works and is tested in MOSS 2007, but similar technics can be used in other versions.

First of all, I recommended you to use minimal master page (http://msdn.microsoft.com/en-us/library/aa660698(v=office.12).aspx), similar minimal master page exists also for MOSS 2010. It’s first step to wipe out Sharepoint things, you don’t need in Publishing web.

In next step, you must modify Render method of your master page. It can be done in <script runat=”server”> block or in code behind file referenced in <%@ Master %> directive.

protected override void Render(HtmlTextWriter writer)
{
	string html = string.Empty;
	using (StringWriter sw = new StringWriter())
	{
		using (HtmlTextWriter tw = new HtmlTextWriter(sw))
		{
			base.Render(tw);
			html = sw.ToString();
		}
	}

	// Do something with html

	writer.Write(html);
}

As you see, you can take html right before it’s send to client. And what’s better, you can modify it. And that’s right what we need. We use regular expressions to find and remove references to scripts and style sheets, we don’t need, and also remove Sharepoint hidden fields and script blocks:

protected override void Render(HtmlTextWriter writer)
{
	string html = string.Empty;
	using (StringWriter sw = new StringWriter())
	{
		using (HtmlTextWriter tw = new HtmlTextWriter(sw))
		{
			base.Render(tw);
			html = sw.ToString();
		}
	}
	if (_isPublicWeb)
	{
		// removing of all hidden MSO... and __SPCEditMenu fields for page editing
		html = Regex.Replace(html, @"<input type=""hidden"" name=""(MSO|__SPSCEditMenu).*?/>\s*", String.Empty);
		// removing of MOSS client scripts for page editing
		html = Regex.Replace(html, @"<script> var MSOWebPartPageFormName.*?</script>\s*", "");
		html = Regex.Replace(html, @"<script[^>]*src=""/_layouts/1029/.*?></script>\s*", "");
		html = Regex.Replace(html, @"<script type=""text/javascript"">\s*//<\!\[CDATA\[\s*var __wpmExportWarning=.*\s*</script>\s*", "");
		// removing of MOSS body and form scripts
		html = html.Replace(@"<body onload=""javascript:_spBodyOnLoadWrapper();"">", "<body>");
		html = Regex.Replace(html, @"(<form.*?)onsubmit="".*?""(.*?>)", "$1$2");
		// removing references to MOSS styles
		html = Regex.Replace(html, @"<link rel=""stylesheet"".*?href=""/_layouts/1029.*?/>", "");
		// removing of (not html valid) ms-action table
		html = Regex.Replace(html, @"<!-- Begin Action Menu Markup -->(.|\s)*?<!-- End Action Menu Markup -->", "");

		// if we don't use WebResource.axd, we can remove it
		html = Regex.Replace(html, @"<script[^>]?src=""/WebResource.axd.*?></script>\s*", "");
	}
	writer.Write(html);
}

Variable _isPublicWeb contains information, whether this site is public (read only) or not. We assign it with value stored in web.config, but you can choose different approach (for example check rights).

After these steps our site look much better:

Now, overall amount of downloaded data is only 113 KB and after optimization of our stylesheet it can be plus minus 100 KB, which is acceptable for site visitors and also for site creators :) Difference between site before optimization and after it is half of megabyte.

At the end, you can improve your Render to lower size of your aspx files:

html = Regex.Replace(html, @"[ \t]{2,}", " "); // all tab sequences are replaced with space
html = Regex.Replace(html, @"(\r\n(\s*)){2,}", "\r\n"); // removing all of empty rows
if (IsPublicWeb) ...

This method is also useful for validating HTML (if you need it), or other activities, if you need modify Sharepoint pages before sending them to client . If you are not sure if you can remove some fields or references, don’t afraid. You can try it row by row, or create own regular expression.

And that’s all. I hope this article can help someone :)

Coproject - a RIA Caliburn.Micro demo, part 10

Wed, 26 Jan 2011 09:29:22 GMT

by Augustin Šulc

In this part, we will add a busy indicator.

As you know, communication with server takes some time. Even in our small project loading might take several seconds so it would be a good idea to notify the user that something is happening in background.

So, open your solution from part 9 or grab source codes from Coproject site and let’s start.

BusyIndicator

First of all, add a BusyIndicator control to ToDoListsView. So, add this namespace using:

xmlns:toolkit="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Toolkit"

and paste this control to the end of LayoutRoot (below ActiveItem and Toolbar):

<toolkit:BusyIndicator IsBusy="{Binding IsBusy}"  Grid.RowSpan="2" />

Then we must implement the IsBusy property on ToDoListsViewModel.

IsBusy property

The easiest way to implement busy indication would be to add IsBusy property to ToDoListsViewModel:

private bool _isBusy;
public bool IsBusy
{
	get
	{
		return this._isBusy;
	}
	set
	{
		this._isBusy = value;
		NotifyOfPropertyChange(() => IsBusy);
	}
}

Then, we just set it to true at the beginning of LoadData function and to false at the end. Try it, it should work well.

Note: if the loading is too fast so you cannot see the BusyIndicator, open CoprojectService and add Thread.Sleep(1000); above ‘return’ statement to the proper GetXXX function (GetToDoListsWithItems to be exact).

BusyWatcher

Although this approach works, you can see problems if more than one loading is done at a time:

- the first action starts and sets IsBusy to true
- the other action starts and sets IsBusy to true
- the first action completes and sets IsBusy to false
- the other action is still running but IsBusy is already set to false

So, it would be a good idea to have something like BusyWatcher – a class that has a hidden counter inside, actions just increment or decrement it as they start or finish, and IsBusy property returns whether the counter is greater than 0 or not. One of possible implementations is as follows. Put it into Framework/BusyWatcher.

public class BusyWatcher : PropertyChangedBase
{
	int _counter;

	public bool IsBusy
	{
		get
		{
			return _counter > 0;
		}
	}

	public void AddWatch()
	{
		if (Interlocked.Increment(ref _counter) == 1)
		{
			NotifyOfPropertyChange(() => IsBusy);
		}
	}

	public void RemoveWatch()
	{
		if (Interlocked.Decrement(ref _counter) == 0)
		{
			NotifyOfPropertyChange(() => IsBusy);
		}
	}
}

Next, extract interface IBusyWatcher from it (IsBusy, AddWatch, RemoveWatch) and make BusyWatcher export this interface:

public interface IBusyWatcher
{
	bool IsBusy { get; }

	void AddWatch();
	void RemoveWatch();
}

[Export(typeof(IBusyWatcher))]
public class BusyWatcher : PropertyChangedBase, IBusyWatcher
...

Now, let’s use this watcher in our view model. Replace the IsBusy property in ToDoListsViewModel with the following:

[Import(RequiredCreationPolicy = CreationPolicy.NonShared)]
public IBusyWatcher Busy { get; set; }

And setting of IsBusy in LoadData change to their respective equivalents of Busy.AddWatch/RemoveWatch.

Finally change binding of BusyIndicator int ToDoListsView to:

<toolkit:BusyIndicator IsBusy="{Binding Busy.IsBusy}"  Grid.RowSpan="2" />

OK, this looks much better but what if an exception occurs between AddWatch and RemoWatch calls? BusyWatcher would stay in as busy forever. Of course, we could wrap actions with a try block and put RemoveWatch into a finally statement.

BusyTicket

Another way is to make use of ‘using’ statement. The trick is that we create a disposable ticket for the using statement. And when the ticket gets disposed of, it will RemoweWatch.

Add this class into BusyWatcher:

public class BusyWatcherTicket : IDisposable
{
	IBusyWatcher _parent;

	public BusyWatcherTicket(IBusyWatcher parent)
	{
		_parent = parent;
		_parent.AddWatch();
	}

	public void Dispose()
	{
		_parent.RemoveWatch();
	}
}

Also add this function into BusyWatcher and put its definition into IBusyWatcher too:

public BusyWatcherTicket GetTicket()
{
	return new BusyWatcherTicket(this);
}

Now, we can use it as follows:

public IEnumerable<IResult> LoadData(string filter)
{
	using (Busy.GetTicket())
	{
		CoprojectContext context = new CoprojectContext();

		...

		Lists = result.Result.Entities;
		NotifyOfPropertyChange(() => Lists);
	}
}

Note that in this scenario, you have separate BusyWatcher for every screen (i.e., separate BusyIndicator for every view). But if you, for example, wanted to have one BusyIndicator for the whole application (e.g., in a status bar), we could use a shared BusyWatcher for all view models and add a BusyIndicator into ShellView and bind it to this BusyWatcher. No big deal.

Coproject - a RIA Caliburn.Micro demo, part 6

Mon, 24 Jan 2011 14:14:34 GMT

by Augustin Šulc

In this part, we will load data from database and start using Caliburn.Micro coroutines. Remember that you can get latest news and source code from Coproject Codeplex site.

ToDoListsView

Create a new Silverlight User Control called ToDoListsView in the Views folder. Then replace the original LayoutRoot grid with this one:

<Grid x:Name="LayoutRoot">
	<Grid.ColumnDefinitions>
		<ColumnDefinition Width="6*" />
		<ColumnDefinition Width="5*" />
	</Grid.ColumnDefinitions>
	<Grid.RowDefinitions>
		<RowDefinition Height="auto" />
		<RowDefinition Height="*" />
	</Grid.RowDefinitions>

	<Button x:Name="LoadData" Content="Load" />

	<ItemsControl x:Name="Lists" Grid.Row="1">
		<ItemsControl.ItemTemplate>
			<DataTemplate>
				<StackPanel>
					<TextBlock Text="{Binding Name}" FontWeight="Bold" 
								Style="{StaticResource DefaultTextBlockStyle}" />
					<TextBlock Text="{Binding Description}" TextWrapping="Wrap" 
								Style="{StaticResource DefaultTextBlockStyle}" />
				</StackPanel>
			</DataTemplate>
		</ItemsControl.ItemTemplate>
	</ItemsControl>
</Grid>

As we already know, Caliburn.Micro will automatically bind Lists ItemsControl to ‘Lists’ property of respective view model. Therefore, you can guess that pressing LoadData button will execute function called LoadData, and you would be right. So let’s implement the view model.

ToDoListsViewModel

Open ToDoListsViewModel and add this code to it:

public IEnumerable<ToDoList> Lists { get; private set; }

public void LoadData()
{
	CoprojectContext context = new CoprojectContext();
	EntityQuery<ToDoList> query = context.GetToDoListsQuery().OrderByDescending(l => l.CreatedDate);
	context.Load(query, LoadDataCallback, null);
}

private void LoadDataCallback(LoadOperation<ToDoList> data)
{
	Lists = data.Entities;
	NotifyOfPropertyChange(() => Lists);
}

In Silverlight, all data loading is done asynchronously. It is good for keeping user interface responsive but programming asynchronous tasks requires more coding than working synchronously. To load data from a RIA Services service, you need to instantiate a context (created on compile time by RIA services), get default query from it, modify the query and then pass it back to the context to load it. You should also provide a callback that gets called when the data are loaded.

If you build the project and click Load, after a while, data should appear.

Coroutines

You probably noticed that if we wanted to do some other work after data are loaded, we would have to put it into LoadDataCallback. And if we wanted to load some other data, another callback would have to be created. This could easily become a a nightmare to maintain and debug. Happily, Caliburn.Micro comes to help with coroutines.

Caliburn coroutines are based on objects that implement IResult interface. Purpose of these objects is to execute some action and fire an event when the action is done. C.M then sequentially enumerates results returned from methods like LoadData, executes a result, waits for it to complete and then execute next one. This is achieved by yield return C# keyword. You probably see similarity to new keywords ‘async’ and ‘await’ planned for C# 5.

LoadDataResult

So, let’s implement result that would load data from a RIA Services context. Create LoadDataResult in Framework as follows:

public class LoadDataResult<TEntity> : IResult where TEntity : Entity
{
	public EntityQuery<TEntity> Query { get; set; }
	public DomainContext Context { get; set; }
	public LoadOperation<TEntity> Result { get; private set; }

	public event EventHandler<ResultCompletionEventArgs> Completed;

	public LoadDataResult(DomainContext context, EntityQuery<TEntity> query)
	{
		Query = query;
		Context = context;
	}

	public void Execute(ActionExecutionContext context)
	{
		Context.Load(Query, LoadDataCallback, null);
	}

	private void LoadDataCallback(LoadOperation<TEntity> data)
	{
		Result = data;
		OnCompleted();
	}

	private void OnCompleted()
	{
		var handler = Completed;
		if (handler != null)
		{
			handler(this, new ResultCompletionEventArgs());
		}
	}
}

Although it might seem complicated, most of the code is just initialization and obvious definitions. The only functions worth attention are Exxecute and LoadDataCallback and these are the same as in the LoadData function. When this result is passed to C.M, it will run Execute and then wait until Completed event is raised. Then it will enumerate next result and so on.

We can replace LoadData and LodDataCallback in ToDoListsViewModel with this function:

public IEnumerable<IResult> LoadData()
{
	CoprojectContext context = new CoprojectContext();
	EntityQuery<ToDoList> query = context.GetToDoListsQuery().OrderByDescending(l => l.CreatedDate);
	var result = new LoadDataResult<ToDoList>(context, query);
	yield return result;

	Lists = result.Result.Entities;
	NotifyOfPropertyChange(() => Lists);
}

Now, although LoadDataResult loads data asynchronously, execution of this function will stop at yield return and continue once the result completes. Workflow of LoadData function is obvious now and can be easily edited later.

Include ToDoItems

We still need to add ToDoItems under their parent ToDoLists. First, we must tell RIA Services to include ToDoItems with lists. Open Services/CoprojectService.cs in Coproject.Web project and this function below GetToDoLists function:

public IQueryable<ToDoList> GetToDoListsWithItems()
{
	return this.ObjectContext.ToDoLists.Include("ToDoItems");
}

ObjectContext is an Entity Framework context, so we instruct EF to include nested ToDoItems when querying underlying database. If these properties are set, RIA Services will automatically include these into metadata transferred to the client ([Include] attribute on respective properties in CoprojectService.metadata.cs that we added in Step 2). Now rebuild the solution in order to have RIA Services recreate context on the client.

Next, point query creation in ToDoListsViewModel.LoadData from context.GetToDoListsQuery to context.GetToDoListsWithItemsQuery.

Finally, edit ToDoListsView and add the following control below the two TextBlocks in ItemTemplate of the ‘Lists’ control:

<ListBox ItemsSource="{Binding ToDoItems}"
				Margin="5,0,0,0" ScrollViewer.HorizontalScrollBarVisibility="Disabled">
	<ListBox.ItemTemplate>
		<DataTemplate>
			<StackPanel Orientation="Horizontal">
				<TextBlock Text="{Binding DueDate,StringFormat='\{0:d\}'}" 
						   FontWeight="Bold" Margin="0,0,5,0" />
				<TextBlock Text="{Binding Content}" />
			</StackPanel>
		</DataTemplate>
	</ListBox.ItemTemplate>
</ListBox>

Now you can run the application. The list will probably run off the screen, so let’s wrap Lists control with ScrollViewer:

<ScrollViewer Grid.Row="1" Style="{StaticResource ListsScrollViewerStyle}">
	<ItemsControl x:Name="Lists">
		...
	</ItemsControl>
</ScrollViewer>

That is all for this step. The application should look like that:

The first official release of T4RIA

Sun, 23 Jan 2011 19:54:34 GMT

by Petr Hošek

During the Rapid RIA development using .NET presentation, we have presented our own T4 template for WCF RIA Service called T4RIA. T4RIA is a T4 template that generates domain services, metadata and localization for WCF RIA Services from ADO.NET Entity Data Model.

We have promised to release T4RIA under open-source license. Today, I would like to announce the first official release which is part of WCF RIA Contrib project. This project is a collection of tools for WCF RIA Services and therefore presents a perfect home for T4RIA.

Usage

T4RIA supports WCF RIA Services 1.0, ADO.NET Entity Framework 4.0 and requires T4 Toolbox for its run.

To use it, simply download the official zip file and copy both T4RIA.tt and T4RIA.settings.t4 to the root of your WCF RIA Services web application. You might need to customize the settings in T4RIA.settings.t4 to fit your environment and conventions. Then, by running T4RIA.tt (simply save the file or use Chirpy extension), you will generate all the necessary files.

The code in generated files can then be customized to fit your needs e.g. add additional domain service operations, add additional model metadata, localize your model.

Resources

To find out more about T4RIA, please visit the official page. To ask questions or make suggestions regarding improvements and new functionality, please use the official discussion.

Developers wishing to help are welcomed to join the effort. Source code can be obtained on CodePlex. For T4 templates development support in Visual Studio 2010, I recommend Visual T4 editor from Clarius. To learn more about T4 as well as T4 Toolbox, its usage and advanced techniques, read Oleg Sych's blog which contains many useful information.

Coproject - a RIA Caliburn.Micro demo, part 8

Thu, 20 Jan 2011 08:28:20 GMT

by Augustin Šulc

In this part, we will create ToDoItem detail.

Context lifetime

The main question when considering lists and details is whether to share context among all screens or create a new context per screen. Both ways have their pros and cons and you will probably have to choose depending on the situation. But most likely, you will use both of them depending on the scope of entities.

Shared context

In this case, you would probably create a service in the application and all screens would access it to get and save data. It is useful when some entities are used across the whole application.

+ You can pass entities across application
+ No need to synchronize data when an entity gets updated – all parts of the application use the same entity.
+ Lower memory consumption if entities are shared across application.
+ Centralized data access.
- Entities stay in memory until detached or context disposed. So if you use a shared context to load hundreds of entites (e.g, in a grid) and do not detach them, memory consumption will be a problem.
- Even unsaved state of entities affect other parts of application (sharing the same entity).
- Harder saving. If you save whole context, you might save currently edited entities of other screens.
- Harder to maintain, especially with current memory leaks in Silverlight.

Context per screen

Every screen creates its own context and loads and saves data on its own. This is probably better for scenarios with editing detail screens and large lists/grids.

+ Easier to see consequences of changing entity properties.
+ Memory management. You can easily dispose of context (and thus all entities it loaded).
+ Easier saving. If you save context, you don’t save currently edited entities of other screens.
- Need to pass IDs across application and every screen must load the entity itself.
- Duplicate entities might exist in the application.
- Need to synchronize changes throughout application when entity is updated.
- Possible concurrency errors while saving.

ToDoItemViewModel

In Coproject, we will use Context per screen for ToDoItem entity. So, let’s start. I hope you have done all the steps described so far. If you haven’t, just download source code from Coproject Codeplex site. Note that source codes are branched for every tutorial part so you can start in any stage.

First of all, we should create an interface for ToDoItem detail. So, create interface ViewModels.Interfaces.IToDoItemEditor:

public interface IToDoItemEditor
{
	ToDoItem Item { get; }
	IEnumerable<IResult> Setup(int toDoItemID);
}

Then, add ToDoItemViewModel to ViewModels:

[Export(typeof(IToDoItemEditor))]
[PartCreationPolicy(CreationPolicy.NonShared)]
public class ToDoItemViewModel : Screen, IToDoItemEditor
{
	public ToDoItem Item { get; private set; }

	private CoprojectContext _context;

	public IEnumerable<IResult> Setup(int toDoItemID)
	{
			_context = new CoprojectContext();

			var dataResult = new LoadDataResult<ToDoItem>(
				_context,
				_context.GetToDoItemsQuery().Where(x => x.ToDoItemID == toDoItemID));
			yield return dataResult;

			Item = dataResult.Result.Entities.First();
			NotifyOfPropertyChange(() => Item);
	}
}

As you can see, the detail screen expects ToDoItemID and loads the proper entity itself. We want to store the context because we will use it for saving. Since there will be single instance of view model for every ToDoItem detail opened, we need it to be of a NonShared creation policy.

Now, let’s add the logic that will open the detail screen. There are ListBoxes in DataTeplates for every ToDoList in ToDoListsView so we could probably use the same trick as for modules to track the selected item, but as there are more ListBoxes, sharing SelectedItem would lead at least to a binding error. Moreover, I want to show how to use custom binding to events.

Firstly, open ToDoListsViewModel and change its base class from Screen to

Conductor<IToDoItemEditor>.Collection.OneActive

and add the following function to it:

public IEnumerable<IResult> OpenItemDetail(ToDoItem item)
{
	var editor = Items.FirstOrDefault(x => x.Item.ToDoItemID == item.ToDoItemID);
	if (editor == null)
	{
		editor = IoC.Get<IToDoItemEditor>();
		yield return editor.Setup(item.ToDoItemID).ToSequential();
	}

	ActivateItem(editor);
	yield break;
}

Finally, we need to execute this function in appropriate time. Open ToDoListsView and add new xmlns definition to the top of the file:

xmlns:cal="http://www.caliburnproject.org"

Now, we want to attach the OpenItemDetail function to the SelectionChanged event of the ListBox bound to ToDoItems. It the most fluent way, it would be done like this:

<ListBox ItemsSource="{Binding ToDoItems}" 
			cal:Message.Attach="[Event SelectionChanged] = [Action OpenItemDetail($this.SelectedItem)]" ...

But since SelectionChanged is the default event of ListBox, Action is the default behavior and SelectedItem is the default property of ListBox for binding, we can use this shortcut with the same result:

<ListBox ItemsSource="{Binding ToDoItems}" cal:Message.Attach="OpenItemDetail($this)"

Note the argument $this. This is a special C.M argument name. Other special words are $datacontext and $eventargs. Their meaning is exactly what you would expect from their names. You can read more about C.M actions here.

We also must add a place for the detail to be displayed in. So add this control below the ScrollViewer containing the Lists ItemsControl:

<ContentControl x:Name="ActiveItem" Grid.Column="1" Grid.Row="1" Margin="10,0,0,0" 
				HorizontalContentAlignment="Stretch" />

ToDoItemView

Next, we have to create the respective view. So add a new Silvelright User Control named ToDoItemView to Views. Add these two namespaces to it:

xmlns:dataForm="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls.Data.DataForm.Toolkit"
xmlns:controls="clr-namespace:System.Windows.Controls;assembly=System.Windows.Controls"

Then add this DataForm to LayoutGrid:

<dataForm:DataForm CurrentItem="{Binding Item}" HorizontalAlignment="Stretch">
	<StackPanel>
		<dataForm:DataField PropertyPath="DueDate">
			<controls:DatePicker SelectedDate="{Binding DueDate,Mode=TwoWay}" />
		</dataForm:DataField>
		<dataForm:DataField PropertyPath="Content">
			<TextBox Text="{Binding Content,Mode=TwoWay}" TextWrapping="Wrap" Height="auto" />
		</dataForm:DataField>
		<dataForm:DataField PropertyPath="User">
			<TextBlock Text="{Binding User.LastName}" />
		</dataForm:DataField>
	</StackPanel>
</dataForm:DataForm>

If you run the application, you will see this:

DataFields automatically added labels to proper places. You should note that there are no DataForm buttons. The reason is that in Assets/Custom.xaml, we have a default style that disables it. DataForm is still kind of a buggy control so I want to use as little of its features as possible.

Let me mention four DataForm bugs we could encounter in Coproject:

Even though Commit and Cancel buttons are disabled, they sometimes appear when changing edit mode.
When switching between DataForms, it sometimes hide the first label in it (DueDate).
When setting ReadOnly mode after editing a TextBox inside the DataForm, controls inside the DataForm are still enabled.
Switching to edit mode with BusyIndicator on the same page causes the indicator to constantly use 100% CPU.

All of them, except for the second can be avoided / fixed.

You probably noticed that User is still empty. The cause is that this nested entity is not included in ToDoItem. So open Services/CoProjectService.cs in the server project, find GetToDoItems() and edit it as follows:

return this.ObjectContext.ToDoItems.Include("User");

Build and run the application. Detail should be complete:

Coproject - a RIA Caliburn.Micro demo, part 7

Mon, 17 Jan 2011 17:17:03 GMT

by Augustin Šulc

In this part, we will add filtering to ToDo list and create several useful extension methods.

Extension methods

In the client project root, create a new static class called Extensions and put following functions into it:

public static bool IsNullOrWhiteSpace(this string value)
{
	return string.IsNullOrWhiteSpace(value);
}

public static string FormatWith(this string formatString, params object[] args)
{
	return string.Format(formatString, args);
}

public static IResult ToSequential(this IEnumerable<IResult> results)
{
	return new SequentialResult(results.GetEnumerator());
}

The last function is interesting. What it does is that it wraps a collection of IResults (remember coroutines from the last part?) into one result. This is particularly useful when you want to yield return a collection of results, maybe other coroutine function.

Filtering

To add filtering capabilities to our ToDoListView, we must add a textbox to it. In order to make look Coproject look nice, add some more styling, so replace LoadData button from the view with the following:

<Border Style="{StaticResource FilterPanelStyle}">
	<Grid>
		<Grid.ColumnDefinitions>
			<ColumnDefinition Width="*" />
			<ColumnDefinition Width="auto" />
		</Grid.ColumnDefinitions>

		<TextBox x:Name="Filter" Style="{StaticResource FilterTextBoxStyle}" />
		<Button x:Name="LoadData" Grid.Column="1" Content="Search" />
	</Grid>
</Border>

In fact, we just added a TextBox called Filter. Now, we have to make use of it. Update LoadData function in ToDoListsViewModel:

public IEnumerable<IResult> LoadData(string filter)
{
	CoprojectContext context = new CoprojectContext();
	EntityQuery<ToDoList> query = context.GetToDoListsWithItemsQuery().OrderByDescending(l => l.CreatedDate);

	if (!filter.IsNullOrWhiteSpace())
	{
		query = query.Where(x => x.Name.Contains(filter));
	}

	var result = new LoadDataResult<ToDoList>(context, query);
	yield return result;

	Lists = result.Result.Entities;
	NotifyOfPropertyChange(() => Lists);
}

As you can see, we only added parameter and filter query according to the parameter. Btw: this filter is transferred via RIA services and Entity Framework to database server and executed there (so the SQL statement is where Name like ‘%anyText%’). Using this way of filtering, you can easily chain multiple filter criteria. You probably won’t be surprised that the filter parameter is set by Caliburn.Micro according to the content of the TextBox called Filter.

Depending on database configuration, the comparison might be case sensitive or in-sensitive. If it is case sensitive, you will need to change the criteria to:

query = query.Where(x => x.Name.ToLower().Contains(filter.ToLower()));

That is all for this part about filtering.

Coproject - a RIA Caliburn.Micro demo, part 4

Thu, 13 Jan 2011 21:48:32 GMT

by Augustin Šulc

In this part, we will dig a little bit into Caliburn.Micro and create application modules.

Note: some information are intentionally simplified to make the whole concept easier to understand. Once you master it, go ahead and read more detailed articles.

Screens

As I indicated in the last part, we will describe Coproject structure and hierarchy of application screens via ViewModels. And then, we will let C.M to take care of wiring it to views and showing it to the user. You will see that this approach helps keep the solution clean and easy to manage.

For this purpose, Caliburn.Micro has several useful classes already prepared.

Screen

Screen is a simple base class for all ViewModels. Not that it already implements INotifyPropertysChanged, it also contains virtual functions that you can use in scenario of nested ViewModels:

OnInitialize
OnActivate
OnDeactivate
TryClose

Conductor

Conductors are basically screens with other nested screens. Therefore, their additional functions are like:

ActivateItem
DeactivateItem
GetChildren

Conductor.Collection.OneActive

To save you as much time as possible, there is an even more specific base class for you to use. It contains property Items and helps you to manage collection of nested viewmodels.

In Coproject, we will this third base class as Shell contains a collection od Modules and, for example, ToDoLists module will contain a collection of opened ToDoItem details.

As I don’t want to duplicate this great article, you should read it if you want to get more information about screens in C.M.

Modules

Ok, let’s use all the screens and conductors and write some code!

First of all, we should create interface for modules (as seen there – Home, Messages, To do, and Milestones will be modules of Coproject). Create interface ViewModels.Interfaces.IModule as follows:

namespace Coproject.ViewModels.Interfaces
{
	public interface IModule
	{
		string Description { get; }
	}
}

Then, under ViewModels, create HomeViewModel:

[Export(typeof(IModule))]
public class HomeViewModel : Screen, IModule
{
	public string Description { get; private set; }

	public HomeViewModel()
	{
		DisplayName = "Home";
		Description = "Project overview & activity"; 
	}
}

As you can see, no magic here. We just set some text properties and notifies MEF that this is a module. The DisplayName property is already implemented in Screen.

Do the same for other modules (don't forget to export):

[Class name] - [DisplayName] - [Description]
MessagesViewModel - Messages - All messages
ToDoListsViewModel - To Do - To-do lists
MilestonesViewModel - Milestones - string.Format("Milestones (today is {0:D})", DateTime.Today)

If you’ve done it right, your Solution Explorer should look like this:

Next, we need to import those exported modules into the shell.

Change ShellViewModel’s base class from Screen to

public class ShellViewModel : Conductor<IModule>.Collection.OneActive, IShell

And add this constructor:

[ImportingConstructor]
public ShellViewModel([ImportMany]IEnumerable<IModule> modules)
{
	Items.AddRange(modules);
}

That is all we need to do to make MEF import all IModule implementations it has into our shell.

Put a breakpoint into the constructor and run debugging to see that it works. Note that we didn’t listed or even mentioned modules anywhere in the application. So if you want to add a new module, just create ViewModel and let it export IModule. That’s all! You can read more about importing in MEF here.

Tips for Silverlight debugging

Sometimes people have difficulties to debug Silverlight applications. Let me give you a hint to make it easy. The key thing is to understand that there are two applications (processes) you might want to debug – server and client. If you typically hit F5 sometimes only server gets debugged. That’s why I do it another way:

1. At the beginning, Start Without Debugging:

This will run the server and open the client in your default browser. Because of easier finding of the right process, I close the browser and open client URL in Internet Explorer, since I don’t use it for other tasks (you will see in a minute). You don’t have to start it again as long as the ASP.NET Development Server is running.

2. Then, before you want to debug your application, you just need to build the solution (in larger applications, rebuilding of the affected project should be enough).

3. Attach to Process (or press CTRL+ALT+P)

4. If you want to debug server, attach to process called WebDev.WebServer40.EXE (press keys w,e,b and the listbox will find it for you):

If you want to debug client, attach to process of your browser (make sure to choose the process of Type Silverlight!). In my case, it is iexplore.exe:

So, if you want to debug your client app opened in the only Internet Explorer instance running, press: CTRL+ALT+P, i, e, ENTER. Just don’t forget to build the solution and refresh your browser (so that the latest version of client gets loaded).

Show menu

So, modules are loaded into shell but nothing is shown in the application – we have to update ShellView to show nested modules.

Open ShellView.xaml and add the following ListBox just below the TextBlock with text ‘Coproject’:

<ListBox x:Name="Items" Style="{StaticResource NavigationMenuStyle}">
	<ListBox.ItemTemplate>
		<DataTemplate>
			<TextBlock Text="{Binding DisplayName}" />
		</DataTemplate>
	</ListBox.ItemTemplate>
	<ListBox.ItemsPanel>
		<ItemsPanelTemplate>
			<StackPanel Orientation="Horizontal" />
		</ItemsPanelTemplate>
	</ListBox.ItemsPanel>
</ListBox>

Tip: You can press CTRL+K, D to have Visual Studio reformat the code.

This is just a ListBox that shows DisplayName of some items it is bound to. But if you run the application, you will see that it is already bound to the Items property of ShellViewModel:

This is caused by convention imposed by Caliburn.Micro – because the ListBox is called ‘Items’, C.M tries to bind its ItemsSource property to property Items of respective ViewModel. And since ShellViewModel is a conductor with collection of child modules, it has one. Of course, you could bind ItemsSource by hand, C.M would not overwrite it.

Show module content

Below the Items ListBox, add the following controls:

<TextBlock x:Name="ActiveItem_Description" Style="{StaticResource CurrentPageTitleStyle}" />
<ContentControl x:Name="ActiveItem" Style="{StaticResource MainContentStyle}" />

As you can guess, the first will show Description of currently selected module, the second one will show its content. But if you run the application, you will see that it works right away.

This is caused by Items ListBox again. There is another convention in C.M – if a control supports SelectedItem property, C.M will try to add Active, Current, or Selected to its singularized name and check whether there is respective property in ViewModel. And if successful, it will create a TwoWay binding. Conductors in C.M have ActiveItem property.

This binding over naming conventions has one flaw – it does not work in design time, co if you want to have some data bound to the controls on design time, you will have to use standard {Binding} syntax.

View location

If you select a module, you might see 'Coproject,Views.MessagesView not found’. It is a C.M error message that it could not locate proper view for your ViewModel. This convention works as that to get View name, it just removes ‘Model’ from the full name of ViewModel. Of course, you can customize this logic, but it is usually sufficient.

Although it might not seem like, it is very flexible. You can have a simple structure like we do:
/ViewModels/MessagesViewModel + /Views/MessagesView

But you can also add structure for modules:
/MessagesModule/ViewModels/ListViewModel + /MessagesModule/Views/ListView
or
/ViewModels/MessagesModule/ListViewModel + /Views/MessagesModule/ListView

Get the source

You can download Coproject source codes from its Codeplex site. Feel free to experiment!

That is all for this part.

Coproject - a RIA Caliburn.Micro demo, part 5

Thu, 13 Jan 2011 21:13:38 GMT

by Augustin Šulc

In this part, we will add some module metadata. Note that you can get the most recent Coproject source codes from its Codeplex site.

Metadata

As you probably noticed, modules are not loaded into shell in any specified order. And since we don’t want the modules be in arbitrary order, we need to add some metadata. You can read more about MEF metadata here.

The easiest way is to use ExportMetadataAttribute. We would update HomeViewModel as:

[Export(typeof(IModule))]
[ExportMetadata("Order", 10)]
public class HomeViewModel : Screen, IModule

and the other ViewModels in the same manner. Next, must update ShellViewModel constructor. Instead of IModule directly, we will request Lazy<IModule, IModuleMetadata> from MEF. This will make MEF to provide lazy reference to requested instance and also metadata of type IModuleMetadata. You might read an introduction to Lazy here.

Let’s create IModuleMetadata in new folder /Framework/:

namespace Coproject.Framework
{
	public interface IModuleMetadata
	{
		int Order { get; }
	}
}

Finally, ShellViewModel’s constructor:

[ImportingConstructor]
public ShellViewModel([ImportMany]IEnumerable<Lazy<IModule, IModuleMetadata>> moduleHandles)
{
	var modules = from h in moduleHandles orderby h.Metadata.Order select h.Value;
	Items.AddRange(modules);
}

The code should be self-describing. Now, run the application. You may experiment with order numbers and see that the order in application menu changes respectively.

Strongly typed metadata

Although this solution works, you probably don’t like the idea of writing magic strings like “Order”. So we should make these metadata strongly typed. To do this, add new class ExportModuleAttribute to the Framework folder. Application structure should look like this:

Add this implementation of the created class:

[MetadataAttribute]
[AttributeUsage(AttributeTargets.Class)]
public class ExportModuleAttribute : ExportAttribute, IModuleMetadata
{
	public int Order { get; private set; }

	public ExportModuleAttribute(int order)
		: base(typeof(IModule))
	{
		Order = order;
	}
}

As you can see, we simply extend the original ExportAttribute to accept order integer. In this case, we can add default export type (IModule). The first attribute [MetadataAttribute] is very important because it tells MEF to also load metadata from ExportModuleAttribute. Finally, we can merge the two attributes on each module viewmodel:

[Export(typeof(IModule))]
[ExportMetadata("Order", 10)]

into one:

[ExportModule(10)]
public class HomeViewModel : Screen, IModule

Do this for all module view models and run the application.

PartCreationPolicy

Talking about MEF exports, you might wonder what happens when you import a component more than once – will MEF provide you the same instance or will it create a new one? The answer is: It depends on configuration. You can specify this behavior on the places. Either on export:

[ExportModule(10)]
[PartCreationPolicy(CreationPolicy.NonShared)]
public class HomeViewModel : Screen, IModule

Or on import:

[Import(typeof(IShell), RequiredCreationPolicy=CreationPolicy.Shared)]
public IShell Shell { get; set; }

CreationPolicy enum has three options:
Shared – MEF will return always the same instance (singleton pattern)
NonShared – MEF will always create a new instance
Any – not specified, depends on the other side of contract (export/import). This is default and if not set to other, this will act as Shared by default.

You can read more about this topic here. I suggest reading whole series MEF for Beginner or MEF Programming Guide.