March 28, 2006

Try using FreeMarker to generate XML documents

Generating XML from code is a very common development task. There are a multitude of ways it can be accomplished. Recently, at a client, we needed to generate an XML message which had to conform to a rather complicated XML schema. We already had an object model that worked well with our code base. We considered using XML binding API's like:
Each of these had its own limitations which reduced their feasibility within our application. Next we considered hand-coding the XML directly with API's like:
The amount of code required to create an XML document with these API's was excessive. Code like this was not fun to write nor easy to follow.

So we decided to take a different approach and use a templating engine, specifically FreeMarker. Using FreeMarker to generate the XML response messages turned out to be a great decision. This is a list of some of the advantages we have noticed:
  1. The FreeMarker template we wrote to create the XML response message is an XML document. This simple fact should not be overlooked.
  2. Easy to integrate into any application. Very little code was required to utilize FreeMarker in our application.
  3. Excellent performance.
  4. The built-in functionality that FreeMarker provides is very powerful.

Tutorials for Waffle

I have been spending my free time updating Waffle with functionality and documentation. Two tutorials have been added to the Waffle web site which should provide a good overview of how to use Waffle and what makes it different.

The examples in the tutorials show how to use Waffle with JSP's. This was done based on feedback I have had when talking about Waffle with developers. At this point you should get latest Waffle code directly from subversion and build it with Maven 2.0.

I would appreciate any comments or feedback you could offer.

February 22, 2006

Sourceforge and subversion

I logged into SourceForge.net today and noticed that a Subversion link was now available when I went to the Administration page. I'm not sure when this feature became available or how long it took me to actually notice it but I think it is great news that SourceForge now provides it.

Look for Waffle's code base to be moved to Subversion shortly.

February 14, 2006

FreeMarker support in Waffle

I recently added FreeMarker support as another option for creating Views in Waffle. FreeMarker is very similar to Velocity but seems to be more powerful. One of the nice features of FreeMarker is that it will point out the errors in your scripts. Velocity basically ignores any problems you may have, while FreeMarker displays an error message directly in your html that pin-points (line and column number) where the problems is located. Additionally FreeMarker actually allows you to reference JSP tag libraries within your FreeMarker scripts. That should allows for some nice flexibility. Take a look at the FreeMarker Servlet Documentation for further details. And take look at Waffle to see how easy it is to create web frameworks when you don't have to learn a proprietary XML syntax or new UI language.

Next task is to document how to create Waffle application with JavaServer Pages (JSP).

January 26, 2006

The Glacial Methodology

The Waterfall Methodology is making a comeback in a big way. Hurry and register when you can ...

http://www.waterfall2006.com/

January 12, 2006

Mmmm Waffles...

It's been a while since I posted a blog, but I have been busy working on a new open source project. A new web framework for use in java/j2ee web applications.

Yes, I know there are already a plethora of java web frameworks, but Waffle (which is the name of the web framework) is different. Honest.

I wanted to work with a web framework that supports POJO based Actions, Dependency Injection, and it has no dependency on XML configuration files. Applications built on Waffle will be easier to develop and test with than other java web frameworks. Plus, it's buzz word compliant already fitting nicely with AJAX. :-)

Please have a look at the documentation and send me feedback on any suggestion you may have for improving the documentation or the framework itself.

August 31, 2005

Documentation for NanoContainer.NET

Been working on clearing up some of the issues with NanoContainer.NET and believe to have gotten to a point where hopefully we can consider going forward with a release. First thing that need to be done is documentation, so I have started to create documentation specific to the .NET implementation of NanoContainer. Take a look here.

August 16, 2005

Custom Attributes for NanoContainer.NET

I recently rolled onto the Beach after working on the same project for the past 7+ months. The project successfully utilize PicoContainer.NET for configuring both the client and server.

A colleague of mine, Jay Fields, and I have been discussing the use of .NET Attributes with pico/nano. I have for a while felt that the .NET implementation of pico and nano have really just been straight ports of the Java code while not really taking advantage of the features C# offers. One particular useful addition are Attributes.

