<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: Swiz Passive View Example :: Part 2</title>
	<atom:link href="http://www.webappsolution.com/wordpress/2010/01/07/swiz-passive-view-example-part-2/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.webappsolution.com/wordpress/2010/01/07/swiz-passive-view-example-part-2/</link>
	<description>When you're in need of an appsolution</description>
	<pubDate>Wed, 19 Jun 2013 08:06:46 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7.1</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Aaron West</title>
		<link>http://www.webappsolution.com/wordpress/2010/01/07/swiz-passive-view-example-part-2/comment-page-1/#comment-1306</link>
		<dc:creator>Aaron West</dc:creator>
		<pubDate>Thu, 22 Jul 2010 22:07:51 +0000</pubDate>
		<guid isPermaLink="false">http://www.webappsolution.com/wordpress/?p=727#comment-1306</guid>
		<description>We're using a ServiceLocator in a decent sized AIR application after reading this post. The pattern definitely helped us solve the problem of mock vs local vs staging vs production execution. Some developers simply aren't involved in the server-side code creation, so they run the app in what we're calling "mock" mode. This mode feeds the app with data from local XML files.

To maximize the benefit of a ServiceLocator we've defined 5 different XML files that match to each run mode: mock, local-only, staging, production and current. "Current" isn't really a run mode, but instead is what the app uses each time it fires up. Separating these run modes from the current mode has given us the flexibility to run any service in any mode. One service can be fed from mock XML data while another can be fed from the local server-side system.

Or, we can copy all the XML from one of the files - mock.xml for instance - and paste the XML into current.xml setting all services to use mock data.

The only downside to this method that I can see is the additional workload it puts on the developers. Whenever we introduce a new service or a new method of a service we have to write the service handler at least twice. Once to retrieve and use mock data from XML and once to retrieve and use data from the server.

In my opinion the flexibility gained from ServiceLocators is worth the extra service programming.</description>
		<content:encoded><![CDATA[<p>We&#8217;re using a ServiceLocator in a decent sized AIR application after reading this post. The pattern definitely helped us solve the problem of mock vs local vs staging vs production execution. Some developers simply aren&#8217;t involved in the server-side code creation, so they run the app in what we&#8217;re calling &#8220;mock&#8221; mode. This mode feeds the app with data from local XML files.</p>
<p>To maximize the benefit of a ServiceLocator we&#8217;ve defined 5 different XML files that match to each run mode: mock, local-only, staging, production and current. &#8220;Current&#8221; isn&#8217;t really a run mode, but instead is what the app uses each time it fires up. Separating these run modes from the current mode has given us the flexibility to run any service in any mode. One service can be fed from mock XML data while another can be fed from the local server-side system.</p>
<p>Or, we can copy all the XML from one of the files - mock.xml for instance - and paste the XML into current.xml setting all services to use mock data.</p>
<p>The only downside to this method that I can see is the additional workload it puts on the developers. Whenever we introduce a new service or a new method of a service we have to write the service handler at least twice. Once to retrieve and use mock data from XML and once to retrieve and use data from the server.</p>
<p>In my opinion the flexibility gained from ServiceLocators is worth the extra service programming.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Swiz 1.0 RC1 Removes [Autowire( view="true" )] - Requires New AbstractViewMediator &#124; Web App Solution Blog</title>
		<link>http://www.webappsolution.com/wordpress/2010/01/07/swiz-passive-view-example-part-2/comment-page-1/#comment-1097</link>
		<dc:creator>Swiz 1.0 RC1 Removes [Autowire( view="true" )] - Requires New AbstractViewMediator &#124; Web App Solution Blog</dc:creator>
		<pubDate>Tue, 20 Apr 2010 12:26:24 +0000</pubDate>
		<guid isPermaLink="false">http://www.webappsolution.com/wordpress/?p=727#comment-1097</guid>
		<description>[...] the corner I figured I&#8217;d pull down the latest code from github, do a build, and then migrate my previous examples of Swiz and the Passive View to the latest SWC. I obviously ran into a couple of small changes between Swiz 0.6.4 and 1.0, but [...]</description>
		<content:encoded><![CDATA[<p>[...] the corner I figured I&#8217;d pull down the latest code from github, do a build, and then migrate my previous examples of Swiz and the Passive View to the latest SWC. I obviously ran into a couple of small changes between Swiz 0.6.4 and 1.0, but [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
