Revolutionary Networks

It’s late and I should be asleep right now but I figured I’d throw together a quick update (please forgive whatever typos and horrible grammatical errors you may find).:

We are moving our blog to be hosted through Rex’s hosting. We will be revamping this address to introduce more of an aggregation area for the blogs of various members that are active in technical writing.

The project that I am currently on at work is quite intensive and I will be begin posting a several articles on various topics ranging from code generation to new ways of leveraging role-base security management.

In other news, I have begun a discovery phase for a new configuration tool. After the blogs get moved and I have my own setup at blogs.rev-net.com/jmarnold I will begin posting the details on this project and begin requesting as much feedback as possible.

Dave has posted a great summary of everything that I had planned to say for roadblocks that we have faced on the Zee project. Bridge Academy Charter High School, the school that I have grown to love from my time attending and teaching there, might be closing down for good.

There is hope for the school as they may appeal their recent rejection for the renewal of their charter. The appeal is a long and painful process - one that I will most likely be deeply involved in as I am with any major event with the school. I will be posting updates on this whenever possible.  In the meantime, the team is on an official break for the holidays (although some of us will still be working on DekiScript.NET).

We’ll be gearing up next year for some wonderful projects.

Visual Studio 2008 and the .NET Framework 3.5 were officially release today. See ScottGu’s post for more information.

The team will be ordering their MSDN subscription VERY soon.

Scott Guthrie posted some fantastic links relating to the upcoming ASP.NET MVC Framework and other related items (including an interesting article on enabling Dependency Injection into your application via Spring.Net).

This is of particular interest to the Zee team as we should seriously consider making use of the framework.

Greetings,

I’ve been having a lot of fun playing catch up after the recent server upgrades (courtesy of DesertGate Internet). The new setup had been prototyped several times on local vmware images so the overall configuration went over quite smoothly. I’m now working on polishing the use of a single username/password for all members as the majority of the applications we use support LDAP authentication/authorization.

Unfortunately, we did run into a few problems (some of which have not yet been resolved) with SQL Server configurations and other various issues. We are pushing back the initial deadline for the Mashup prototype implementation and will have more information regarding this very soon.

Sorry for the delays!

The team has been working with Steve Bjorg from MindTouch on creating a .NET implementation of DekiScript. We had a strong start but I took some time off this weekend (as did the rest of the team) for Paul’s wedding. GREAT weekend and some much needed time off.

However, we are back and I am getting to work. We’re tentatively scheduled for a prototype by November 16th. Expect some source code and an accompanying blog entry.

A new prototype of the Mashup framework, utilizing the new improved function builder,  has been made available online:

http://dev.rev-net.com/Mashups/ 

I’m looking forward to hearing some feedback!

Now, let’s move back to the problem that was mentioned at the end of the first part of this series: allowing for more than just native data types. This was a large area of concern as we would obviously be limiting the power of any library. Just imagine:


StringBuilder builder = new StringBuilder();
builder.Append(“some html tag”);
return builder.ToString();

The thought of that made me absolutely cringe, as it rightfully should. Not only does this potentially create performance and rendering problems, it also makes it very difficult for libraries to create any worthwhile affects on the User Interface (e.g. AJAX). For every library function call, you would be displaying the same HTML – potentially having to include multiple JavaScript files with each call.

The simple solution for this problem: restrict return types to native data types, as well as any derivations of System.Web.WebControl. Now we just had to consider how to implement this within a reusable WebControl of our own.

The approach to this control was relatively simple: using a regular expression,

1. Find all matches of the syntax {{ library.Function(“some argument”) }}
2. For each match:
a. Invoke the function
b. If the function returns a WebControl, add the WebControl; otherwise add the result as a LiteralControl.
c. Add any surrounding text as a LiteralControl.

This is handled by the Text property of the control (you may also bind to this property).

We have successfully created sample libraries creating a Virtual Earth control, image manipulation, and other complex examples.