So the past few days we have worked on a spike to take advantage of Attributes in the NanoContainer.NET. Utilizing Attributes in the code will allow us to define how an object is added to the container and will free us from having to create a separate script for loading the container. Here is an overview of the work we have done:

Attribute:


RegisterWithContainerAttribute - This is a class level attribute used by concrete classes that need to be registered with the container. The properties of this class are:
  • object key: which represents the key the component should be registered against
  • ComponentAdapterType componentAdapterType: An enum that defines the type of component adapter (choices consist of Caching, NonCaching and Custom). Caching is the default.
  • DependencyInjectionType dependencyInjectionType: An enum that defines the DI construct to follow (Constructor or Setter are the choices) as expected Constructor is the default type.
  • Type componentAdapter: represents the concrete Type to use as the component adapter. This allows a concrete class to define a custom component adapter to use for itself.


Examples of use:

// constructor based with caching...
[RegisterWithContainer]
public class Foo : IFoo
{
private IBar bar;
public Foo(IBar bar)
{
this.bar = bar;
}
}

// setter based with caching
[RegisterWithContainer(DependencyInjection=DependencyInjectionType.Setter)]
public class Foo : IFoo
{
private IBar bar;

public IBar Bar
{
set {this.bar = value; }
}
}

// constructor based with non-caching...
[RegisterWithContainer(ComponentAdapterType.NonCaching)]
public class Foo : IFoo
{
private IBar bar;
public Foo(IBar bar)
{
this.bar = bar;
}
}

// setter based with non-caching...
[RegisterWithContainer(ComponentAdapterType.NonCaching,
DependencyInjection=DependencyInjectionType.Setter)]
public class Foo : IFoo
{
private IBar bar;

public IBar Bar
{
set {this.bar = value; }
}
}

// utilize a custom component adapter (caching and injection type are ignored for custom)
[RegisterWithContainer(ComponentAdapterType.Custom,
ComponentAdapter=typeof(CustomComponentAdapter))]
public class Foo : IFoo
{
private IBar bar;
public Foo(IBar bar)
{
this.bar = bar;
}
}

// example of the custom component adapter...
public class CustomComponentAdapter: CachingComponentAdapter
{
public CustomComponentAdapter(Type type)
: base(new ConstructorInjectionComponentAdapter(type))
{
}
}

Now the CustomComponentAdapter doesn't really serve a purpose in this example, but I think it gets the point across. I think this addition to NanoContainer.NET is extremely useful and takes advantage of the language features. I think it also opens up the idea of utilizing similar functionality for Java 5.0 Annotations. Consistency between the two would be great.

June 17, 2005

Dynamic Proxy missing from C#

There are many things about the C# language I really like and think Java would benefit from having. On the flip side of that several Java features are also sorely missed in C#. One in particular is dynamic proxy. The java implementation of dynamic proxy is java.lang.reflect.Proxy which is an extremely powerful feature. For those unfamiliar with dynamic proxy take a look at the JavaDoc to gain a deeper understanding of it.

For those who aren't interested in reading the JavaDoc here is a quick overview. Basically a dynamic proxy allows you to generate an instance of an Interface(s) at runtime without the need of a real implementation. So for example we have an Interface Foo
public interface Foo {
String hello();
}

We can create an instance of Foo without having to have a class defined which actually implements Foo. In Java we can do this like so:
ClassLoader classLoader = Foo.class.getClassLoader();
Class[] interfaces = new Class[] { Foo.class }; // list of interfaces to support
InvocationHandler invocationHandler = ... // custom impl of InvocationHandler
Foo instance = (Foo) Proxy.newProxyInstance(classLoader, interfaces, invocationHandler);

