Comments on: Swiz Autowire View

By: Rupert

Rupert — Tue, 16 Feb 2010 03:29:28 +0000

Great Sönke I will keep an eye on swiz site for 1.0 release.
best wishes and good luck!

By: Sönke

Sönke — Tue, 16 Feb 2010 03:11:04 +0000

I am glad that you like Swiz and yes, it feels so good when you come from Cairngorm and can get rid of all this boiler plate code!
swizframework.org should have all main docs. For further information try the blogs of the Swiz team members and examples listed on swizframework.org.

Swiz 1.0 is around the corner so be sure to get tons of new docs and examples soon.
However, this should not stop you from using 0.6.4 and when 1.0 is ready the transition should be pretty easy.

By: Rupert

Rupert — Tue, 16 Feb 2010 03:03:52 +0000

Ok, thanks a lot Sönke. I am taking my first steps with Swiz and I find it very interesting, ligthyears ahead from Cairngorm2 (which I used a few times). I wonder if there is some documentation available about all this Swiz tags features. I have already browsed swizframework.org and read the examples but I think they not cover all the nice features Swiz offers. I don’t want to sound ungrateful like demanding more documentation I see swiz team efford and goodwill, just asking if you could recommend some posts, lectures, books or whatever.

best regards.

By: Sönke

Sönke — Tue, 16 Feb 2010 01:23:46 +0000

Rupert, currently Swiz only support autowire view by type so you would have to subclass Panel to inject them by type into different mediators.

By: Rupert

Rupert — Tue, 16 Feb 2010 01:12:19 +0000

Hi I wonder if it’s possible to wire two different view instances to two different view mediators.
I mean:
mediator1—–>employeesPanel(Panel)
mediator2—–>productsPanel(Panel)

where mediator1 and 2 are instances of different mediator classes and employeesPanel and productsPanel are instances of Panel.
Is it posible to specify an id on the autowire tag?
Hope I have expressed myself correctly.

By: Matt Ganski

Matt Ganski — Fri, 05 Feb 2010 18:28:33 +0000

This is great. I understand its not an MVC best practice to do this in controllers. However, in my project, I have classes that are non views, yet they can ask the controller to make service calls. Since the class is a non view class, it must be declared as a bean in order for me to mediate events. I found myself using a public property setter to set a reference to a view in my application. Now with this, no setter necessary, I can inject the view I want right in when it’s created. Thanks!

By: flashscope components

flashscope components — Wed, 09 Sep 2009 21:59:22 +0000

@Sönke,wow. I’ll try to use it right now and let you know the result.

By: him_aeng

him_aeng — Fri, 17 Jul 2009 06:06:35 +0000

I think this is the solution of my scenario. I use Flash CS3 .swc file that publish from Flex Component Kit.

When I use this flash view I have to add many line of “addEventListener” and check for the frame was entered or not? (if the frame was not entered, its child component was not instantiate).

So, with swiz ViewPackage I can separate the “addEventListener” code to another file even though it promote tightly coupling pattern but for flash component view I think swiz viewPackage is nice solution.

awesome guy.

By: Borek

Borek — Sun, 24 May 2009 19:29:27 +0000

Hi Sönke,

I will post into the Swiz Google Group with a sample project when I have time. Basically, what I would love to see is support for this:

[Autowire(view="true")]
public var myView : IMyView;

Swiz currently supports only concrete type like MyView which makes the Presenter tightly coupled to the View which is not good practice and it also makes testing of such presenter hard.

Cheers,
Borek

By: Sönke

Sönke — Sun, 24 May 2009 15:15:16 +0000

Hi JB,
I think it really depends on the style you want to code and if you like code behind you are free to use it this way. However, we don’t want Swiz to be understood as code behind technology. I think the beauty of Swiz is the flexibility which enables developers to code how they want and how it fits best to solve a given problem.
What do you think about the example I made with “decoupling” the drag handler from the view?