<?xml version="1.0" encoding="utf-8"?>
			
			<rss version="2.0">
			<channel>
			<title>Aria Media - model-glue</title>
			<link>http://aria-media.com/blog/index.cfm</link>
			<description></description>
			<language>en-us</language>
			<pubDate>Sat, 04 Sep 2010 17:59:18 -0700</pubDate>
			<lastBuildDate>Mon, 01 Jan 2007 13:47:00 -0700</lastBuildDate>
			<generator>BlogCFC</generator>
			<docs>http://blogs.law.harvard.edu/tech/rss</docs>
			<managingEditor>d.nando@gmail.com</managingEditor>
			<webMaster>d.nando@gmail.com</webMaster>
			
			
			
			
			
			<item>
				<title>Transfer is Cool</title>
				<link>http://aria-media.com/blog/index.cfm/2007/1/1/Transfer-is-Cool</link>
				<description>
				
				Transfer is an object-relational mapping framework, which means that takes care of all your CRUD operations for you.  Recently, I watched a &lt;a href=&quot;http://www.compoundtheory.com/?action=displayPost&amp;ID=164&quot;&gt;presentation&lt;/a&gt; that Mark Mandel (the author of the framework) gave, and got curious. So I decided to give Transfer a try with a small MG app I&apos;m working on, and I&apos;m really enjoying it.

Brian Rinaldi has written up a &lt;a href=&quot;http://www.remotesynthesis.com/blog/index.cfm/2006/10/22/Building-an-Application-with-Transfer-ORM&quot;&gt;tutorial&lt;/a&gt; that&apos;s also good introduction to the framework.

Transfer is configured with a few XML files (rather than using introspection as Reactor does), which is a little more work up front than Reactor. But what i read is that Brian&apos;s Illudium PU-36 Code Generator can handle creating the XML files for you. I haven&apos;t had a chance to try that yet tho&apos;.

I&apos;m finding it very easy to get up to speed using the framework. And it provides an easy way to extend the functionality of its generated Transfer Objects via the use of decorators. Sounds complex, but it&apos;s not. You just write a CFC with the added functions you want in your Transfer Object, and glue them together in the tranfer.xml config file using the decorator attribute of the object tag. 

There&apos;s a lot of functionality in Transfer that i haven&apos;t even explored yet. It&apos;s at a 0.6 release, but seems very solid to me somehow. So i&apos;m giving it a complete go with an eye to putting it to work in a production site.
				
				</description>
				
				<category>model-glue</category>
				
				<pubDate>Mon, 01 Jan 2007 13:47:00 -0700</pubDate>
				<guid>http://aria-media.com/blog/index.cfm/2007/1/1/Transfer-is-Cool</guid>
				
			</item>
			
		 	
			
			
			<item>
				<title>Model-Glue and Reactor Divorce!</title>
				<link>http://aria-media.com/blog/index.cfm/2006/12/29/ModelGlue-and-Reactor-Divorce</link>
				<description>
				
				In a sign of the times to come, Model-Glue and Reactor divorced on December 22, according to the change log on the Unity SVN repository. 

Apparently, rumor has it that MG was having an affair with another ORM framework named Transfer, and Reactor, well, &lt;i&gt;reacted&lt;/i&gt; and promptly filed for divorce. Joe Rinehart made it final on December 22 by pulling Reactor&apos;s configuration from the sample application template as well as removing the Reactor-specific portions from MG&apos;s core configuration file.

Said Joe, &quot;Everyone thought it was a marriage made in heaven, but I guess it wasn&apos;t meant to be.&quot;

Model-Glue wouldn&apos;t speak with us concerning the breakup, but when contacted, Reactor shared the following:

&quot;Look, I know I reacted pretty strongly back then when I first found out about MG and his new, ehem, &lt;i&gt;ORM&lt;/i&gt;, but I guess I&apos;m OK now. We&apos;re still gonna work together tho&apos;. We&apos;re just not &lt;i&gt;married&lt;/i&gt; anymore. Looking back, I guess we were too tightly coupled.&quot;

Pressed for details about how they were going to continue their working relationship in the future, Reactor confided:

&quot;Well, let&apos;s just say that for now, you can add the ORM   configuration information in the ColdSpring.xml file of your MG app yourself, like this ...&quot;

&lt;code&gt;
&lt;!-- Defines which ORM service to use with MG 
	(Reactor, Transfer, Michelle, Roxy, etc) --&gt;
&lt;bean id=&quot;ormAdapter&quot; class=&quot;ModelGlue.unity.orm.ReactorAdapter&quot;&gt;
	&lt;constructor-arg name=&quot;framework&quot;&gt;&lt;ref bean=&quot;ModelGlue&quot; /&gt;&lt;/constructor-arg&gt;
&lt;/bean&gt;
  
&lt;!-- Defines the ORM service itself --&gt;
&lt;bean id=&quot;ormService&quot; class=&quot;reactor.reactorFactory&quot;&gt;
	&lt;constructor-arg name=&quot;configuration&quot;&gt;&lt;ref bean=&quot;reactorConfiguration&quot; /&gt;&lt;/constructor-arg&gt;
&lt;/bean&gt;
&lt;/code&gt;

Indeed, Reactor&apos;s tip was very timely. We noticed we got a nasty error without these additional bean definitions in place using the latest build of Unity downloaded from SVN.

&quot;And you might need an example of MY configuration, which still goes in ColdSpring.xml like before (sigh) ...&quot;, Reactor continued.

&lt;code&gt;
&lt;!-- This is your Reactor configuration --&gt;
&lt;bean id=&quot;reactorConfiguration&quot; class=&quot;reactor.config.config&quot;&gt;
	&lt;constructor-arg name=&quot;pathToConfigXml&quot;&gt;&lt;value&gt;/modelglueapplicationtemplate/config/Reactor.xml&lt;/value&gt;&lt;/constructor-arg&gt;
	&lt;property name=&quot;dsn&quot;&gt;&lt;value&gt;thedsn&lt;/value&gt;&lt;/property&gt;
	&lt;property name=&quot;type&quot;&gt;&lt;value&gt;mysql&lt;/value&gt;&lt;/property&gt;
	&lt;property name=&quot;mapping&quot;&gt;&lt;value&gt;/modelglueapplicationtemplate/model/data&lt;/value&gt;&lt;/property&gt;
	&lt;!-- development or production --&gt;
	&lt;property name=&quot;mode&quot;&gt;&lt;value&gt;development&lt;/value&gt;&lt;/property&gt;
&lt;/bean&gt;
&lt;/code&gt;

We asked Reactor what she thought of the name &apos;Unity&apos; going forward, now that MG was also going with Transfer. 

&quot;Look, if you&apos;re asking if the 3 of us are going to move in together on the same server, you can just FORGET IT!&quot;

She paused a moment, staring across the room ...

&quot;I guess somebody&apos;s gonna tell me I&apos;m over-reacting again, huh?&quot;

Nah ... ;-)
				
				</description>
				
				<category>model-glue</category>
				
				<pubDate>Fri, 29 Dec 2006 23:38:00 -0700</pubDate>
				<guid>http://aria-media.com/blog/index.cfm/2006/12/29/ModelGlue-and-Reactor-Divorce</guid>
				
			</item>
			
		 	
			
			
			<item>
				<title>The Mystery of AutoWiring in Model-Glue Unity</title>
				<link>http://aria-media.com/blog/index.cfm/2006/9/22/The-Mystery-of-AutoWiring</link>
				<description>
				
				I&apos;ve been playing with Model-Glue Unity on and off over the past few months, and i thought i&apos;d start a blog to help me learn. Maybe i can help a few others learn something too.

One of the things that seems to stump people trying to learn MG is the autowiring feature. Many people might not even know it exists, because it&apos;s not very clearly explained in the documentation as of yet. To use autowiring, you need to mess a little with ColdSpring. ColdSpring calls everything by a different name, so that makes it seem kind of foreign in the beginning. A CFC is called a bean, a struct is called a map, an array is called a list, and so on. But once you translate the terms used and get to know your way around a little, it suddenly can seem very easy to use.

Simply put, autowiring is a very handy way to inject instantiated CFC&apos;s into your controllers using ColdSpring.
				 [More]
				</description>
				
				<category>model-glue</category>
				
				<category>newbie cafe</category>
				
				<pubDate>Fri, 22 Sep 2006 00:00:00 -0700</pubDate>
				<guid>http://aria-media.com/blog/index.cfm/2006/9/22/The-Mystery-of-AutoWiring</guid>
				
			</item>
			
		 	
			</channel></rss>