your .net design team

ODNC Luncheon Seminar Series Presents: Test Driven Design (aRealWorldExample)

noreply@blogger.com (Charles) — Wed, 18 Nov 2009 20:50:00 +0000

The Ottawa .NET Community is please to invite you to a luncheon presentation on "Test Driven Design (aRealWorldExample)". Test Driven Design is a powerful development paradigm and there's nothing like a simple "Real World Example" to help you wrap your head around it. The presentation is scheduled for Wednesday, November 18, 2009 at 12:00 noon. Bring your lunch and see how you can use Test Driven Design in your next project.

Test Driven Design (aRealWorldExample)

This session illustrates Test Driven Design in light of a real world scenario. The scenario involves a legacy class object that needs to be upgraded to meet a new user requirement. You will be walked through the process of creating the test cases that will be used to insure that the user requirement is fully met. You will then see how the solution is developed around these test cases. Note that LINQ functionality will be included in the solution and you will have the added benefit of seeing this technology in action. At the end of this session you will have a better understanding of how to integrate Test Driven Design (and LINQ) into your next project.

About Charles Wiebe

Charles Wiebe is the co-founder of TrackerRealm, a company that specializes in workflow design. He is a Microsoft .NET software architect/designer for Windows Forms and ASP.NET solutions. Charles' expertise lies in the Application Layer, working with Web Parts, and GUI development. He is currently responsible for the User Interface components used in COR, a Content Management System and Jetfire, a workflow domain specific language. Charles is an active member of Ottawa .Net Community; he has coordinated the last 2 Ottawa Code Camps and has played a major role in several ODNC Study Groups. Charles will also be one of the presenters at this year's Microsoft Tech Days Tour taking place in Ottawa next month.

The zip file contains the Visual Studio 2008 solution and PowerPoint used in the presentation.

Presentation covers:

The objective of upgrading the legacy filter class is to migrate the 'prototype' design done in 2007 and meeting with increasing success in market to a mass deployed component. This means expanding the boundary conditions and improving the test methodology.
Test Driven Development shows how to create a test case, followed by writing the code to "make the test pass".
The legacy Filter class is upgraded to use Generic FindAll and Find methods with anonymous methods
New method is added to Filter class as an extension method – good technique to follow when you want to add code in sand-box and test before submitting to release stream.
Rhino.Mocks used to improve testing methodology.

Jetfire – Maybe we should have called it DC#

noreply@blogger.com (John Hansen) — Wed, 29 Apr 2009 20:22:00 +0000

We were joking around the other day trying to describe Jetfire when we hit upon DC#, for dynamic C#. Now to be fair C# does have dynamic attributes (especially C# 4.0); however most of C# functionality is determined at compile time. Generally to be considered a dynamic language such as IronRuby, or IronPython, most of a language's functionality should be determined at run time. Dynamic languages do sacrifice some performance for increased application flexibility, although some would argue that in real applications there is no sacrifice in performance.

We say Jetfire, at least in jest, should be called DC# because its syntax comes directly from C# and it is a dynamic language. Jetfire has the following dynamic attributes

Dynamic typing
Dynamic Access Modifiers
Code can be created and executed 'on the fly'

Jetfire Links

Related Articles

Modeling a Workflow in Software

noreply@blogger.com (John Hansen) — Fri, 17 Apr 2009 16:10:00 +0000

On the surface modeling a workflow in software might seem like a very straight forward task.

After all according to wikipedia "A workflow is a depiction of a sequence of operations…". This sounds like a great match for a computer program modeling the workflow.

You could then use the software workflow to

Guide you through the workflow process.
Perform actions through the software such as send email, operate equipment or perform a computational process such as adjust a photograph.
Facilitate approvals
Record activity especially when actions were taken.
Roll up the results and status in other documents

