VO, Model and event dispatching

Visnik's Avatar


05 May, 2011 04:20 PM

I am new to Robot legs, been playing with it for about a week, and I had a question am hopping someone would be nice enough to clarify, offer advice or point me in the right direction. I am building a flex app to play around with the RL framwork, I created a Model object and it references multiple Value Objects. I am having my command(s) update the Value Objects through the Model. Once a given value is updated in a particular VO, I want to dispatch an event from the VO for a mediator to listen for. I was thinking I should extend the VO with the Actor Class so the event with within the RL framwork. This threw an error. Can this be done, or should I think about a traditional binding approach?


  1. 1 Posted by Jos Yule on 05 May, 2011 05:41 PM

    Jos Yule's Avatar

    Well, you might want to just have the Model itself send out a specific event for each VO which is updated, or a generic "update" event, with the VO included in the event (as a data member).

    VOs are, generally, supposed to be pretty dumb. Make the model do the work! :)


  2. 2 Posted by Inxentas on 07 May, 2011 11:04 AM

    Inxentas's Avatar

    I'm currently using Zend AMF to pull entities from a server. While these do not extend Actor, I do store and organize them in a model. In my case, a single model with a few VO members are sufficient. VO's are indeed supposed to be dumb. Most of mine have a few getters to turn unix timestamps into more usefull Date objects. They generally don't even extend anything unless it's really needed, usefull, or represents serverside-defined inheritance. In that case I just map the base classes.

    A conceptual flow would be like this...

    1) Through event mediation a Command is executed.
    2) The Command does work on an injected Actor.
    3) The Model or Command dispatches a relevant event.
    4) Mediators work their magic on the view.

    Just to clarify (3): I generally dispatch from a Command if the operation is instant. I dispatch from a Model when it's not. Since AMF works with Responders instead of an EventListener, doing it from a Command is just a preference. A Model is probably more suitable in most cases, but in both cases you use the dispatch() method so it doesn't matter as far as RL is concerned internally. I merely extend Actor in order to be able to use dependancy injection.

    I also use the method Jos Yule suggested: dispatching custom events with VO's (or collections of VO's). I kinda abuse public static constants to define the context of that dispatch, and wire those together in the Context.

    I hope this contribution is usefull. I am a fresh RL user myself so feel free to correct me on my current practices.

  3. 3 Posted by Inxentas on 09 May, 2011 09:06 AM

    Inxentas's Avatar

    I just wanted to add the following:

    I was curious as to why you got an error when extending Actor with your VO's. I was able to do so without to many problems. In my case I'd rather store VO's inside a model, because when I send the VO back to the server it will have all the inherited properties from the Actor class. That means my server-side code will have to expect a property named 'eventDispatcher' which is kinda silly if you think about it.

    I have no idea why you got an error in the first place, technically it should be possible for VO's to extend Actor (I just wouln't recommend it). Maybe an issue with your constructors?

  4. Support Staff 4 Posted by Stray on 11 May, 2011 08:30 AM

    Stray's Avatar

    Hi Visnik,

    I just wanted to echo what the others said: VO implies a fairly dumb container object. Possibly one that is read-only, but definitely not something that is bindable or fires events (binding creates events).

    If what you really want is something more active than a VO that's your decision, but don't call it a VO because the purpose of these patterns / terms etc is so that any 2 developers can have a conversation and have common understanding without having to describe every part in detail.

    It's a bit like deciding to call a dog 'cat'. It's going to lead to confusion at some point!

    I'm guessing you got the error when you extended Actor because you weren't using the injector to create the VOs. Injection isn't magic - it's basically a very smart factory approach - so you have to use the factory (the injector) to create or 'finish' your objects that have injections.

    Let us know how you got on,


  5. 5 Posted by Inxentas on 16 May, 2011 06:01 PM

    Inxentas's Avatar

    I've been doing some tests on my VO's because mapping actual models is an interesting idea. I have no idea on what type of app I'd use it though, I was just curious if it could be done. It did. It also created the problem of additional public properties when send back to the AMF gateway. You can imagine what happens when models compose each other. you'd create a forest of public properties that have contextual values, so it's a one way street it seems. For most of my apps, one way streets are about as usefull as dead ends.

    Off course I don't know what error your code threw, but I do know that conceptually, it raises more problems then it fixes solutions when thrown into a server-client environment. Storing VO's in a model and dispatching framework events from there (or the Command, whatever floats your boat) works wonders, and you can concentrate on actual application logic straight away while your VO's remain simple classes.

    Lets us know how you fair with RL!

  6. Stray closed this discussion on 08 Jun, 2011 09:59 AM.

Comments are currently closed for this discussion. You can start a new one.

Keyboard shortcuts


? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac