The other day, I was trying to get the icon for a button in flex programmatically for a FlexUnit test. The code I was testing set the icon of a button using setStyle('icon', ICON). I attempted the obvious button.getStyle('icon') in the test, but was surprised that this always returned null.

A little bit of digging revealed that the I needed to go through the style declaration for the button. When changing my test to assert on button.styleDeclaration.getStyle('icon'), I was able to successfully access the icon.

I found this a bit non-intuitive, but fortunately it only involved some investigation and minimal code changes.

Share/Bookmark

Quite a while ago, I wrote a blog post which included some code which allowed you to use ActiveRecord without needing a database table.

I recently needed that functionality again, so I converted that code into a plugin and put it on github so that I could easily include it in another project. While doing this, I also cleaned up and simplified the code quite a bit.

The github page is here: http://github.com/AnthonyCaliendo/acts_without_database/

Related Services: Ruby on Rails Development
, Custom Software Development

Share/Bookmark

Mocha on sparklette.net

Mocha is the mocking library used by the Rails team, so it has understandably gained some traction among Rails developers. I have started using it over flexmock lately, but ran into some problems with partial mocks on ActiveRecord objects. The problem stemmed from the fact that ActiveRecord instantiates new records when returning records from finders, which meant that creating partial mocks for a particular record was difficult.

I created a helper method to make this easier, and so far it has cleaned up a bit of my tests.

Using #any_instance is not helpful in the cases I ran into, since I wanted to target a specific record for different expectations.

You could mock out the individual #find or #find_by_* methods as needed in each test, but that didn’t seem ideal to me. Instead, I dug a bit into ActiveRecord to find what method was called when it actually instantiated the records after a find. I discovered that there is an #instantiate method which takes a hash of column=>value pairs from the finder to instantiate those records.

The following is the helper method which I created to do this:

def mock_active_records(*records)
    records.each do |record|
      record.class.stubs(:instantiate).with(
        has_entry('id', record.id.to_s)
      ).returns(record)
      record.stubs(:reload).returns(record)
    end
  end

Here is an example test:

require 'test_helper'
class UserTest < ActiveSupport::TestCase
  setup do
    @user = User.create!
    @non_pending_order = user.orders.create!
    @pending_order = user.orders.create! :pending => true
    mock_active_records @non_pending_order, @pending_order
  end

  test 'cancels pending orders when deactivating user' do
    @non_pending_order.expects(:cancel).never
    @pending_order.expects(:cancel).once

    @user.deactivate!
  end
end

This test makes sure that when I deactivate a user, that I call the cancel method on only the pending order.

Now, you may be asking “why don’t I just test the side effects of cancel on the orders?” Well, I feel that what happens during cancel for an order is outside the scope of a unit test for user. In this example, cancel can have a multitude of side effects. In the context of a unit test for a user, I don’t care what happens when I cancel an order. I only care that I do cancel it.
Also, if cancel needed to make an outbound call to another system, I wouldn’t want an external system to be a dependency of my unit test. Mocking out the method removes any external and implementation dependencies in my unit tests (a functional test is a different matter, mind you).

Related Services: Ruby on Rails Development, Custom Software Development

Share/Bookmark

Photo Credit: by dpascoe

Not many people talk about good practices to use for comments in code. Many people see them as an extra or freebie, so not a lot of thought gets put into them. The truth is, though, that comments are a great tool for giving insight into the thought process when the code was being written. Unfortunately like any tool, comments can be misused.

Here are three of the most common misuses of comments which I tend to run into.

1. Commenting the Obvious
A.K.A. Superfluous Comments
A good rule of thumb for comments is to not comment on what the code is doing, but why it is doing it. You then try to write the code as self-documenting as possible so that footnotes aren’t required to figure out what is going on. Obviously, there are going to be some times when this rule can’t be followed because of the complexity of the situation and in those cases comments about what is going on is valuable. However, you will sometimes run into comments for code which is easy to understand

Please take a look at the following real live example from some Flex 3 SDK code which sparked the idea for this post. I would have to assume that anyone familiar with ActionScript would be able to figure it out on their own…
BAD

    //--------------------------------------------------------------------------
    //
    //  Constructor
    //
    //--------------------------------------------------------------------------

    /**
     *  Constructor.
     */
    public function TextInput()
    {
        super();

        // InteractiveObject variables.
        tabChildren = true;
    }

When I saw that first giant comment, I thought to myself “hey, this just might be a constructor”. When I saw the second comment, I was sold on the idea! Nestle that third comment about InteractiveObject variables into your mind for the next misuse (misleading comments), but try to focus on the first two for this one.

Commenting on very obvious stuff such as “this is a constructor” just creates clutter which reduces the readability of the code. Instead of seeing more code at once, I have to scroll past large chunks of useless information. Whatever “code style” reasons people use as rationalization, these types of comments are unnecessary and don’t provide useful additional information or clarity (the whole point of comments). If you feel you need a map to show where things are located, I would suggest refactoring into smaller classes and/or establishing code formatting guidelines (such as, “static variables go at the top above the constructor”).

So, knowing this, what should the comments look like?
BETTER

    public function TextInput()
    {
        super();

        // We want our children to be tab-enabled since our TextField
        // child will be handling a lot of the work, so force this
        // value to true to allow that.
        tabChildren = true;
    }

Now, my attention is focused on a useful comment and not parsing through a lot of useless comments.

2. Comment Confusion
A.K.A. Incorrect or Misleading Comments
There are two main causes for this problem. The first cause is if the coder will write a comment that is either incorrect or not very obvious. Sometimes this is because the confusing comment makes sense to the person writing it, and sometimes it is just because the person made a mistake. The second cause is “code/comment drift”; this is when code is updated but the comments are not. Code can change over time, but sometimes the comments that explain what is going on are left behind when the code changes to do something else.

Whatever the cause, incorrect or misleading comments can lead to confusion when the comment contradicts the code in subtle (or not so subtle) ways; you have to dig through source control or old requirements (which are sometimes not updated either) to figure out what the code should be doing. It is an even worse problem if there is no test for the logic in question.

Deleting or updating comments when you change the code seems obvious to most, but I have run into this problem on more than one occasion. The same goes for writing clear comments. I could have used the previous example’s comment of “// InteractiveObject variables.” to illustrate this point since that is confusing given what the code which follows it actually does , but I’m going to spoil you with an exaggerated fake example.
BAD

public int count(List stuff) {
    // the number of foos we find
    int barTotal = 0;

    // count foos
    for (Something it : stuff) {
        if (it.isBar()) {
            barTotal += 1;
        }
    }

    // return foo count
    return barTotal;
}

Now, judging by the comments, the code has a bug since it should be counting foos and not bars. In a perfect world, the method would be named better to indicate what needs to be counted (self-documenting code) and there would be a unit test which would prove what should be going on. But since we don’t have any of that, we are left scratching our heads and spending time looking in source control and old requirements documents to try to figure out what needs to be counted.

What would some better comments look like? (N.B. I won’t change any of the code’s naming, which is really what needs to be done in this case).
BETTER

/**
  * Count the number of bars in the passed list, and return it
  */
public int count(List stuff) {
    int barTotal = 0;

    for (Something it : stuff) {
        if (it.isBar()) {
            barTotal += 1;
        }
    }

    return barTotal;
}

Notice that I made the comment reflect the code. In the absence of any evidence of what the code should be doing, assume that it is doing the right thing and adjust the comments to reflect that. This piece of code still needs to be investigated to determine if it is a bug or not (no, seriously, just changing comments is sweeping the problem under the rug), but at least the comment confusion has been removed.

3. Not Enough Comments
A.K.A. Failure to Execute
This is probably the most common situation. When writing code, people don’t tend to think about maintaining the code or they have difficultly realizing what “unique knowledge” they have about the situation which makes certain things obvious to them but completely confusing to someone else.

Knowing when a comment is needed is an art and it is difficult to give direction. The one piece of advice which I’ve found useful is to ask yourself the question “if I came back and looked at this code in a year, would I know what is going on?”. If not, try to leave comments which would help your future self figure that out.

Take a look at the following:
BAD

public void handleError(int errorCode) {
    if (errorCode < 3) {
        errorCode += 1;
    }

    notify("received error" + errorCode);
}

Now, why exactly do we need to add one if the error code is less than three? What sort of madness is behind this?

Without a comment to tell someone what is going on (or remind yourself), this magic math is a mystery. Do we need to do this? Has the reason for this apparent hack changed since it was coded up? Keep in mind that a unit test wouldn't be much help here unless it had comments or a name which implied why this is being done.

Now, let's take a look at the same code which different comments.
BETTER

