In order to help myself to better visualize the whole framework I’ve created a PDF based on your slides. Hope it can help others as well:
http://blog.grifo.tv/2011/02/0…/

Cheers
Danilo

“you should not target low coupling, instead target appropriate coupling” – Mike Labriola (@mlabriola)

I've always liked that quote on the subject.

2. I have no issues with creating lots of extra classes for expressiveness. Extending Signal has several benefits. You can type the expected value objects in the Super constructor, and it eliminated the need to use named injections in your mappings. I don't use named injections at all. Ever. I will always favor extending a base class, even if it is to simply “mark” a class for injection. I find this to be much cleaner in general, and I don't mind the extra classes in my structure.

A couple of questions:

1. I always thought that services shouldn't be coupled to models (slide 126?)

2. On a recent project i used a service to load up xml data and pass eventually to the
view. It seemed though for a very long runaround to get the data to the view.
(command asks service to load data,service loads parses data dispatches event,
command takes event and transfers data to the model -> command dispatches that
model has been updated,mediator updates view with data) vs. mediator listens for
service event and transferring the data to the view. In this case all the model was
doing is carrying a bunch of public vars. I don't know if i'm doing this right. Any
thoughts/suggestions?

3. On your as3signals demo it seemed that you still had to create a custom class for your
signal. I thought that signals was suppose to get rid of that need. what's the benefit of
using signals in the robotlegs framework over events -i guess besides the strict typing?

“you should not target low coupling, instead target appropriate coupling” – Mike Labriola (@mlabriola)

I've always liked that quote on the subject.

2. I have no issues with creating lots of extra classes for expressiveness. Extending Signal has several benefits. You can type the expected value objects in the Super constructor, and it eliminated the need to use named injections in your mappings. I don't use named injections at all. Ever. I will always favor extending a base class, even if it is to simply “mark” a class for injection. I find this to be much cleaner in general, and I don't mind the extra classes in my structure.

A couple of questions:

1. I always thought that services shouldn't be coupled to models (slide 126?)

2. On a recent project i used a service to load up xml data and pass eventually to the
view. It seemed though for a very long runaround to get the data to the view.
(command asks service to load data,service loads parses data dispatches event,
command takes event and transfers data to the model -> command dispatches that
model has been updated,mediator updates view with data) vs. mediator listens for
service event and transferring the data to the view. In this case all the model was
doing is carrying a bunch of public vars. I don't know if i'm doing this right. Any
thoughts/suggestions?

3. On your as3signals demo it seemed that you still had to create a custom class for your
signal. I thought that signals was suppose to get rid of that need. what's the benefit of
using signals in the robotlegs framework over events -i guess besides the strict typing?