<?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"
	>
<channel>
	<title>Comments on: Mate, an unobtrusive Flex application framework</title>
	<atom:link href="http://blog.iconara.net/2008/05/06/mate-an-unobtrusive-flex-application-framework/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.iconara.net/2008/05/06/mate-an-unobtrusive-flex-application-framework/</link>
	<description></description>
	<pubDate>Wed, 20 Aug 2008 03:18:35 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6</generator>
		<item>
		<title>By: bjorn</title>
		<link>http://blog.iconara.net/2008/05/06/mate-an-unobtrusive-flex-application-framework/#comment-6721</link>
		<dc:creator>bjorn</dc:creator>
		<pubDate>Tue, 13 May 2008 10:29:03 +0000</pubDate>
		<guid isPermaLink="false">http://blog.iconara.net/?p=190#comment-6721</guid>
		<description>Mate looks very interesting. Especially the view/model binding architechture looks like it could work very well (compared to Cairngorm, which is what I've used before).

Thanks for the tip Theo! This must have passed my flex-framework radar somehow :-)</description>
		<content:encoded><![CDATA[<p>Mate looks very interesting. Especially the view/model binding architechture looks like it could work very well (compared to Cairngorm, which is what I&#8217;ve used before).</p>
<p>Thanks for the tip Theo! This must have passed my flex-framework radar somehow :-)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Theo</title>
		<link>http://blog.iconara.net/2008/05/06/mate-an-unobtrusive-flex-application-framework/#comment-6686</link>
		<dc:creator>Theo</dc:creator>
		<pubDate>Thu, 08 May 2008 17:25:06 +0000</pubDate>
		<guid isPermaLink="false">http://blog.iconara.net/?p=190#comment-6686</guid>
		<description>Again, thanks for the clarification. I didn't realise that you set up the bindings behind the scenes when the views were created, I thought you somehow kept track of the views and pushed the new data in (which would be "bindings" too, just not the Flex framework's bindings). Now it makes perfect sense that you use the class instead of instance references.</description>
		<content:encoded><![CDATA[<p>Again, thanks for the clarification. I didn&#8217;t realise that you set up the bindings behind the scenes when the views were created, I thought you somehow kept track of the views and pushed the new data in (which would be &#8220;bindings&#8221; too, just not the Flex framework&#8217;s bindings). Now it makes perfect sense that you use the class instead of instance references.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nahuel</title>
		<link>http://blog.iconara.net/2008/05/06/mate-an-unobtrusive-flex-application-framework/#comment-6682</link>
		<dc:creator>Nahuel</dc:creator>
		<pubDate>Thu, 08 May 2008 06:10:02 +0000</pubDate>
		<guid isPermaLink="false">http://blog.iconara.net/?p=190#comment-6682</guid>
		<description>The injectors are mapping to classes because we don't want to have a direct reference to the views.
The views can be instantiated very late in the application or may never be created and the injectors are just waiting there just in case they are created. Or you can create multiple instances of the same view and the injectors will get notified for each. That's why we use classes, because we want a notification for all the instances that are created from that class at any time in the application.

Mate by default notifies they injectors every time that a view fire the "creationComplete" event. As you may know this event is triggered only once after the view is ready. The injectors get a reference of that instantiated view and bind the properties via the injector tag. You can also add other actions inside the injectors that can do others things if you need, for example keep a reference to that view or register for events in that view, etc.

As I mentioned, by default, we listen for the "creationComplete" event, but you can overwrite that with the InjectorsSettings tag (this tag applies changes globally to all the injectors). For example, you can listen for "initialize" or any other event, even a custom event. In addition you can turn "autoWire" to false and they won't listen for anything. If "autoWire" is false, you will need to register the views by hand.  When registering by hand, you also have the ability to pass a unique identifier (useful when you have multiple instances of the same view), but that is another chapter :)
As you can see, you can have a lot of control of how the views are injected, but I think that 70% of the people will not need to go deep, so we made the default behavior simple for them.</description>
		<content:encoded><![CDATA[<p>The injectors are mapping to classes because we don&#8217;t want to have a direct reference to the views.<br />
The views can be instantiated very late in the application or may never be created and the injectors are just waiting there just in case they are created. Or you can create multiple instances of the same view and the injectors will get notified for each. That&#8217;s why we use classes, because we want a notification for all the instances that are created from that class at any time in the application.</p>
<p>Mate by default notifies they injectors every time that a view fire the &#8220;creationComplete&#8221; event. As you may know this event is triggered only once after the view is ready. The injectors get a reference of that instantiated view and bind the properties via the injector tag. You can also add other actions inside the injectors that can do others things if you need, for example keep a reference to that view or register for events in that view, etc.</p>
<p>As I mentioned, by default, we listen for the &#8220;creationComplete&#8221; event, but you can overwrite that with the InjectorsSettings tag (this tag applies changes globally to all the injectors). For example, you can listen for &#8220;initialize&#8221; or any other event, even a custom event. In addition you can turn &#8220;autoWire&#8221; to false and they won&#8217;t listen for anything. If &#8220;autoWire&#8221; is false, you will need to register the views by hand.  When registering by hand, you also have the ability to pass a unique identifier (useful when you have multiple instances of the same view), but that is another chapter :)<br />
As you can see, you can have a lot of control of how the views are injected, but I think that 70% of the people will not need to go deep, so we made the default behavior simple for them.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Theo</title>
		<link>http://blog.iconara.net/2008/05/06/mate-an-unobtrusive-flex-application-framework/#comment-6677</link>
		<dc:creator>Theo</dc:creator>
		<pubDate>Tue, 06 May 2008 23:17:18 +0000</pubDate>
		<guid isPermaLink="false">http://blog.iconara.net/?p=190#comment-6677</guid>
		<description>Good to know, thanks for the clarification. I did have a hard time understanding exactly what was going on, because the framework is heavily event driven there is quite a lot of indirection and that makes it hard to follow the code. It's not a bad thing though, it makes for a more decoupled architecture, but it does get harder to understand.

I was also a bit confused why and how the injectors reference the views by their class, I can't find how the lookup is being done, where the mapping of that class to actual instances take place. Perhaps you could clarify that too? (Perhaps this is a question for your forum, but as long as I have your attention...)

Your Model Adapter sounds a lot like the Presentation Model pattern which I have begun to use a lot, I think it's a very good fit in a Flex architecture.</description>
		<content:encoded><![CDATA[<p>Good to know, thanks for the clarification. I did have a hard time understanding exactly what was going on, because the framework is heavily event driven there is quite a lot of indirection and that makes it hard to follow the code. It&#8217;s not a bad thing though, it makes for a more decoupled architecture, but it does get harder to understand.</p>
<p>I was also a bit confused why and how the injectors reference the views by their class, I can&#8217;t find how the lookup is being done, where the mapping of that class to actual instances take place. Perhaps you could clarify that too? (Perhaps this is a question for your forum, but as long as I have your attention&#8230;)</p>
<p>Your Model Adapter sounds a lot like the Presentation Model pattern which I have begun to use a lot, I think it&#8217;s a very good fit in a Flex architecture.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Nahuel</title>
		<link>http://blog.iconara.net/2008/05/06/mate-an-unobtrusive-flex-application-framework/#comment-6675</link>
		<dc:creator>Nahuel</dc:creator>
		<pubDate>Tue, 06 May 2008 16:31:35 +0000</pubDate>
		<guid isPermaLink="false">http://blog.iconara.net/?p=190#comment-6675</guid>
		<description>Hi Theo,
Thank you so much for your comments. I just wanted to point out that the injectors are binding the model with the view if the source is bindable (extending from EventDispatcher). The difference is that we don't have a reference from the view to the model as in model.getInstance(). Instead, we bind the properties that we want from outside the view using the injectors.
In addition, sometimes we use a Model Adapter when the view is more complicated and it needs "massaged" data instead of the raw data. In this second option, the adapter is injected and the view binds to the adapter. An example of this is in the weather widget example (http://mate.asfusion.com/page/examples/weather-widget). The code there can be simplified by using public variables, but we wanted to make our Model Manager a bit more explicit and only let other components get the data but not be able to set it.

By the way, the site is up again now. ￼</description>
		<content:encoded><![CDATA[<p>Hi Theo,<br />
Thank you so much for your comments. I just wanted to point out that the injectors are binding the model with the view if the source is bindable (extending from EventDispatcher). The difference is that we don&#8217;t have a reference from the view to the model as in model.getInstance(). Instead, we bind the properties that we want from outside the view using the injectors.<br />
In addition, sometimes we use a Model Adapter when the view is more complicated and it needs &#8220;massaged&#8221; data instead of the raw data. In this second option, the adapter is injected and the view binds to the adapter. An example of this is in the weather widget example (http://mate.asfusion.com/page/examples/weather-widget). The code there can be simplified by using public variables, but we wanted to make our Model Manager a bit more explicit and only let other components get the data but not be able to set it.</p>
<p>By the way, the site is up again now. ￼</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Theo</title>
		<link>http://blog.iconara.net/2008/05/06/mate-an-unobtrusive-flex-application-framework/#comment-6674</link>
		<dc:creator>Theo</dc:creator>
		<pubDate>Tue, 06 May 2008 14:36:55 +0000</pubDate>
		<guid isPermaLink="false">http://blog.iconara.net/?p=190#comment-6674</guid>
		<description>I really doubt that me writing about it would have any /. effect, but it really looks like the site has gone down since this morning.</description>
		<content:encoded><![CDATA[<p>I really doubt that me writing about it would have any /. effect, but it really looks like the site has gone down since this morning.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kapil Viren Ahuja</title>
		<link>http://blog.iconara.net/2008/05/06/mate-an-unobtrusive-flex-application-framework/#comment-6671</link>
		<dc:creator>Kapil Viren Ahuja</dc:creator>
		<pubDate>Tue, 06 May 2008 10:26:30 +0000</pubDate>
		<guid isPermaLink="false">http://blog.iconara.net/?p=190#comment-6671</guid>
		<description>Either the link you have provided is incorrect or the site  is down</description>
		<content:encoded><![CDATA[<p>Either the link you have provided is incorrect or the site  is down</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Dynamic Page Served (once) in 0.402 seconds -->