However there are issues (you didn't think it could be quite this simple). All of these issues are resolvable, but add an extra layer complexity to modeling a workflow in software.

Workflow programs must be able to operate for days, weeks or even years. The implication is that the workflow program must automatically preserve its status. The status must be automatically restored if the computer is restarted.
Workflows go through states when the operations occur. Operations, or commands, need to work only in the appropriate state. For example a "Complete" command may only valid once the workflow is 'started'.
Workflows are performed by more than one person. This means that the workflow must be able to support simultaneous users working on different computers or devices.
Workflows need to be shared, but also be protected from incorrect usage. For an expense workflow the user may need to be a manager to approve it. The workflow program needs support different roles for different users.
Not everyone who uses a workflow sees the same data. For example an approver's comments may need to be hidden from the applicant.
Workflows change over time. For example an 'approval' process may change while there are requests in the system. The workflow software must be able to handle 'grandfathering' the process for requests already in the system or optionally support upgrading them.
Workflow programs need to be simple to design and build.

This is rational behind the dynamic language
Jetfire. Jetfire is domain specific language that handles all these issues with ease. Applications can be built quickly. Application code isn't obscured by reams of infrastructure code. With Jetfire the designer of workflow software can concentrate on the application, not the infrastructure. All this makes the workflow program more reliable and much easier to maintain.

Links

Related Articles

Form Maker debut

noreply@blogger.com (Charles) — Sun, 22 Mar 2009 14:53:00 +0000

We have been asked a number of times "where is the Jetfire visual designer"? Our attention was aimed at getting the programmatic model correct. We are now starting to deliver purpose-built visual designers. Why multiple designers?

The objective of Jetfire visual designers is to:

Provide simple GUI's for building applications
Take the 'programming' out of 'application programming'
Easily deploy applications
Provide a one-step process to writing and deploying applications

Figure 1: Form Maker in design mode

Our first release for purpose-built visual designers includes Form Maker. It is a simple first step, but designed to be practical. The key features of Form Maker include:

Add one or more properties
Reorder properties
Identify the property type (text, date, duration, integer, and more)
Build applications based on previous programs
Form validation
One-click deployment

Figure 2: Form Maker in layout mode

Click the 'Show Form Layout' link and Form Maker displays how the Form is displayed to a user.

The differentiator of Form Maker is one-click deployment. The user creates an application and with one click adds the application to the Jetfire ecosystem – ready for use.

Figure 3: Property types

Figure 3 shows the types of properties that can be added to a form in Release 1.

'UnknownType is displayed when reviewing an existing program and the property type is unknown, e.g. an enumeration.

Supporting Quality Processes

noreply@blogger.com (Charles) — Sun, 22 Mar 2009 14:51:00 +0000

In a previous blog, we stated that the "objective of Jetfire is to simplify the workflow creation/modification process so that Power Users can build workflows and upgrade them".

In the early 90's, I worked for a large corporation that implemented ISO-9001. To be compliant with ISO-9001, each department has to show that they followed their processes. The easiest process to show compliance was the software submission process, because it was tooled. Tracking the paper processes required continuous manual intervention.

Continuous Improvement is the name of the game to improve product quality. Software that naturally reinforces the rules is required to support quality processes. Tooling with the ability to easily upgrade is required. With this back-drop, let's look at Jetfire.

New Jetfire workflows are easily added, without upgrading system software.
Jetfire workflows should easily up-version.
Light-weight workflow ecosystem

Jetfire programs are built on an object oriented ecosystem that executes Jetfire code interpretively. This approach allows Jetfire workflows to be easily uploaded, without the need to upgrade the system software.

To up-version code, version is included in every object in the system. New code creates a new version of a Workflow Class, which are related to previous versions of the named workflow class. New and previous versions of the Workflow Class are accessible with the preferred class to be instantiated being the current version.

Finally, the small size of the Jetfire ecosystem provides a compact environment that is targeted at building applications.

Writing programs for the workflow domain

noreply@blogger.com (Charles) — Sun, 22 Mar 2009 14:33:00 +0000

Jetfire is a DSL (domain specific language). So what domain are we talking about?

When we started Jetfire, the goal was to create a language that makes workflows easy to write. I can say without reservation that we have achieved that goal. Let's review the differences between Jetfire and C#.

Jetfire is based on C#, so that programmers can easily write it.
The keyword 'workflow' replaces 'class'. 'workflow' is used to activate first class support for workflow constructs.
Dynamic Access Modifiers are used to make class members public/private depending on who is using the class.

The Jetfire domain specific language incorporates first class support for workflow constructs.

Let's review some examples of how Jetfire simplifies writing workflows.

Example 1: States – Some workflows are state driven. Jetfire Methods include a new type of method: the state method. 'enterstate' is a keyword used to promote the workflow into the specified state.

public workflow MyFlow
{

// 'Start' state

Start()

{

// place code to be executed when the state is entered.

}

// constructor

public MyFlow()

{

// put the workflow into the Start state

enterstate Start()

}

Example 2: Dynamic Access Modifier example using states – the AddData method is public when the workflow is in the Start state. Otherwise, the AddData method is private.

private ArrayList dataList = new ArrayList();

// method 'AddData' has a dynamic access modifier

public void AddData(string data) : states(Start)

{

this.dataList.Add(data);

}

Example 3: Dynamic Access Modifier example using access – the DoSomething method is public if the logged in user has the Role 'Approver'. Otherwise, the DoSomething method is private.

public void DoSomething() : access("Approver")
{
...
}

These are some powerful examples how a domain specific language can simplify writing workflows.

Why a Domain Specific Language is better than a Framework!

noreply@blogger.com (John Hansen) — Tue, 17 Mar 2009 18:20:00 +0000

If you are a programmer you use frameworks. Some frameworks such as a collection framework are almost indistinguishable from the language. I know in my C# code I find almost all my classes contain either 'List' or 'Dictionary'.

Other frameworks such as ADO .net are very large and require quite a bit of time learn. They provide an indispensible service to your application but are very difficult to learn and use. The application code that employs the framework is almost unintelligible. Adding more comments or the more judicious use of variable names seems to have no effect on making the code look better. The problem is that most frameworks need to expose details of internal concepts to application as numerous tunable parameters and properties. This is required since a typical framework has no other mechanism of inferring intent.

The need for the framework to have numerous tunable parameters and properties (lazy loading, concurrency issues, etc) compounds usage problems. This is because in order to be used correctly they need to be understood. Subtle errors in understanding a concept of a framework produces either subtle errors in the application or causes the application not to run a peak performance.

Using a domain specific language addresses a number of these problems.

A domain specific language after all is just another language. Most languages can be learned in a few hours to a few days. When we wrote Jetfire we started with C# syntax adding few specific features. A programmer's investment in understanding languages could be reused. The additional features in Jetfire, for example, are consistent with the C# programming paradigm.
The code in a DSL is designed to be understandable and compact. Unlike working with a framework where hundreds of lines of code are required just to provide initialization, working with a DSL typically requires very little code.
When you write code in a DSL the language is able to understand the programmer's intent and therefore is able to hide most of the complexity. For example Jetfire understands that variables should be saved to persistent storage. Therefore Jetfire does this automatically without the application programmer writing extra code. Jetfire also knows if a variable is used inside a method that it doesn't need to be saved because that variable is only valid as long the method is executing.

Policy based Management with Jetfire

noreply@blogger.com (John Hansen) — Wed, 12 Nov 2008 16:38:00 +0000

We have started an exciting new phase of Jetfire development. Our next release is planned to support both a rules engine and transparent access to .net objects.

Using Jetfire source code a rule will look like the following:

It needs to be mentioned that Jetfire code is not what the rule writer or rule user would see. They would, in all likelihood, see some sort of form based interface. Using Jetfire it extremely easy to write such an interface since it supports programmatically accessing the code for the rule. The Jetfire code is presented here for understandability.

How the rule code operates is that when an event occurs, in the above example when a 'property' is changed in any 'MailStats' object, parameters are generated for the rule. In the example above the 'mailStats' and 'user' parameters are extracted from the event parameters. Think of this as automatic method overloading. These parameters provide a context for the rule and naturally if a parameter was requested that didn't exist in the event object it would cause a coding error.

Any legitimate code is allowed within the 'condition', including calling other rules. Calling methods within a 'condition' is not allowed unless the method is deemed to be 'rule safe'. In other words helper methods are allowed such as converting from a string to integer. This allows the compiler to check the integrity of the rule 'condition' and insure that the 'when' events are sufficient.

Jetfire Policy Based Management Advantages

Jetfire rules are easy to code and understand. The built-in integrity features makes the rules very robust.
The ability to access .net objects means that Jetfire Rules can operate with existing data. That is there is no need to convert data. The data required for a Rule is in a database it can be easily accessed using a .net Framework such as ADO.
Since Jetfire is interpreted rules can be changed without recompilation or binding.
Code changes will not impact existing working rules since Jetfire includes automatic code version control.
Since Jetfire is a highly reflective language it is easy to present the user with friendly forms based rule system.

Navigating in Visual Studio

noreply@blogger.com (SW) — Wed, 12 Nov 2008 01:09:00 +0000

I work with Solutions that contain hundreds of files. Navigating through many levels of directories can be a cumbersome task, especially when you are not the author of the Solution. In university, using Visual Studio for assignments was never a problem, since you get to architect the structure of the Solution.

Working with a larger Solution, I was constantly performing Searches on desired keywords. This worked, but very time consuming. I needed to speed things up to increase my productivity. I wanted a mechanism to remember where sections of code are located within the Solution. Here are a couple of tips that can help:

Tip #1: Using Bookmarks

Visual Studio has a Bookmarks feature that allows you to save a specific line in a specific file. They work exactly like bookmarks used in web browsers. Simply press Ctl+k and Ctl+k to save the line as a bookmark. Note that you need to do Ctl+k twice, as I presume Visual Studio is starting to run out of shortcut keys! Once the bookmark has been saved, you can view the bookmark in the Bookmarks window that can be docked at the bottom of your window:

Instead of using the filename as the Bookmark title, try placing a comment as the title instead to remind yourself the importance of the said file, or even a "TODO" comment. I have a handful of bookmarks for files I have edited so I can quickly re-visit the file if need be.

Tip #2: Track item in Solution Explorer

Another tip to help navigate Visual Studio is to enable "Track Active Item in Solution Explorer". This allows any active file to be highlighted in the Solution Explorer. This comes in very handy when performing Searches, since double clicking a result highlights the file in Solution Explorer, giving you a general idea of the location of the file within the Solution.

This option can be enabled through Tools -> Options -> Projects and Solutions.

This behaviour is actually enabled by default, but for whatever reason, this feature was disabled one day. I went through days without this feature, so I finally made the effort to scan the long list of options under the Options dialog, and it was worth it!

Building a Color Editor using COR

noreply@blogger.com (Charles) — Wed, 29 Oct 2008 01:33:00 +0000

Check out the AJAX Color Editor control for a control that displays a color picker. This project includes source code that shows how to incorporate the Web Control in an ASP.NET page. The Color Picker is based on AJAX technology that provides partial rendering for the control, giving it the feel of a fat client.

Table 1 displays the Color Picker. The control displays 2 color palettes – one for the back color and the second for the fore color. The sample text to color shows the selected back and fore colors.

The Color Picker uses:

The COR project provides a set of public static methods for adding Controls.
AJAX technology provides partial rendering for the control, giving it the feel of a fat client

COR Project

The Color Picker is a Web Control. It is created programmatically using public static methods from the 'C' class in COR.

FAQs for COR - A Web Site Building Tool

noreply@blogger.com (John Hansen) — Sun, 19 Oct 2008 22:27:00 +0000

Q: What is COR?
A: COR is software that helps power users to become Web gurus by letting them build and maintain Web Sites. Users, with only browser, can log on to the Web Site to modify or create pages. Pages employ templates that support the placement and editing of web parts by the user (shown below – notice the 'Edit' and 'Delete" controls).

Q: How is COR different from web pages built using Microsoft ASP.net?
A: COR is a small layer of management software that is built directly on top of ASP.net 2.0. It takes full advantage of ASP.net Web Parts to implement its functionality. You get the full power of ASP.net 2.0 without requiring a software programmer for all, but the most complicated web pages.

Q: What Web Parts come with COR?
A: COR comes with a Library of 30 Web Parts. One notable inclusion in the library is a Word Web Part. It allows users to update content using Microsoft Word. Tables, formatting, and pictures in the Word document are automatically converted to HTML by the Word Web Part.

Q: What are some of the other key features of COR?
A: COR directly supports a menu bar across the top of the page and a menu bars on either the side of the page. COR also keeps track of the user's location in the WEB site by displaying "bread crumbs".

Q: What does COR stand for?
A: COR stands for Controls On the Right. This is because when a user is editing a page the controls are displayed on the right hand side of the page. The example below shows the 'controls on right' being employed to add a web part to the header area of the page.

Q: Why did you build COR?
A: We built COR because we needed something to build our own WEB sites. We started by building our Web sites using just ASP.net pages and eventually evolved to COR. We also use COR to build Jetfire Workflow solutions.

Q: Why not just use SharePoint?
A: Microsoft SharePoint is a wonderful product. Many of the features of COR look very similar to SharePoint. COR; however is a much lighter product that is focused on building Web sites.

Q: How much does COR cost?
A: COR is free. The source code is available and does not have any restrictive licensing requirements (BSD license). See COR-Why make it free? and Open Source License Favorites for more details.

Q: How can I extend COR or add a new WEB Part?
A: COR is well documented and uses standard Microsoft programming patterns. An experienced programmer should have no trouble extending COR or adding a Web Part. Naturally, we can be contracted to add new features or build new Web Parts (contact us).

Q: Where can I download COR?
A: www.codeplex.com/cor

Q: What is the difference between DotNetNuke and COR?
A: DotNetNuke employs Web controls and is based on .Net 1.1. Pages in DotNetNuke are built by programmers. COR uses Web Parts and is based on .net 2.0. Pages in COR are built by privileged user(s).

Q: What is required get a Web site running using COR?
A: COR can use, as the server, any Windows or Vista PC that supports Internet Information Services and Forms authentication. Many ISPs support this configuration. The ISP we use is LFC Hosting.

Q: Are there some examples of sites that use COR?
A: yes.

Jetfire
Ontario Amateur Wrestling Association
National Capital Wrestling Club
Ottawa Wrestling Festival
Canada Cup
Arbutus Associates

Displaying Line Numbers in Visual Studio

noreply@blogger.com (John Hansen) — Sun, 12 Oct 2008 17:16:00 +0000

You would think that the display of line numbers should just be automatic when using Visual Studio 2005 or 2008. After all when using a C# compiler all the errors are given by a line number. Also when exceptions occur the stack traces gives the line numbers of the stack (procedure calls) and the line number of the offending code that caused the exception. Unfortunately, by default the line numbers are not visible when viewing the code in Visual Studio. In fact many programmers work for months and even years before finding this important setting.

To display line numbering in Visual Studio 2005 or Visual Studio 2008 click the following sequence.

Tools/Options/Text Editor/C#/General and select "Display/Line Numbers".

Visual Studio C# text editor with line numbers off (default). Note no line numbers.

Select the Tools from the main menu bar, then Options.

Select Display/Numbers so that line numbers are displayed.

Visual Studio C# text editor with line numbers turned on. Note the line numbers on left.

Also See Related Postings
Using Regions
C#: Top 10 Coding Guidelines

Adding ASP.NET Controls programmatically

noreply@blogger.com (Charles) — Sun, 28 Sep 2008 18:21:00 +0000

If you design ASP.NET Web Controls or Composite Controls, you have designed controls programmatically. This approach is not as easy as using the Visual Designer in Visual Studio. This post explores the use of the "C class", which is part of the COR download. The "C class" is a set of public static methods for adding Controls, managing strings, XML files and more.

Personally, once I started designing Web Parts, I did not want to go back to designing controls using the Visual Designer. I actually find it easier to place controls on the page and use logic to decide what controls are being placed on the page. However, designing Web Parts with standard Web Controls leads to much code. The "C class" allows design of controls with minimum code.

// Let's review how a Label is added to a control:

Label label = new Label();

Label.ID = "ThisLabel";

label.Text = "The name to display";

label.Width = Unit.Pixel(200);

label.CssClass = "AFormatOption";

this.Controls.Add(label);

It takes five statements just to add a simple label. For complex GUI's, it is easy to get lost in the number of lines required. I started thinking: "Why not have a simple method that adds the Label with a number of parameters?". E.g. Let's review what such a method would look like.

// Using a method that does the work of assigning the values to the named properties

Label label = AddLabelMethod("ThisLabel", "The name to display", "AFormatOption", Unit.Pixel(200), this);

The AddLabelMethod takes five parameters: ID, Text, CssClass, Width and an object that the label control is added to. The AddLabelMethod returns the new label object, which typically is not required because all the work is done in the AddLabelMethod.

The C class in COR is a set of helper methods that simplify the addition of Web Controls. To add a label,

// Using the AddLabel method is the C class simplifies programmatic design.

Label label = C.AddLabel ("ThisLabel", "The name to display", "", "AFormatOption", Unit.Pixel(200), this);

Note: ToolTip is added to the list of parameters. It is shown as a blank string in the example.

The C class, over 2000 lines of code at last count, contains a number of useful methods, including:

AddTable, NewTableRow, NewTableCell
AddLabel, AddTextBox, AddLinkLabel, and a lot more
AddHiddenField and other methods to get and set the value of the hidden field
Xml file management, e.g. GetAttribute, ReadXmlFile
AddUpdatePanel, AddUpdateProgress, AddTimer (recent additions)
... and more

I find using tables to place controls on the page is now simple. E.g

// Add a table to this control

Table table = C.AddTable("table", Unit.Percentage(100), this);

// Add the first Row

TableRow row = C.NewTableRow(table);

// Add the first cell to the Row – it has text and a tooltip and is 100 pixels wide.

C.NewTableCell(row, Unit.Pixel(100), "a name to display", "a tooltip for the cell", "CellFormat");

// Add a second cell to the Row.

TableCell cell = C.NewTableCell(row);

// Add a text box to the second cell

C.AddTextBox("tb2", "", "Enter the name of something", "TextBoxFormat", Unit.Pixel(200), cell);

Using ASP.NET controls, this five-line sample would have taken about 20 lines of code. This approach has clear advantages:

Reduced footprint – The number of lines makes it easier to understand what is being done.
It is easier to add Comments that relate to what is being done.
The C class methods prompt the user for the typically used parameters. It is now easy to identify if any of the typical parameters have been forgotten.

The "C class" is available in the COR download found on Code Plex.

Related posts include: ASP.NET Life Cycle.

The Life Cycle of ASP.NET Controls

noreply@blogger.com (Charles) — Sun, 28 Sep 2008 13:17:00 +0000

Designing ASP.NET websites is easier if you understand the Life Cycle of the ASP.NET controls. Let's review the ASP.NET controls (Refer to table 1). These include:

Page (Master Page)
User Control
Web Control
Html Control
Composite Control
Web Part

From an object model perspective, the Life Cycle methods are derived from Control, Web Control and Composite Control.

The table presents ASP.NET controls mapped against Life Cycle methods. This is what I think of as the 'get started' Life Cycle for controls. There are more Life Cycle methods, e.g. Pre-Init, if you want to manage Master Pages and Themes for a page. Here are some observations:

You don't need to use all of the states when writing a control
You are best served if you match functionality to the correct Life Cycle method
- Your control will behave properly in all use cases.
- Subtle bugs can occur because you have placed functionality in a non-optimal Life Cycle method

Life Cycle Method	Member of	Page, User Control	Web Control	Composite Control, Web Part	Html Control
Inherits from ->	X	Control – Template Control	Control	Control – Web Control	Control
Init	Control	1	1	1	1
Load Control State	Control	2	2	3	2
Load View State	Web Control	3	3	4
Load	Control	4	4	5	3
Create Child Controls	(Composite) Control			2 or 6 (See Note 1)
Post back Event Handling	Web Control	5	5	7	5
Pre Render	Control	6	6	8	6
Save Control State	Control	7	7	9	7
Save View State	Web Control	8	8	10
Render	Web Control	9	9	11
Dispose	Control	10	10	12	8
Unload	Control	11	11	13	9

Table 1: Life Cycles of various ASP.NET Controls

Controls and the Life Cycle

Html Controls are simple controls that inherit from Control. As such, valid Life Cycle methods include:

Init
Load Control State
Load
Post back event handling
Pre Render
Save Control State
Dispose
Unload

Page, User Control and Web Control includes the methods above, plus:

Load View State
Save View State
Render

The Composite Control and Web Part include the base methods from above, plus:

Create Child Controls

Composite Controls

Being a Web Part designer means that I use Composite Controls. Composite Controls are different in that they have a Life Cycle method called 'CreateChildControls'. (This is probably because of the history of Web Parts and SharePoint.) Here are a couple of notes from MSDN documentation on Composite Controls.

The CompositeControl class is new in ASP.NET 2.0. If you created custom controls in ASP.NET version 1.0 or 1.1, you had to implement the INamingContainer interface to create a new naming scope for child controls. In addition, you had to override the Controls property and invoke the EnsureChildControls method. In ASP.NET 2.0, these and other steps are performed by the CompositeControl class.

You should create the child controls in the CreateChildControls method and not in OnInit or another life cycle phase. The server control architecture relies on calls to CreateChildControls whenever the Controls collection is needed, such as during data binding (if applicable).

Note 1: When the Composite Control is displayed normally, 'CreateChildControls' is called AFTER the 'Load' method. However, when a post back event occurs, 'CreateChildControls' is called AFTER the 'Init' method. This certainly makes the 'CreateChildControls' method an "interesting" aspect of the Life Cycle.

References

http://blogs.thesitedoctor.co.uk/tim/2006/06/30/Complete+Lifecycle+Of+An+ASPNet+Page+And+Controls.aspx – this shows a trace of the Life Cycles of MasterPage, Page, and various Controls.
http://msdn.microsoft.com/en-us/library/ms178472.aspx - this describes the Page Life Cycle.

Quiz made easy

noreply@blogger.com (Charles) — Sat, 26 Jul 2008 19:41:00 +0000

I just finished integrating the Jetfire Quiz into the system. The quiz that I wrote using the Jetfire scripting language was quite simple:

What is your name? __________
Are you over 18? (yes/no)
Select an age category: 18 to 25, 26-35, 36 – 45, over 45
How often do you go dancing in a year? ___

From a code perspective, the Quiz is a set of Questions and Answers. Answers may be text, numeric, yes/no, a selection from a list, date and time, and duration.

A new Web Control is provided (in the website) to iterate over the list of Questions and Answers, providing the user with the ability to input answers. The quiz can be viewed using this custom control.

The real reason for this blog is to brag about just how simple it is to write your own Quiz. My friend, Mo, wrote a quiz in 30 minutes this morning. Mo owns a Print shop in Ottawa, has a Computer Science degree from over 20 years ago and hasn't programmed in a whole lot of years. Mo is a smart guy, but not a programmer. He needed a little bit of help with syntax, but since he uses Excel extensively, he was a natural to write his first Jetfire workflow.

Since I hit him cold with "you are designing a quiz right now", most of the time was spent formulating the questions and answers about the travel quiz that he wanted to write. His travel quiz includes the following questions:

What was your favorite destination? ________
Select your Sex: Male, Female
Select a destination: North America, Europe
Select an age category: Under 18, 18 – 35, 36- 50, over 50
How often do you travel in a year? ____

Less than five minutes later, I had the privilege of being the first to fill in his quiz.

Sound like fiction? With Jetfire, you upload the Jetfire code and start using it immediately. This is possible because Jetfire is a scripting language and re-uses the Question and Answer Web Control described above.

Kudos to screwturn wiki

noreply@blogger.com (Charles) — Fri, 04 Jul 2008 14:44:00 +0000

This blog sends kudos to screwturn.eu, the creators of a .NET open source wiki implementation.

TrackerRealm has been looking for a wiki for the past year that we can use for documentation. After assessing over half a dozen versions of incomplete projects, I was getting extremely frustrated. Then while looking for a new Blog engine one day, I noticed that the Blog engine company was using screwturn for their documentation – I went whoa! – this looks like a great wiki – I wonder how much it costs. Well, the price is right.

Why do I like screwturn wiki?

Ease of installation – it was installed on my PC in 10 minutes. (ScrewTurn store the page data in xml files vs a database)
Ease of skinning – I created a new theme for http://wiki.jetfire.ca in 30 minutes. (I am not a themes expert)
Ease of administration – putting the admin password in the web.config makes it easy to change. Adding new accounts is trivial.
New pages easily created
Ease in tailoring the templates, e.g. header, footer, side panels, etc

Easy sums up what I think about our new screwturn wiki.

New Blog Editor

noreply@blogger.com (Charles) — Thu, 03 Jul 2008 20:17:00 +0000

I am writing this blog on my brand new blog editor – it's called Word 2007. I love Word. Word allows a user to post a blog to Blogger directly from Word 2007.

Word is simple - it lets me use an editor that I am familiar with and format my blog that way that I am comfortable with. And it has a spell checker.

How does it work?

Open Word 2007
Select New from the Office icon
Select 'Create new blog'
Enter Login information for Blogger
(optional) identify an image provider for uploading images (that you embed in Word)
Write Blogs in your favorite editor
Save a draft copy of your blog to polish off later or Publish the draft to your blogger
Once the Blog is finished, Publish the blog.

One gotcha is that once you publish the blog and close the Word Editor, you must use Blogger's editor, UNLESS you save a copy of the blog locally and then re-edit it.

That's it – enjoy.

ADO.Net: The Good, The Bad and The Ugly

noreply@blogger.com (John Hansen) — Wed, 25 Jun 2008 22:05:00 +0000

First I need to state that ADO.Net is a very good component. It does an excellent job of what it was designed to do. ADO.Net provides an object based representation of a database.

Some the excellent features ADO.Net are:

DataTables: Provide a memory representation of a database table (or combination of tables). This allows software to directly read and write to the database data. The ADO automatically takes care of concurrency issues.
DataSets: Provide a memory representation of a number of data table and the relationships between the tables. With DataSets the database schema can be represented in an object format.
XML tools: Provides ability to both input and output XML representations of data to and from data sets and data tables.
Serialization: Data sets can be serialized allowing database data to be available via a web service or remote service. This allows for rich clients to have direct access to the database.

There is an issue with ADO.Net and Data Sets (summarized in this discussion on wikipedia), but that is not bad part.

The bad part is that ADO.Net falls short of the requirements to properly support Object-Oriented design (OOD). While doing an excellent job of providing an object oriented view of a SQL database, a SQL database itself is not very object oriented. That is ADO.Net provides objects that map one to one to the features of database. In the absence of any other components what typically happens is that ADO.Net is used directly with application code. Even with careful planning it can still result in these bad design practices:

OOD tenant of encapsulation is violated. What occurs when ADO is used is that many of the SQL database issues are not encapsulated, but brought into the application code.
Complex objects and especially object composition are not used. Databases only support the storage of built-in types. The result is that the application objects that deal with the database data tend not to use software structures such as queues, FIFOs, collections, and references (object composition). Instead application objects use the built-in types almost exclusively and use the database foreign key structures directly, instead of references. In fact the code is likely not to be object oriented at all.
There is significant code that needs to be created that is dedicated to ADO configuration, setting up data tables/data sets, reading and writing to database, etc. This isn't bad code; the bad part is that it needs to be written, tested, deployed and maintained.

This results in really ugly application code. This ugly code has a number of nasty features:

Software and the database must be changed at same time. Typically changing the database schema requires changing the application software. Adding new features requires not only adding the new objects, but insuring the database is also changed.
The issue of versioning the database schema and software needs to be accommodated. For example when new features require database changes there needs to be a deployment process where the existing databases are upgraded. Alternately the software needs to handle both the old and new database schema.
The application code becomes larger than it needs to be in order to handle that lack of true objects in a database. Bugs become harder to fix. New features become more difficult to add. The code just becomes harder to understand because of its size, lack of encapsulation and use of structured programming
instead of object programmer techniques.

This begs the question, how should you employ OOD and still use a database? One answer is to use an object-relational mapping technique such as is provided by Hibernate or product such as DB4O that makes a standard SQL database look like an object oriented database. These are good, but have their draw backs. Fortunately there will shortly be solution from Microsoft that extends ADO.Net called ADO.Net Entity Framework. It may not solve all the "ugly code" issues and will certainly have some drawbacks, but is very promising. We are excited by it.

The ADO.Net Entity Framework is a very attractive solution since it is not only provides an object-relational mapping service, but will provide Query support using LINQ as well as integrating tightly with Visual Studio. This is great, but in my opinion the biggest advantage of the Entity Framework is that it allows new, and even ongoing, software projects to use OOD while using existing databases, existing database tools and practices. In other words the substantial investment in databases can be protected, while building OOD software to exploit it.

Open Source License Favorites

noreply@blogger.com (John Hansen) — Fri, 20 Jun 2008 15:54:00 +0000

There are lots of open source licenses in existence. Some are general purpose and some are very specific. Our favorites are BSD and GNU GPL. Many of the other open source licenses are variations of these 2 classics.

BSD is the most permissive of the 'open source' licenses. When software has a BSD license it is practically in the public domain. The only real requirement of the license is a citation provision where if BSD software is incorporated into another product, its usage must be acknowledged. Other than that provision BSD licensed code can be incorporated into other products with no restrictions. As software developers we have no qualms about using BSD licensed code.

GNU license is a little more restrictive. If you use a GNU GPL application, for example to build a web site, it is free. It is free even if you make money from the Web site. If, on the other hand, you incorporate GNU GPL code in your product you must make your product GNU GPL licensed as well. For products that are developed for profit this is a very restrictive requirement. This is why most GNU software is also available with a commercial license allowing incorporation into proprietary products. Jetfire is available with a GNU General Public License as well as a commercial license. Here is an excellent article on GNU vs commercial license.

For us when we ship a product with a BSD license we want it used everywhere. One of our goals is to get consulting revenue from customers who want special features. Another goal is to release other products that rely on it. For example Jetfire WebParts operate on top of our BSD licensed COR product. Our primary goal; however is to get attention from delivery of a valuable, quality free software product. In we effect advertising our capabilities.

When we license a product with GNU our strategy is to get is used everywhere as well, but with the twist that if it is used commercially we are also looking for revenue. We are willing to sacrifice some usage that a more permissive license would afford in return for getting revenue. Many non-commercial applications will pay for the commercial license simply to get enhanced support.

COR - Why make it free?

noreply@blogger.com (John Hansen) — Thu, 19 Jun 2008 20:22:00 +0000

COR, which stands for 'Controls On the Right', provides the foundation block allowing mere mortals to build and maintain web sites. That is the goal behind our new BSD licensed project.

Briefly, COR is a project available on CodePlex that allows anyone to become a guru at designing and building web sites. You probably need an expert to set it up, but once set up 'mere mortals' can develop pages and update content. It also helps if you have a graphic artist to help with the color schemes and provide some banner graphics.

We built COR because we were tired of building our site. We didn't have a lot money to hire someone build and maintain our site, so we needed to do it. We quickly became tired of constantly hand coding HTML and patching pages together from a half dozen tools. After re-building the same page a number times by hand we decided we were going to automate. Our goal for COR was that only a Web browser was required to build or change Web pages. The running joke was "After all, how hard can it be?". Well as it turns out it is always harder (and takes longer) than you think, but using ASP.Net 2.0 it was manageable. In fact using a lot of tools in .Net bag, such as the Forms Authentication, made the entire effort viable.

We really liked the modular Web Part concept and the way SharePoint allows users to create Web pages. We would have used SharePoint, but our ISP, as is the case with most ISPs, didn't support SharePoint. So both Web Parts and SharePoint style web page editing is a key feature of COR.

We use COR internally because we are also mere mortals. Our websites http://www.trackerrealm.com/ and http://www.jetfire.ca/ are built with it. We also have numerous other websites using it. We like it. We like it so much that we think it should be everywhere. We'd like to get paid for COR, but that is just not going to happen. So we decided to go for fame and glory. What better way to do that then to make it freely available, with source code, and a very permissive license.

Finally COR is a foundation block for our Jetfire Web offerings. Check out Cor on Codeplex.

Hello World with Jetfire

noreply@blogger.com (John Hansen) — Thu, 12 Jun 2008 18:57:00 +0000

It has become a tradition the first program to introduce a user to a programming language is "Hello World". We thought it would be appropriate to have a "Hello World" program for Jetfire (download site) as well; however we were concerned that it didn't really show how Jetfire is different from everything else. Well that is the point. Jetfire it is not different when it comes to writting code to solve a problem, but it is radically different, in that it is a whole lot simpler, when you try to solve real world problems with Jetfire.

Well what do we mean by a lot simpler. Well lets look at "Hello World".

namespace test
{
   workflow HelloWorld
   {
      DateTime creationTime = DateTime.Now;
      public string Hello
      {
           get{return "This workflow was created at:" + creationTime.ToString();}
      }
   }
}

On the surface it looks almost like C#. The only significant difference is that 'class' has been replaced by 'workflow'. Other than that it is valid C# code.

So what is the difference? Why bother with Jetfire? Well the big difference is that Jetfire really starts where C# ends. For example, once a Jetfire instance of the HelloWorld object is created it is persistent until it is deleted. That is why there is a time stamp in this example so you could see when each instance was created. Try it for yourself.

In C# to make an object persistent you need to write code to save it to database or a file. Yes, you can serialize the object; however then serialization breaks if you change the code, and so on. With Jetfire there is nothing more to do. The objects and code are persitent. When the code changes a new version is automatically created.

This is part of goal of having the programmer focus on the problem, not the programming infrastructure. Hopefully the "HelloWorld" example gives some introductory insight to the features of Jetfire.

Auto-Display for Workflows

noreply@blogger.com (Charles) — Sat, 29 Sep 2007 01:51:00 +0000

In talking with customers about the workflow creation process, one customer got quite excited about how quick and easy it is to create a workflow. Suddenly, the customer asked, "If I can create a workflow this fast, I want to create a lot of workflows. Can I display the workflow using some existing GUI without having to design a custom GUI?".

Custom GUI's take time to create. The objective of Jetfire is to simplify the workflow creation/modification process so that Power Users can build workflows and upgrade them. But what good is a simple workflow creation process if there is no GUI to use it?

This is a common problem with workflow systems. I have not seen a workflow system that provides a user GUI that adapts to new workflows. However, with the experience from Tracker, we decided that a general GUI is best addressed by a data-driven system.

Using Web Parts, we created a set of Web Parts that provide a general purpose workflow display for Jetfire. (see http://Jetfire.ca/pages/JetfireWebParts.aspx for more informaiton.)

Silverlight 1.0 Released

noreply@blogger.com (Charles) — Sat, 29 Sep 2007 01:24:00 +0000

Sep 19, 2007
Jason Beres from Infragistics in Boston, Mass was the guest speaker at Ottawa dot net community Events speaking about Silverlight. Silverlight was just released on Sep 5.

We have been testing CTP's for WPF/E, now called Silverlight, since 0.8 release. There have been some subtle changes in the interface definitions. In upgrading our Silverlight projects from 0.9 to 1.0 (see http://www.trackerrealm.com/blogs/WPFEControls/images.htm), we noticed the following changes:

Javascript is no longer a part of the Xaml file. Events have moved from the Xaml file to a "code behind"Microsoft Javascript file using an AddEventListener method.
I refer to it as a Microsoft Javascript file, because it does not conform to the standard JS file format. Rather, Microsoft have created a Javascript object model.
A number of Xaml Control properties are gone. (not deprecated, but gone)

Meanwhile, back to Jason - fantastic presenter and presentation. Jason discussed Silverlight 1.0 and 1.1. He juggled back and forth between the formal release and the CTP highlighting differences. Key points:

Silverlight is Microsoft's competitor to Adobe Flash. (great graphics and animation.)
Silverlight is a cross-browser plug-in.
Silverlight is Xaml-based.
Silverlight is a stand-alone product, ie. not dependent on .net. (Microsoft are integrating base classes from .net)
Silverlight 1.0 release is 4.6 MB. (expect Silverlight 1.1 release to be about 7 MB)
Silverlight language for the code behind file in 1.0 is Javascript
Silverlight language for the code behind file in 1.1 is C# and VB.net

Jetfire is born

noreply@blogger.com (Charles) — Wed, 26 Sep 2007 22:03:00 +0000

Blogging has taken a back seat over the past few months while we have been working on Jetfire - a new approach to designing workflows. Well, Jetfire has arrived and blogs should start coming.

Jetfire debut at Ottawa Demo Camp

noreply@blogger.com (Charles) — Wed, 26 Sep 2007 21:09:00 +0000

Monday, Sep 24, 2007
John and Charlie present Jetfire Workflows to an Ottawa developer audience. (See FAQ at http://Jetfire.ca/pages/JetfireFAQ.aspx for more info.)

The demo showed a DVD Tracking application. DVD's are added to Jetfire and tracked by Home, On Loan, Lost and Dead states. Commands, e.g. Lost, Found, Died) and Properties (On Loan To, Loan Timestamp, Returned Timestamp, and Lost Timestamp) are displayed on a general Web Demo available to ALL Jetfire workflows.

The Jetfire code, written in a C#,Java-like language was developed by John and Charlie at TrackerRealm. The language is workflow specific and makes it quick and easy to write workflows.

Demo key figures include:

Multi-language strings (see English and Swedish-Chef instructions)
Command Method and Property filtering by state (only see what you need to see)
Change state (uses keyword: 'enterstate')
Enter 'On Loan To' name causes state change, On Loan To Timestamp to be automatically updated

Bottom line: Comments like "Is that all the code there is?" tells me that we are on the right track.

Test Drive Jetfire yourself at http://jetfire.ca/Pages/JetfireDownload.aspx

The DVD workflow (100 lines of code) is shown at http://jetfire.ca/Code/Apps/DVDInventory.txt.