[Arp] Sugestion.

[Cortlandt Winters]

I'm probably wrong as I'm still not fluent in patterns. Most importantly I
haven't done any work with transactional databases where I imagine the
answer will probably be found, and I've yet to read arp's manual (hopefully
tonight).

So basically disregard anything I have to say:D. Regardless I'll offer my
opinion as it stands as grist for the mill. My instinct, based on my more
noodly development, is that the rule of thumb should be that events should
cary exactly enough information to cary state either forward or backwards in
a system. If querying needs to be done to fill that event with coordinates
or whatever, it should be filled in as available as the event travels
through the system, but I think the information should be encoded in the
event so that at the controler's level you can watch the system from the
events, write scripts that replicate real user events, and do multiple
levels of intelligent undo/redo's just by recording the events and playing
them either forward or backwards. I also think that multiple consumers is
potentially dangerous and is where different event types is usefull to
seperate. There being ephemeral events and state changing events. I think
the state changing events should have the data in them, ephemeral ones don't
need it as the state is assumed to be either unimportant or implicit.

I'm not sure whether Arp's view states are all ephemeral or not, but I
assume that there is usually important view state information like which tab
or item of something is selected that are often considered ephemeral, but
which I think are pretty important.

For example if you have multiple consumers in an asynchronous system, you
might consider ways to combine them and make their relationship fairly
ordered. Isn't the whole idea of mvc to order the producer consumer chain?
In addition to ordering their responsabilities one might need to order the
events themselves, timestamps would be a good candidate for basic event data
that go with some state changing events.

I realize that event data can be a headache to maintain. When the name of a
piece of event data is changed it can make you change code everywhere the
event passes, but if the events are proper objects, then you can use it's
constructors and getters setters to keep this from being any worse than any
other object in the system, and it would be at least as clear as when a
function's return values changed.

Anyway, for any trivia buffs. Feel free to teach me where I'm misguided
here, I'm just going from instinct. I promise to try to improve my
understanding of the patterns too, so I don't keep using the 3 sentence
versions of words forever. For all I know I've just described arp's design
and missed the point of the conversation entierly.

-Cort

> -----Original Message-----
> From: Arp-bounces at ariaware.com [mailto:Arp-bounces at ariaware.com]On
> Behalf Of Darron J. Schall
>
> Aral Balkan wrote:
>
> > Case in point: Multiple event consumers can respond differently to a
> > given event. Say, for example (I'm making this up now)... you have a
> > GetAddressBook event. The Controller is listening for it and maps it
> > to the GetAddressBookCommand which calls a remote method to receive
> > the contents of the address book. Let's say that the Command needs to
> > know which user's address book it needs to get (and lets say this is
> > the only bit of data required and is stored in a property
> called userId.)
> >
>
> I'll be happy to debate this more to come to the "most correct"
> conclusion.  What does everyone else think?  Obviosuly, there is no
> "this is the 1 true answer," but rather we can most likely come to
> agreement on what we like best.
>
> -d