A couple of the many projects that I took up last year were the creation of a couple of aspect oriented programming (AOP) tools. What is Aspect Oriented Programming? Not wanting to start from scratch, I did a quick internet search and found the following article which seems to give an adequate explanation of the subject. Feel free to skim through it and come back. I think the obedient poodle example is a unique approach to explaining the topic.

http://msdn.microsoft.com/en-us/library/aa288717(v=vs.71).aspx

There are many ways to approach AOP ranging from dependency interception (most common) to IL injection, which is possible with the Postsharp framework. I hope to briefly touch on some of the different approaches here as I will talk about these as I go forward and write future posts about my AOP tools. 

Dependency Interception

Dependency interception utilizes dependency injection and dynamic code generation to “weave” in our “aspects”. With dependency …

For the last month or so, I have been collaborating with an associate of mine, Irene Vidyanti of the University of Southern California on a project utilizing the Open mHealth system. Open mHealth is a framework for creating mobile health solutions which involve collecting patient/participant data through a smart phone, storing the data in the web and monitoring the data through a web interface. 

Open mHealth in collaboration with the UCLA CENS project have developed a reference application called ohmage. It comes in several parts; ohmagePhone, an Android client; ohmageServer, a data tier written in Java and ohmageFrontEnd, a web interface written with the Google Web Tools (GWT). 

Coming from a .net background, I found the process of setting up my environment and working with packages to be quite involved, so I have created a step by step manual to help myself out and I thought it would be helpful if I were to share it with others trying to do the same. You can find that …

A Brief Introduction

As per my last post An Analysis of Content Handlers in the Orchard Project, I have invented an alternative to the Content Handler, the Content Handler Registrar (name subject to change). Like Content Handlers, Content Handler Registrars are used to create handlers and associate them with content items and parts. The difference here is that Content Handler Registrars provide an application programing interface (API) that allows for some pretty keen infrastructure improvements as the application grows (Referring to aforementioned article and other yet to be documented changes.)

But for those afraid of change, fear not; anything that can be done with handlers can still be done with registrars. The main difference to developers is that Content Handlers live in the request scope, whereas Content Handler Requests are shell scoped. In many ways, Registrars are Content Handler factories.

The methods of Content Handler Registrar

As previously mentioned, I aimed to do …

Over the past month I have gotten intimately familiar with the Orchard project. One thing that jumped out at me was how handlers are associated with content items. In short, they are not. Every enabled content-handler is given the opportunity to handle every content-handler-method for every content-item. When an Orchard event is invoked, it is the responsibility of the handler to look at the content item and ask the question, "can I handle this", if not return. The code often looks like this:

void IContentStorageFilter.Activated(ActivatedContentContext context)

{

if (context.ContentItem.Is<tpart>())

Activated(context, context.ContentItem.As<tpart>());

}

A little context may be in order.

The IContentHandler interface has a plethora of methods which can be categorized into four groups; activating, storage, template and import/export. Activating has one method which generally is used to weld parts onto items. Storage has several methods …

This may sound like common sense, but do you know why? 

Last week, I was watching a popular training video online regarding the repository pattern and data contexts. In the video, the author demonstrates a piece of code that exposes the data context in such a way that if his repository classes were used in some other application, a single instance of data context may end up being used in multiple using blocks. 

So I wrote up an explanation of the oversight and sent it off to the author, Dan Wahlin. He told me that it was as designed and that the data context was to be "available even if it was previously disposed."

So shocked was I that I scoured the internet for an explanation as to why this is wrong, but I came up bust. In the end, I was able to convince him to change it, but it was an uphill battle. I find that this is the type of rubish code that readers see and unfortunately take as gospil. 

But for many developers, dispose is somewhat of a magical device. It …