Wednesday, January 25, 2012

Era of the XAML user interface

I hear the term XAML user interfaces mentioned way too often these days.

XAML has in fact nothing to do with userinterfaces. XAML is just a language for instantiating an object structure. I have previously written about how I have used it as a configuration language for my applications, a sort of light weight dependency injection framework. To show that WPF and Silverligth are not the only UI frameworks that can be used with XAML I have used XAML to create a small Windows Forms form.

The root node of my XAML file will be Form. By providing "clr-namespace:System.Windows.Forms;assembly=System.Windows.Forms" as the default namespace Visual Studio and .net will recognize the elements and validate them to match a structure that is allowed beneath a form. If you need to use other .net namespaces, you just add a prefixed xml namespace for each of those .net namespaces.




Visual Studio will pr default open a WPF/Silverlight visual presentation along with the text editor when opening the XAML file. As we are not using WPF or silverlight the visual presentation will not show anything usefull. The XAML can be distributed as a file besides you application, embedded as XAML or embedded as BAML (XAML compiled to a binary format). The BAML approach is probably the most sensible solution for a real life application.

To create an instance of the form just give the XAML stream to a XamlReader and cast the result to a Form object. Now the form can be displayed by calling Show, like you would on any other windows form.


When the form object has been created, i use two lines of code to hookup some eventhandlers before showing the form. The find method on the form is an extension method for Form that flattens that flattens the structure of the form so that LINQ can be used on it. The generic type is a filter that only returns the controls of that type and the lambda is a further filter. The find method has been implemented in the plain framework, so you can go there to se the implementation.
The Do method is just like the ForEach method on List, this however work for any type of IEnumerable<T>.

The first of the two lines finds all buttons whose name start with "Command" and hook them up to an event handler. The second line hooks an event handler to the TextChanged event of all controls whose name start with Value. In this way it is easy to use a naming convention to hook the UI up to business logic. Dependind on your architecture, you might hook it up to fire commands or whatever.

You might implement some layout manager the same way, or you might inherit panel or something other control and create a layout manager that way. By implementing you own controls you can also put metadata on the controls in your UI.

So, XAML has the potential of being used with other UI frameworkds than WPF and Silverlight.

http://dotnetexception.blogspot.com/2008/04/xaml-ultra-lightweight-ioc-container.html

Thursday, January 19, 2012

Suitable Business model?

I have created a prototype for an application.
  • I know there is a market for what the application does as there are existing products that have same target audience.
  • Existing products are VERY pricy.
  • The product is simpler and easier to maintain than existing products in the market.
I just have one problem. How should I put this to market?

A way could be to make it open source. This has worked for me with plain. Plain was however a theoretical experiment, a playground for thougths on how simple and easy application architecture could be made. There was never a plan for a final release because the process was more important. The no limits and no constraints meant that we could implement a search filter framework that resembled Linq a bit before we ever heard of Linq. A validation framework much like the one now found in nHibernate and ASP.Net Mvc 3 etc.. But plain intentionaly lacked one thing that I would like my new project to have. Exposure and usage.
  • Open source the product and commercialize tools and support.
  • Open sourcing everything.
  • Make everything closed source.
  • Some others I haven't thought of.

This is a more finite problem and I want to work towards a releasable codebase. Will a enterprise product ever be popular if it is cheap?
Will it be possible to have a differentiated licensing model for hobbyists and enterprises. Will this model result in a greater usage? Is it at all possible to have the kind of openness and transparency I'm looking for if the project is not open source?

Wednesday, January 18, 2012

Declarative structure initialization

I'm on the lookout for a Dependency Injection framework for .net that supports a small, compact and declarative syntax. I want it to be so easy that non programmers can figure out what is going on.

My first thoughts were on XAML as it is simple and declarative. The reason for not choosing this anyway is that it doesn't support generics in a nice way. By not in a nice way I mean very verbose and strange. On top of that XAML is not implemented on mono.

Springframework and Castle Winsor is also too verbose for my likings. Although they are very good, they still require me to define my object at one place and reference they together in a structure somewhere else. Thsi is not a bad thing, I would just, also, like the possibility to create the objects in the structure inline where they are needed.

Another solution could be to consume code and execute it. This ofcorse is also way off compared to what I want to accomplish.

Any Ideas on what path to follow?

Wednesday, January 04, 2012

Wishlist: Derived generic parameters

In .Net generics gives a nice way to make type agnostic code that are not limited to a specific type.

The following two types are taken from the plain framework.

interface IBusinessEntity<T>{
    T Id {get;set;}
}


interface IDao<T,TT> where T : IBusinessEntity<TT>{
    T Get(TT);
    TT Save(T);
}


As shown you can use gemeric types as generic parameters for other types. In the IDao interface, I have specified that T must be a IBusinessEntity interface with the TT type as a generic parameter.
In my example I will create a Article class that implements the IBusinessEntity interface and a generic Dao implementation

class Article : IBusinessEntity<int>{
    //some code
}


class Dao<T,TT> : IDao<T,TT>{
    //some code
}



Now I want to get a dao for the class you just created. As Article has int as a generic parameter, the Dao objects has to defined with the article type as well as int to be able to compile.

var dao = new Dao<Article,int>();

Once you apply "Article", the only valid type as TT is "int". If you apply anything else, the compiler will let you know that "Article" is not valid. The reason for this is that in the definition of IDao, T has a requirement for T, not TT.
It has been bugging me that the compiler complains about the type of T and not the type of TT. T is the important generic parameter, and TT could just be derived from that.

In future releases of .net I would like to be able to write the following.
interface IDao<T<TT>> where T : IBusinessEntity<TT>{
    T Get(TT);
    TT Save(T);
}



This way I could specify TT as part of the signature, but as TT is derived from what type T is, I would only have to specify T when using it.
When creating the dao I could then write.

var dao = new Dao<Article>();

This is a small improvement, but it would remove some strange dependency error when using multiple generic parameters.