Now the actual power of this is handled in the implementation of the InvocationHandler. Here is a simple implementation of the InvocationHandler which traps method calls to the method hello().
public class FooInvocationHandler implements InvocationHandler {
public Object invoke(Object proxy, Method method, Object[] args) {
if(method.getName().equals("hello")) {
System.out.println("The hello method was called!");
}
return "world";
}
}

While this is a very trivial example it does show how easy it is to create a proxy and how potentially powerful they are. Adding AOP type of functionality to method calls is simple to do, such as Security checks and the overused logging example.

Well back to my point. When working on the .NET port of PicoContainer I needed the ability to utilize a dynamic proxy for the ImplementationHidingComponentAdapter. This ComponentAdapter hides the implementation from the container. I figured I would easily be able to convert this logic to the C# port. To my surprise C# does not provide an out of the box simple implementation of dynamic proxy. They do provide the Emit API which will allow you to create your own proxy behavior for it. But creating a sufficient implementation of dynamic proxy from the Emit API is not a trivial task. Luckily the open source community has created an implementation of dynamic proxy for .NET called DynamicProxy.

Best to follow the documentation on the website itself or the related article on The Code Project. It's a good implementation and thoroughly tested. PicoContainer.NET utilizes it, as well as NHibernate. One caveat however is that at the moment it does not work with Mono, hopefully that will be fixed.

Mono error:
** ERROR **: file class.c: line 2820 (mono_ldtoken): should not be reached

It would be great if Microsoft would add dynamic proxy support to the language but until then DynamicProxy seems like an nice tool.

June 16, 2005

JetBrains MPS: Meta Programming System

The folks over at JetBrains, makers of the excellent IntelliJ IDE, have released their latest project MPS or Meta Programming System. MPS appears to be a Language Workbench. The concept seems extremely interesting, and could potentially be a huge change with how systems are developed.

MPS can be downloaded through the EAP program JetBrains offers. MPS appears to have a dependency on the latest IntelliJ IDEA code named Irida, which too is available through JetBrains' EAP. The MPS is itself a plug-in for Irida IDE.

June 12, 2005

Languages , languages and more languages.

Earlier this year I started working with .NET, C# specifically. Since then I have also started to jump on the Ruby bandwagon. Most recently I've gone back in time and started re-learning C++. It's enjoyable spending time and getting into each language. I think it is valuable to have an understanding of what else is out there. Without a doubt I can see how expanding my knowledge with these languages will benefit me in general. I find that opening my mind to different concepts helps me with me think of things like: "How can I do something similar to this in Java?", or "What is the equivalent syntax for this in C#."

Next steps Ruby on Rails... or maybe I'll have to break out my old SmallTalk books.

April 14, 2005

Project Structure for .NET applications

Over the last few months I have been working more and more with .NET (C# specifically). After working almost exclusively on Java projects for the last several years I have a bias for how a project should be laid out. However, I quickly realized that a Java projects structure does not translate easily to .NET. This seems specifically related to the nuances of Visual Studios.

I initially started investigating the different layouts for several popular .NET open source projects. Each project I looked at varied greatly in how it was laid out.
I was surprised to see that no common approach existed for .NET projects.

The following is a quick overview of how I have structured projects. I'll use PicoContainer as an example:

Java Project Structure

-- picocontainer
-- lib
-- src
-- java
-- org
-- picocontainer
-- defaults ...
-- test
-- org
-- picocontainer
-- defaults ...

.NET Project Structure

-- picocontainer
-- lib
-- src
-- PicoContainer
-- Defaults ...
-- PicoContainer.Tests
-- Defaults ...


The main difference is how package naming in Java does not translate easily to namespaces in .NET. The folders PicoContainer and PicoContainer.Tests are each separate Assemblies. PicoContainer.Tests of course contains a reference to PicoContainer. The differences are of course minor but from what I have seen there does not yet seem to be a standard project structure for .NET.

The advantage of the .NET layout is it works well with Visual Studios and does not require any tweaking of the project properties. Hacking the properties just makes things confusing and less intuitive.