Comments on: When dynamic programming backfires http://swordsystems.com/2009/11/20/when-dynamic-properties-backfire/ Cutting Commentary Thu, 10 Jun 2010 04:30:51 +0000 http://wordpress.org/?v=abc hourly 1 By: noah http://swordsystems.com/2009/11/20/when-dynamic-properties-backfire/comment-page-1/#comment-10 noah Fri, 20 Nov 2009 15:27:17 +0000 http://swordsystems.com/?p=35#comment-10 Add it to the metaClass: controller.metaClass.params = [my:'params'] Easy peasey. Add it to the metaClass:

controller.metaClass.params = [my:'params']

Easy peasey.

]]> By: eric http://swordsystems.com/2009/11/20/when-dynamic-properties-backfire/comment-page-1/#comment-9 eric Fri, 20 Nov 2009 06:35:21 +0000 http://swordsystems.com/?p=35#comment-9 After further testing, it looks like the controller.request.parameters technique does not work within a ControllerUnitTestCase. You do have to add items to controller.params directly. However, you can set controller.request.parameters in integration tests (as the blog post that I reference above indicates) and the data will be available via the params call within the controller. You can also set the controller.params directly with integration tests. Anyone who wants to dig into exactly why there is a difference is more than welcome. Personally, I'm calling it a night. After further testing, it looks like the controller.request.parameters technique does not work within a ControllerUnitTestCase. You do have to add items to controller.params directly. However, you can set controller.request.parameters in integration tests (as the blog post that I reference above indicates) and the data will be available via the params call within the controller. You can also set the controller.params directly with integration tests.

Anyone who wants to dig into exactly why there is a difference is more than welcome. Personally, I’m calling it a night.

]]>