public void handleError(int errorCode) {
    // to support operations, our error codes need to be translated
    // to their scheme.  the mapping is:
    //     our 3 and up = the same for operations
    //     our 0 = their 1
    //     our 1 = their 2
    //     our 2 = their 3
    if (errorCode < 3) {
        errorCode += 1;
    }

    notify("received error" + errorCode);
}

With just a simple comment, the reasoning for this math is now known to anyone who looks at the code. A year later, you will be able to look at the code and know why that math is being done.
UPDATE: 3:30PM CT: Again, the correct solution to this problem would be to refactor the code to be self-documenting; however, I wanted to focus mainly on the comment aspect of this instead of improving the code itself. Improving the code would make the comment completely unnecessary, but ignore that for the sake of this example .

Good coding practices, TDD, and pair programming will play a major role in alleviating comment misuse. However, keeping in mind the rule of commenting the why and not the what will go a long way to improving comment quality.

Share/Bookmark

Recently, I needed to create a special tag in Grails which would render specific children in a way that is aware of their order. I wanted to stick entirely with markup (not passing an array to a tag), and also wanted to avoid putting lots of logic inside a .tag file. While it was possible to write a tag lib which first parsed the children in a “non-render” mode, I preferred a solution which did not require doing my own parsing before render. The solution I came up with isn’t the most flexible, but it got the job done in a relatively clean way with minimal custom code.

The following is an example solution with the associated code and tests.

The problem is this: I want a parent tag which will add different class names to the children depending on their order. For this example, we will be adding even/odd and a first/last class to the appropriate children. For the purposes of this example, we will ignore CSS 3.0 Selectors, which could do this entirely in the stylesheet.

First, let’s generate our tag lib through grails.

grails create-tag-lib ParentChild

Now that we have our empty files, we can write a test to define the expected behavior in the generated test file. Make sure that you are extending grails.test.GroovyPagesTestCase.

class ParentChildTagLibTests extends grails.test.GroovyPagesTestCase {

    void testParentContainerShouldRenderChildren() {
        def writer = new StringWriter()
        def markup = new groovy.xml.MarkupBuilder(writer)
        markup {
            ul('class':'myParent') {
                li('class':'myChild even first') {
                    a(href:'/first', 'one')
                }
                li('class':'myChild odd') {
                    a(href:'/second', 'two')
                }
                li('class':'myChild even last') {
                    a(href:'/third', 'three')
                }
            }
        }

        assertOutputEquals(
            writer.toString(),
            ''
        )
    }
}

Now that we have a failing test, we can write the actual code. Notice that I used a custom namespace here (just for the sake of example).

class ParentChildTagLib {

    static namespace = 'example'

    def parentContainer = {attrs, body ->
          // we'll be using this to keep track of our children
          def children = []
          this.pageScope.parentContainerChildren = children
          // this will execute the body, so that the children are
          // appended.  obviously, anything other than child
          // tags will not render correctly.
          body()

          def mkp = new groovy.xml.MarkupBuilder(out)
          mkp {
              ul('class': 'myParent') {
                  // iterate over all the children, and
                  // render them here
                  children.eachWithIndex {child, index ->
                      li('class': determineClassNames(child, children, index)) {
                          a(href: g.createLink(child.url), child.label)
                      }
                  }
              }
          }
      }

      private def determineClassNames(child, children, index) {
          def classNames = 'myChild'

          if (index % 2 == 0) {
              classNames += ' even'
          } else {
              classNames += ' odd'
          }

          if (child == children.first()) {
              classNames += ' first'
          } else if (child == children.last()) {
              classNames += ' last'
          }

          return classNames
      }

      def child = {attrs, body ->
          // simply keep track of the tag attributes
          this.pageScope.parentContainerChildren << attrs
      }
}

Now, given the following GSP code:

I get the following HTML generated:

    one
  

    two
  

    three
  

There are some limitations to this strategy. First, any other markup outside of the child tag inside the parent is not going to render how you'd expect. Also, nested parent tags aren't going to work for this implementation unless you make some changes. Finally, this implementation won't support body markup in the child tags; however, given a little tweaking it could be made to do that (I'll leave that as an exercise for the reader).

Despite these limitations, if you are looking to do something like breadcrumbs, tab navigation, or custom list rendering, then this may fit your needs.

Share/Bookmark

I recently had an issue in flex where I needed the click event for a component in an ItemRenderer to not bubble up to the parent list. Since the click event was being dispatched by Flex SDK code, I could not directly do this by passing false into the event’s constructor. I had hoped to find a property I could set on the object, something like “clickBubbles”, which I could set which would accomplish this.

