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
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.
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?
Support Staff5 Posted by Stray on 11 May, 2011 08:30 AM
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
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.
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
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.