At the time of this writing, the team is focusing their efforts on finalizing the Sql Server 2005 provider, creating a web.config provider, and writing an extension to the FCKEditor WYSIWYG editor to easily build function calls without prior knowledge of the syntax. These features will be available for the beta release (tentatively schedule for November 1, 2007.

The prototype was a success, in its own right. We had successfully parsed out the interim syntax definition and dynamically invoked the respective library methods. We had hard-coded the library prefix mappings and the Custom Attributes were pretty rough but it was a step forward.

There were now two areas of concern:

1. Designing an extensible prefix mapping architecture
2. Allowing for more than just native data types as return types.

For this part, I will be discussing the extensible prefix mapping architecture.

Prefix Mapping

By prefix mapping, I mean that somewhere the framework needs to know that the prefix “sampleLibrary” maps to the type: RevNet.Web.Mashup.SampleLibrary. We knew that the mapping system had to be flexible, so the provider pattern was chosen. At the time of this writing, a SQL Server 2005 provider is provided by default (with plans to provide a web.config provider as well).

The provider can then be specified in the configuration file utilizing the RevNet.Web.Mashup.Configuration.MashupLibraryProviderConfigurationSection, class for programmatic support, and defining a section with the name ‘MashupLibrary’ in the configSections element. The following an example utilizing the SqlServer provider: Sample Mashup Config

Note: A custom provider simply has to derive from: RevNet.Web.Mashup.Configuration.MashupLibraryProvider.

The provider design was relatively simple to implement. It also illuminated the information that would be of interest to anyone utilizing the API – we then created classes to provide metadata about the libraries. This metadata is essentially the documentation available for libraries and their respective functions.

The IMashupLibrary interface

The RevNet.Web.Mashup.IMashupLibrary interface simply provides information regarding a Mashup Library (e.g. author name). We had originally considered possibly allowing for installation actions to occur when adding a library – however, given the requirement that the assembly be located in a reachable location by the application, any installation requirements should be handled while installing the library assembly.

In order to expose any method as a Mashup Library function, it must be marked by a MashupLibraryFunctionAttribute.

The MashupLibrary API

The RevNet.Web.Mashup.MashupLibrary class exposes methods and properties to access the default provider, as well as the collection of all configured providers. It also has direct methods to utilize the default provider (e.g. MashupLibrary.GetAllLibraries() calls GetAllLibraries() on the default provider). It also provides a caching mechanism of the available libraries (with the ability to refresh the cache as well).

Now that the API was in place, we needed to create a reusable way of displaying the data on a web-app. The easiest way we could think of doing this is by creating a custom control: MashupDisplayControl.

Hybrid web-applications have been popping up all over the place. We’ve seen massive strides in the progression of the philosophies that sparked creative minds to innovate upon the existing technologies within the wave of “Web 2.0″ and the next generation of the web. These strides have resulted in the creation of aggregating applications such as Google Reader, and Wikis such as QEDWiki and Deki Wiki. The approach taken by these two Wiki applications are embodiments of yet another popular buzz word: Mashups. Both QEDWiki and Deki Wiki allow the User to pull information from multiple sources onto a single page. While this may be fantastic in its own right, the members of RevNet began to feel that it was slightly restrictive. Allow me to elaborate. Rex and I began critiquing both of these applications. After some time, we asked ourselves: “should information be able to be retrieved from multiple sources?” Yes, we strongly believed that this is an important ability for Users of any application to have. This is when we realized what was missing. There was nothing wrong with enabling this within a Wiki application but we believed that this should be enabled for any application anywhere - not just in the context of a single wiki page. Moreover, these were only available in PHP. This is what fueled the start of our very own .NET-based Mashup Framework.

The First Iteration

We began sketching out details in a brainstorming discussion:

Meet the Widgets

I am envisioning the ability to utilize the mashup concept in all areas of the collaboration suite. If a formal syntax is standardized, then it can be used all across the application. This would allow a widget-based approach for all features.

Consider the following syntax snippet* as an example:

In {{ popupUserProfileSummary("joshua.arnold@rev-net.com", "Joshua Arnold's") }} latest {{ popupBlogPostSummary("1", "blog post") }}

This would appear as:

In Joshua Arnold’s latest blog post, he mentions that…

with “Joshua Arnold” and “blog post” having dynamic popups appear on a mouseover event displaying a Profile summary and Blog Post summary, respectively. This could appear in a forum post, blog entry, calendar event, or ANYWHERE. Moreover, we should allow for other services as well - windows live, google, flickr, etc…

* Syntax snippet is just a pseudo syntax example and is not meant to reflect the actual standard.

Automating the Widgets

Eventually applications will be able to associate the text, “Joshua Arnold” to a specific user, and be able to automatically convert the text “Joshua Arnold” to the appropriate widget syntax, in this case being: {{ popupUserProfileSummary("joshua.arnold@rev-net.com", "Joshua Arnold") }} It would also be able keep the original text and not convert it to a widget each time it occurs.

Controlling formatting

Definitions: A “library” is a set of functions that are used to format information from internal/external sources The “Core” library will be written abstractly and have a default implementation. This will provide the standard formatting techniques for everything. It will be written abstractly to allow other implementations to be written and used to facilitate layout maintenance.

As with any new idea, we felt that the first step should be to create a simple prototype. I began working on a very rough preliminary architecture - attempting to plan for the ability to have libraries dynamically defined and loaded. We began with some rough Custom attributes to decorate classes and methods to be pulled through reflection and map correctly to function calls. Essentially, we would register a “prefix” (or alias) with a library class and any function calls made from that prefix would be invoked from that class - requiring that the function names matched their respective method names. The architecture had potential but the first implementation was slightly painful. Nevertheless, we pushed forward to begin working on the syntax parser. Rex wrote the parser to allow for function nestings as well: {{ myLibrary.FunctionName(myLibrary.FunctionName()) }}. We hosted it in a simple console application to test the invocation of the functions and it worked rather well, to our surprise. I started noticing the restrictions already: only the native .NET types (e.g. string, int) could be handled. If you wanted to return “Hello World,” it would work just fine. However, any html to be rendered would have to be created with the use of a StringBuilder or another similar approach. Obviously, this just wasn’t an option.