Either that property doesn’t exist or I could not find it. My solution was to basically hijack the event and send an impersonator in its place.

What I ended up doing was writing an event listener function which would stop propagation on the event. It would then dispatch another event with the same properties as the original, except it would set bubbles to false. This will prevent the event from bubbling up to parent components, but still allow event listeners to be added to the component itself.

The following is the function I wrote:

private function removeMouseEventBubble(event:MouseEvent):void {
	// if the event already does not bubble, we don't
	// need to do anything.
	// also, this will prevent any infinite loops from occurring
	if (event.bubbles) {
		// stop the event from being handled by other code
		event.stopImmediatePropagation();

		// dispatch a new event which does not bubble
		event.target.dispatchEvent(
			new MouseEvent(
				event.type, false, event.cancelable,
				event.localX, event.localY,
				event.relatedObject,
				event.ctrlKey, event.altKey,
				event.shiftKey, event.buttonDown,
				event.delta
			)
		);
	}
}

Now, all you need to do is set the click handler on the component:

In order to make sure that this code prevented the original event from propagating and to ensure that it dispatched a similar event which does not bubble, I wrote the following FlexUnit test. N.B. This code is adapted from an actual test, I wouldn’t recommend having the code under test defined in the test case itself, nor do I like the fact that the removeMouseEventBubble function is being added in the test.

public function testShouldRemoveBubbleOnClickButAllowEventListenersToStillFire():void {
	var component:UIComponent = new UIComponent();
	component.addEventListener(
		MouseEvent.CLICK, removeMouseEventBubble
	);

	// if we cannot add other event listeners, then the
	// async function will not get fired and the test will fail.
	component.addEventListener(MouseEvent.CLICK, addAsync(
		function(event:MouseEvent):void {
			assertFalse(event.bubbles);

			// assert that the event was translated properly
			assertEquals(MouseEvent.CLICK, event.type);
			assertTrue(event.cancelable);
			assertEquals(8, event.localX);
			assertEquals(9, event.localY);
			assertEquals(renderer, event.relatedObject);
			assertTrue(event.ctrlKey);
			assertTrue(event.altKey);
			assertTrue(event.shiftKey);
			assertTrue(event.buttonDown);
			assertEquals(5, event.delta);
		}, 1000)
	);

	component.dispatchEvent(
		new MouseEvent(
			MouseEvent.CLICK, true, true, 8,
			9, renderer, true, true, true, true, 5
		)
	);
}

I then wrote a test to verify that the event did not bubble up to the parent:

public function testShouldNotBubbleClickEventToParent():void {
	var parent:UIComponent = new UIComponent();
	parent.addEventListener(MouseEvent.CLICK,
		function(event:MouseEvent):void {
			// this won't cause the test to fail per say,
			// but it will cause an exception to be thrown
			// and this will show up when executing the
			// test.  This will fail the build, especially
			// if run on a CI server like hudson or cruise.
			fail('did not expect event to bubble');
		}
	);

	var child:UIComponent = new UIComponent();
	child.addEventListener(
		MouseEvent.CLICK, removeMouseEventBubble
	);
	parent.addChild(child);

	child.dispatchEvent(new MouseEvent(MouseEvent.CLICK));
}

This solution works, but I was hoping there was something more elegant and less hacky which accomplished the same thing.

Share/Bookmark

50 Cent’s unit test based savings

Unit testing is fairly common these days as more and more people understand the benefits; however, you may still run into a client or manager who is not convinced. These people tend to think unit testing increases development time and cost, or they feel that unit tests are redundant since a QA department is also testing the application. If you’ve ever heard “we don’t have time for unit tests”, “you’re a developer, leave testing to QA”, or “I’m not paying you to write tests” then you know what I’m talking about.

These encounters can be quite frustrating for a developer or project manager who wants to leverage unit testing. While there might be a temptation to just unit test anyway without the blessing of a client or manager, it is more useful to help these people understand why they are mistaken about unit tests. I have found that this misunderstanding is often because they don’t realize that testing is actually a cost saver instead of just an additional cost.

But how to vocalize this point in a way they will understand?

The bottom line is that unit tests save time and therefore money. This is a common stumbling point for people to understand (especially non-technical people) since it is counterintuitive. To them, testing is just “more code” so it has to increase development time and cost. To combat this erroneous perception, it is important to point out how unit tests save time for both developers and QA.

Unit testing reduces the time it takes for the developer to verify their code. Instead of needing to find out if this bit of code which is in the middle of a long workflow works, I can write and run a targeted unit test in less time than it takes to fire up the app, login in, start the workflow, goto the exact spot in the workflow, etc. Since the test is repeatable and automated, writing the test is a one time cost which I can then easily re-run to verify my code at any point in time and for as many times as needed. This becomes an even bigger time saver when code needs to be changed. Everyone makes mistakes, and it is easy to accidentally break something when making a change to several month old code which you didn’t write. Unit tests help ensure that a developer catches any mistakes right when they happen, and allows them to be fixed quickly.

It is at this point that QA is often brought up: “a developer doesn’t need to verify code because QA takes care of that”. At these times, it is important to point out how the QA process is more costly, especially if the issue could have been prevented with a unit test.

If someone in QA notices a problem, they need to stop verifying other parts of the application to deal with the problem. You have just reduced their productivity. Now, the QA person needs to write up a ticket which includes detailed instructions of how to recreate the problem. You have just increased the amount of work needed to be done by QA. Now, the developer gets the ticket and needs to take a look at the issue instead of working on new features. You have just caused the developer to context switch, which reduces their productivity. If the issue is for code the developer wrote a while ago (or didn’t write at all), they need to spend time getting familiar with the code. Again, more context switching and more time spent not adding new features. Even after fixing the issue, the QA person will still need to verify the fix by retesting that same part of the application. The QA person is made even less productive because they are testing that part of the system again instead of parts which haven’t been tested yet.

Now, imagine how much more time is spent if the developer is having problems reproducing the issue or if the QA person notices the problem isn’t really fixed and needs to reopen the issue. You will need to repeat most of that process, further compounding time spent. What happens down the line when code is changed and this specific issue occurs again? Yup, you have to do this whole dance again.

Unit tests won’t prevent this from happening all the time, nor will it handle the kind of complex scenarios and verifications which QA does which are difficult to do in a unit test. However, it will significantly cut down on the number of easily preventable issues which detract QA from doing more important testing (and the developer from focusing on new features). When the developer writes a unit test to prove the issue is fixed, he will be preventing it from happening again in the future (which means time is saved because the issue won’t be reopened or crop back up some point in the future).

Basically, unit tests are a way to automate certain parts of the development and QA process which don’t need to be done by a human every time. This allows a more streamlined process which makes developers and QA people more efficient and productive, and frees them up to focus on things which generate revenue instead of hunting and fixing bugs which didn’t need to be there in the first place.

There are plenty more reasons why unit tests save time (the design benefits coming from TDD is certainly not to be forgotten); however, I have found this example to be the most effective because it is the easiest for non-technical people to visualize the cause and effect relationship unit tests have on the bottom line.

Share/Bookmark

One of the nice extensions available for FlexUnit is the ability to easily unit test event behavior using EventfulTestCase.

This library has support for testing Cairngorm, but unfortunately support is lacking for PureMVC. I searched for existing solutions which added PureMVC notification support, but was not satisfied with their APIs. Luckily, it was not difficult to write some code to support PureMVC which mirrored the API of EventfulTestCase.

The code at the end of this post is a start at duplicating the EventfulTestCase behavior. It doesn’t have all the functionality, but it is enough for simple tests.

Here are the methods which are made available:

• expectNotification(notificationName:String) Sets up the expectation that a notification is sent with the passed name. Can be called multiple times to set the expectation for multiple notifications.
• assertExpectedNotificationsOccurred(userMessage=”) Asserts that all expected notifications were sent. The userMessage parameter indicates an optional message to be prepended for a failure message.
• lastActualNotification Property which represents the last notification which was sent (the last actual notification).

The following is an example of the kind of test you can write:

public class ChuckProxyTest extends PureMvcTestCase
{
    private var chuck:ChuckProxy = new ChuckProxy();

    public function testShouldSendFlashNotificationWhenSeeingTerrorist():void
    {
        var terrorist:Terrorist = new Terrorist();
        expectNotification(ApplicationFacade.FLASHED);

        chuck.lookAt(terrorist);

        // asserts FLASHED notification was sent
        assertExpectedNotificationsOccurred();
        // asserts notification body was the terrorist
        assertEquals(terrorist, lastActualNotification.getBody());
    }
}

