tag:robotlegs.tenderapp.com,2009-10-18:/discussions/problems/329-structure-and-pattern-for-eventsRobotlegs: Discussion 2018-10-18T16:35:28Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/76827972011-06-06T18:46:41Z2011-06-06T18:46:41Zstructure and pattern for events<div><p>Hi Enrique,</p>
<p>I tend to ask the question "who owns this event?" and then use
the answer to determine where I want to put the event.</p>
<p>Sometimes an event is specific to a type of service - in which
case putting that event inside the services package (or the
services package within that feature package) seems like a good
idea.</p>
<p>However - if you have cross-feature events, and you're using
the</p>
<pre>
<code>feature
api
restricted</code>
</pre>
<p>structure, then you need any events which are going to be used
within another feature to be inside the api package and not the
restricted package.</p>
<p>I tend to use this set up, so my events generally end up in the
api package by feature, and if there is much in that package then
I'll sub package them however I think best describes the dichotomy.
Perhaps just in an <code>events</code> package, or perhaps in
`events / flow' etc.</p>
<p>In the end, the first function of packages is to help the
developer understand the relationships between the classes in the
application. Any method that makes sense is viable IMO.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/76827972011-06-10T16:27:17Z2011-06-10T16:27:18Zstructure and pattern for events<div><p>Hi @Stray, I was thinking in your suggestion, but I think I
can't get it :(<br>
I feel that I'm duplicating classes, or making a real spaghetti,
maybe with an example is easier:</p>
<p>I have an event <code>ProductEvent</code> with a type
<code>GET</code>, this event is saved in root / [events] folder.
When I dispatch <code>ProductEvent.GET</code> a command is executed
and get productos from a service.</p>
<p>Then the command updates the model, and the model dispatch
another event: <code>ProductModelEvent.UPDATED</code>, I'm saving
ProductModelEvent inside [model] / [events].</p>
<p>Then the user can change something in the view, and I need to
update the model too. I need to dispatch an event from my mediator
with the <code>ProductVO</code>, and that event should execute a
command which updates the model.<br>
But what is this event?.<br>
a <code>ViewEvent</code>? [view] / [events] because is dispatched
from mediator...<br>
a <code>ModelEvent</code>? [model] / [events] because is updating
the model, and my ModelEvent has a "ProductVO" in it (as load).<br>
a <code>CommandEvent</code>? [events] because it executes a command
and is similar to GET data.</p>
<p>If I choose ViewEvent I feel that I'm messing the things,
because I'm using ViewEvents for events dispatched from the view to
the mediator.</p>
<p>If I choose ModelEvent I feel that I'm messing the things,
because I'm using the ModelEvents for events dispatched from the
model.</p>
<p>If I choose CommandEvent (<code>ProductEvent</code>) then I need
to add a load data to that event, that is not needed for example in
<code>ProductEvent.GET</code>. So it feels like those events are
not of the same class...<br>
And the data load that I need to add is the same data load that
have my ModelEvent ( <code>ProductModelEvent</code> ). So it feels
like I'm repeating myself.</p>
<p>And if I create a new CommandEvent, I feel that I will end with
thousands of event classes with probably just one type.<br>
Even more, I don't know what name to use for that "new" event,
ProductEvent2 ?</p>
<p>Can you help to clear this mess? :(</p></div>Enriquetag:robotlegs.tenderapp.com,2009-10-18:Comment/76827972011-06-10T20:25:14Z2011-06-10T20:25:41Zstructure and pattern for events<div><p>Hi Enrique,</p>
<p>I think first of all it would help to be more descriptive in
naming your events.</p>
<p>eg: Not <code>ProductModelEvent</code>, but
<code>ProductUpdateEvent</code></p>
<p>Then I would choose names such as</p>
<p><code>ProductRequestEvent</code> (has no payload) and<br>
<code>ProductCreatedEvent</code> (when the data comes back from the
service - containing the payload of the data.)</p>
<p>It's ok to have a lot of different events. And the package you
end up putting them in <em>doesn't really matter</em>.</p>
<p>For myself - unless an Event is very clearly
<strong><em>only</em></strong> for use in/by the view, or is very
specific to the model or service that fires it, I just stick them
in my controller package - not within model, view or service.</p>
<p>If the nature of the Event is really different then I think it's
better to have a new event than to make one event serve two
purposes. The flash.events events are all messed up IMO.</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/76827972011-06-10T22:24:12Z2011-06-10T22:24:13Zstructure and pattern for events<div><p>really? it's OK if I have a lot of different Event classes? I
mean, do you have a lot of Event classes with just one string
constant inside that class?</p>
<p>I don't know, maybe there's nothing wrong with having a
different class for each type of event. But I don't know, DRY is
surrounding my mine...</p>
<p><strong>this is what I have now:</strong><br>
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////<br>
<code>src / events / ProductEvent</code><br>
types:<br>
GET: dispatched by mediator executes command for retrieving data
from the service (I'm listening the result in my command with a
promise).<br>
EDIT: dispatched by mediator executes command for editing model
with local data.<br>
data load: Array (used only in EDIT)</p>
<p><code>src / model / ProductModelEvent</code> types:<br>
UPDATED: dispatched by model when data is setted<br>
EDITED: dispatched by model when data is edited<br>
data load: Array</p>
<p><strong>is your suggestion to change that to this?:</strong><br>
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////<br>
<code>src / events / ProductRequestEvent</code> type:<br>
REQUEST dispatched from mediator, executes command and retrieve
data from service<br>
data load: none</p>
<p><code>src / events / ProductEditEvent</code> type:<br>
EDIT dispatched from mediator, executes command and edit model<br>
data load: Array</p>
<p>// this is not changed:</p>
<p><code>src / model / ProductModelEvent</code> types:<br>
UPDATED: dispatched by model when data is setted<br>
EDITED: dispatched by model when data is edited<br>
data load: Array</p>
<p>
/////////////////////////////////////////////////////////////////////////////////////////////////////////////////</p>
<p>I just one to find some type of pattern or convention, so I
don't need to think everytime if I need to write a new event, and
how should it be called, and where should I save it (package),
etc.<br>
And also if in a few days I need to find an Event I know where to
search, and what name to search (approximately at least).<br>
More if I need to work in a team.</p></div>Enriquetag:robotlegs.tenderapp.com,2009-10-18:Comment/76827972011-06-11T09:40:34Z2011-06-11T09:40:34Zstructure and pattern for events<div><p>Hi Enrique,</p>
<p>I have hundreds of events in my larger projects. An event
represents a change in state / user action / application incident
etc.</p>
<p>Adobe gave us the rather rubbish String based event system. Many
of us don't really trust this approach (where you can accidentally
have two events with the same name) and so the Robotlegs event
system is built on strong typed events.</p>
<p>This means that the event class is the most important indicator
of the purpose of an event, and then the String
<code>Event.SOMETHING_HAPPENED</code> constants are sub-divisions
of that event class.</p>
<p>Naming events is hard - it will never be easy, so I'd just go
with the most descriptive names you can think of, and make sure you
have good refactoring tools :)</p>
<p>My own naming-refactoring policy is that if I accidentally type
or think something different from what I've currently named the
variable, class or function, often this is a good indicator to
change its name.</p>
<p>For example - yesterday I was writing some code for a mosaic
application. I had <code>TileView</code> and one of the parameters
was <code>dimensions:Number</code>. Then in my tests I
automatically started writing <code>tileSize</code> instead of
<code>dimensions</code> and I realised that this was a better
description.</p>
<p>I would still rename <code>ProductModelEvent</code> to
<code>ProductUpdateEvent</code> - and also there's a convention
that your type constants should be in past tense, so I would go
with:</p>
<pre>
<code>ProductRequestEvent.PRODUCT_REQUESTED
ProductEditEvent.PRODUCT_EDITED</code>
</pre>
<p>Because these read like real conversation and less like
code.</p>
<p>But that's just my preference.</p>
<p>In terms of where to put them, if you are worried about it then
I would just put all your events in packages like this:</p>
<pre>
<code>com/project/controller/events/product
com/project/controller/events/startup
com/project/controller/events/... etc</code>
</pre>
<p>This way if someone is looking for them then they are only going
to be moving between one layer of folders.</p>
<p>HTH</p>
<p>Stray</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/76827972011-06-11T15:11:24Z2011-06-11T15:11:24Zstructure and pattern for events<div><p>Well, maybe I need to be less paranoid and to lose my fear about
having hundreds of classes with just one type of event inside
it.</p>
<p>About using Past Tense, I was using irregular verbs for noting
that an action is not made yet, if I follow your Past Tense rule
the I have two events with the same name:</p>
<p>I need to convert this:<br>
<code>ProductEvent.EDIT</code> (execute command for editing
model)<br>
<code>ProductModelEvent.EDITED</code> (dispatched by model after
edition)<br>
to just this?<br>
<code>ProductEditEvent.PRODUCT_EDITED</code></p>
<p>I think to have the events in the same folder is better (and
make the separation with subfolders there).<br>
I just started in the other way because this article:<br>
<a href=
"http://knowledge.robotlegs.org/kb/reference-mvcs-implementation/robotlegs-mvcs-folder-structure">
http://knowledge.robotlegs.org/kb/reference-mvcs-implementation/rob...</a><br>
Maybe we need to change that :(</p>
<p>Thanks @Stray !</p></div>Enriquetag:robotlegs.tenderapp.com,2009-10-18:Comment/76827972011-09-04T18:12:19Z2011-09-04T18:12:19Zstructure and pattern for events<div><p>Hello,</p>
<p>I think that it is better to put all the events in one folder. I
mean, of course, you can create sub-directories for better
organization but to store them in one place. For me, the good named
event is better then the good file path (i.e. ProductsActionsEvent
looks better then
com.project.services.products.events.ActionEvent). Of course we
can't generalize and just say what is right or wrong. It's more
like a personal choice and project specifics. Usually my events are
stored in com.project.controllers.events.<br>
Sometimes I prefer to add an additional parameter to the
constructor of the class. For example:<br>
public class ProductEvent(type:String, data:* = null) { ...<br>
So if you have an event ProductEvent.GET you will discard the data
parameter. If you have an event ProductEvent.UPDATED then you will
use the "data" to send the updated information. Using that method
you will not need to create a new event for every action. It just
depends on your project. The workflow described above is not always
useful. Sometimes is really wrong. Especially if you mix the
responsibilities of your classes ;)</p></div>krasimirtag:robotlegs.tenderapp.com,2009-10-18:Comment/76827972011-09-04T22:55:30Z2011-09-04T22:55:30Zstructure and pattern for events<div><blockquote>
<p>I think that it is better to put all the events in one
folder</p>
</blockquote>
<p>I disagree with this. I've seen what this approach leads to, and
it is never pretty in a non-trivial app. I want my events (and all
of my classes really) as close to their owner as possible. Events
that are part of the model (announcing changes to the model) BELONG
to the model, and not to the feature. The length of the
package/namespace is completely aesthetic. If it is long because it
is descriptive of where the event is owned, I favor clarity of
looks every time.</p>
<p>I'm a strident single TYPE event class user. Allowing
arbitrary/optional arguments leads to conditional logic leads to
muddled code and complete disregard for SRP. Event classes become
dumping grounds for any marginally related behavior. I don't have a
problem with many classes as much as I have a problem with classes
that have too much responsibility or are not easily describable in
terms of the behaviors they express. I don't want "this event is
dispatch when something happens to x" - I want "this event is
dispatched when z happens to x" - specificity. mmm</p>
<p>So I end up putting the <em>events</em> package in the
model/view/controller/service packages and evaluate where the event
should be owned. It prevents the MONOLITHIC event packages that are
hard to understand and provides clear cognitive separation between
the events in a given functional area.</p></div>Joel Hookstag:robotlegs.tenderapp.com,2009-10-18:Comment/76827972011-09-07T06:53:05Z2011-09-07T06:53:05Zstructure and pattern for events<div><p>Hi Joel, good points. I'll use your advice in my next project
;)</p></div>krasimirtag:robotlegs.tenderapp.com,2009-10-18:Comment/76827972011-09-09T01:44:14Z2011-09-09T01:44:14Zstructure and pattern for events<div><p>I jumped back and forth between placing all events in one
package and placing them with their owner. After reading Stray's
and Joel's book, I am fully convinced they should be placed with
their owners. I am currently planning the package structure for a
very large project, I will be using a events to their owner
approach. My 2 cents</p></div>visnik