Finally, here is the code. Notice the package; you will need to add it to test/org/puremvc/as3/test.

package org.puremvc.as3.test
{
    import flexunit.framework.AssertionFailedError;
    import flexunit.framework.TestCase;

    import org.puremvc.as3.core.View;
    import org.puremvc.as3.interfaces.INotification;
    import org.puremvc.as3.patterns.observer.Observer;

    public class PureMvcTestCase extends TestCase
    {

        private var expectedNotificationNames:Array = [];
        private var actualNotifications:Array = [];

        public function PureMvcTestCase(methodName:String=null)
        {
            super(methodName);
        }

        protected function expectNotification(notificationName:String):void
        {
            assertNotNull('No instance exists for View.getInstance()', View.getInstance());
            expectedNotificationNames.push(notificationName);

            View.getInstance().registerObserver(notificationName, new Observer(
                function(notification:INotification):void {
                    actualNotifications.push(notification);
                },
                null));
        }

        protected function get lastActualNotification():INotification
        {
            if (actualNotifications.length == 0) {
                return null;
            }
            return actualNotifications[actualNotifications.length - 1];
        }

        protected function assertExpectedNotificationsOccurred(userMessage='The expected notifications were not sent'):void
        {
            var actualNotificationNames:Array = [];

            for(var notificationIndex:int = 0; notificationIndex < actualNotifications.length; notificationIndex++) {
                actualNotificationNames.push(actualNotifications[notificationIndex].getName());
            }

            assertArraysEqual(expectedNotificationNames, actualNotificationNames, userMessage);
        }

        protected function assertArraysEqual(expected:Array, actual:Array, userMessage:String = null):void
        {
            var equal:Boolean = (expected.length == actual.length);

            if (equal) {
                for(var i:int = 0; i < actualNotifications.length; i++) {
                    if (expected[i] != actual[i]) {
                        equal = false;
                        break;
                    }
                }
            }

            if (!equal) {
                if (userMessage && userMessage.length > 0) {
                    userMessage += ' - ';
                }

                throw new AssertionFailedError(userMessage + 'Expected: <' + expected + '> but was: <' + actual + '>');
            }
        }
    }
}

Share/Bookmark

For a recent project, I needed to plug some Java code into a Grails app. I wanted to use GORM for persistence, but couldn’t introduce the interfaces, proxies, and factories into the java code which is required for existing solutions to this problem.

Basically, my constraint was that the java code itself couldn’t be altered to work inside the grails app. The solution I came up with is pretty simple, but works well.

The java code delegated to a DAO for persistence (using an interface). Here is what it looked like:

package org.smurf;

import java.util.List;

class SmurfingServiceImpl implements SmurfingService {
    private final SmurfDao smurfDao;

    public SmurfingServiceImpl(SmurfDao smurfDao) {
        this.smurfDao= smurfDao;
    }

    public List listSmurfs() {
        ...
        return smurfDao.findAll();
    }

    public Smurf capture(Smurf smurf) {
        ...
        return smurfDao.update(smurf);
    }
}

I packaged my groovy domain class to be org.smurf.Smurf so that the java code would be using the Grails generated class. Depending on the situation, this could involve a little bit of tweaking to the grails domain object to be compatible with any existing java classes. For this example, we’re assuming an anemic bean so we don’t need to do anything except declare the properties.

package org.smurf
class Smurf {
  String name
  Boolean captured
}

Next, I created an abstract DAO which delegates the sort of CRUD operations you see in a DAO to the GORM object.

package org.smurf;

import java.util.List;

public abstract class GormDelegatingDao {

	protected abstract Class getGormClass();

	public T create(T entity) {
		return update(entity);
	}

	public T retrieve(String id) {
		return (T) invokeClassLevelMethod("get", id);
	}

	public T update(T entity) {
		return (T) entity.invokeMethod("save", new Object[0]);
       }

	public T delete(T entity) {
		return (T) invokeClassLevelMethod("delete", entity.getId());
	}

	public List findAll() {
		return (List) invokeClassLevelMethod("list");
	}

	protected Object invokeClassLevelMethod(String method, Object... args) {
		T instance;

		try {
			instance = getGormClass().newInstance();
		} catch (Exception e) {
			throw new RuntimeException(e);
		}

		return instance.invokeMethod(method, args);
	}
}

After this, I simply needed to implement SmurfDao using this abstract class.

package org.smurf;

class GormSmurfDao extends GormDelegatingDao implements SmurfDao {
	protected Class getGormClass() {
		return Smurf.class;
	}
}

Using spring, we just need to make sure an instance of this class is injected into the SmurfingService. The following is an example using grails-app/conf/spring/resources.xml:

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd">

  <bean class="org.smurf.GormSmurfDao" autowire="constructor"/>

  <bean id="smurfingService" class="org.smurf.SmurfingServiceImpl" autowire="constructor"/>

</beans>

I can now access this service in a controller (or grails service), and it will properly persist my changes without me needing to set up any additional configuration or changing the existing java code.

It is entirely possible to dynamically generate the DAO implementations for each domain class. You could even use a factory and proxy pattern to create them on the fly if you wanted to be really slick.

For a real world application, there are probably operations outside of CRUD which you would need to deal with (e.g. complex finders). Using the general concept presented here, it wouldn’t be difficult to delegate these finders to GORM.

Share/Bookmark

One of the most useful features of ActionController is the ability to add filters before, after, or around actions.  This tool is made even more powerful by the ability to chain filters together.  Allowing an AOP approach is indispensable for addressing cross cutting concerns (or simply separating concerns), and is one of the things which makes a framework valuable to a developer (Spring is an excellent example of this).

A while back, I had a requirement to persist a record of which email addresses were sent an email through the system.  I expected to find callback support for ActionMailer, but was surprised to find that it didn’t exist.

I had three options: put the logic inline in each ActionMailer method which is not DRY and muddles concerns, put the logic in the ActionContoller as filters which break encapsulation in terrible ways (and is at the wrong layer), or extend ActionMailler to allow callback methods.

I choose the latter…

I created a simple plugin which allows you to add before and after deliver callbacks to ActionMailer, and constrain them to certain methods using nly and :except options ala ActionController‘s filters.

You can add the plugin by executing the following in your rails app directory:

script/plugin install git://github.com/AnthonyCaliendo/action_mailer_callbacks.git

Here is a snipet from the readme:

There are 2 main ways to define a callback. In each case, the callback method/block is passed the mail object as the
only argument.

You may define a callback using a block:
class FooMailer < ActionMailer::Base
  after_deliver do |mail|
    ...
  end
end

You may also define a callback using a symbol/string for a method name:
class FooMailer < ActionMailer::Base
  before_deliver :append_advertisement

  def append_advertisement(mail)
    ...
  end
end

Callbacks take options which can be used to define which mail types (i.e. methods) they will be applied to.
These options take the format of *only* and *except*.
  - An *only* callback will only be run for methods which match the passed method names.
  - An *except* callback will be called for all methods EXCEPT those that match the passed method names
The options can take either an array of strings/symbols, or a single string/symbol.

class FooMailer < ActionMailer::Base
  before_deliver :append_disclaimer,  nly => [:email_friend, :announce_something]
  after_deliver :notify_user, :except => :invite_user

 ...
end

== What About Halting the Chain?

You can halt the chain in either a before or after callback.  In order to do this, just call +halt_callback_chain+ in
the block (or +self.class.halt_callback_chain+ in an instance method).
If the chain is halted in a before callback, the email will *NOT* be delivered and no other callbacks will be invoked
(either any after callbacks or any remaining before callbacks).
If the chain is halted in an after callback, the email will have already been sent and all before callbacks would have
run, but any remaining after callbacks will not be invoked.

class FooMailer < ActionMailer::Base
  before_deliver do |mail|
    halt_callback_chain if invalid_mail?(mail)
  end

  after_deliver :abort

  def abort(mail)
    self.class.halt_callback_chain
  end
end

I wanted to keep usage similar to how filters are handled in ActionController, so I decided against using the return value of the callback to halt the chain. Instead, you explicitly halt the chain similar to how rendering or redirecting halts a before_filter chain in a controller.

I am hosting the code on github at http://github.com/AnthonyCaliendo/action_mailer_callbacks/tree/master. I was time constrained when I wrote this, but I will be cleaning up the code once I get a chance (I promise!).

I wrote this code months ago (just now got around to blogging about it and releasing it to github), but while researching this blog post I saw that someone else came up with a similar plugin at http://github.com/kelyar/mailer_callbacks/tree/master. Kelyar’s plugin seems more limited than the one I am providing (plus, there are no tests… tsk tsk!), but it is cleaner and simpler. It may be worth taking a look at that as well.

Share/Bookmark