tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/1040-models-between-services-and-mediatorsRobotlegs: Discussion 2012-09-14T07:09:38Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/185951512012-09-07T20:36:39Z2012-09-07T20:36:40ZModels between Services and Mediators<div><p>A couple questions about wiring up models and services. I have a
JAXRS endpoint that is spitting out JSON. The HTTP call has the
option of using URL parameters. I sometimes have to "massage" the
data before binding it to a view, but not always. I have thought
about it and think I have a couple questions at specific points in
the data flow.</p>
<p>1A. Assume I have a JSONService that generates a
JSONResponseEvent with the result in the payload. So, why even
inject a JSONModel into my JSONView mediator? Why not simply have
the JSONView listen for the a JSONResponseEvent that comes directly
from the JSONService and bypass the model?</p>
<p>1B. Does the model being injected into the view mean that I can
have the mediator make simply changes to the vies without having to
go outside those 3 objects?</p>
<p>1C. If however, the model does not have the "required" data
(perhaps we lazy load and it hasn't been asked for yet), even if my
JSONModel is injected into my JSONView mediator, I still need to
have the JSONView mediator catch a JSONModelUpdatedEvent so that it
knows the JSONModel is updated and the JSONView should be
"refreshed". Simply updating the data in the model is not enough to
refresh the view.</p>
<ol>
<li>Lets assume I am using a JSONModel and that it already contains
data. I instantiate a JSONView mediator in which the JSONModel is
injected. What is the proper way to get that data into the view?
Should the JSONView request the data from the mediator, which then
gets it from the model and after that it operates as I had just
made a JSONService call? Should the mediator bind the data when it
Regsiters?</li>
</ol>
<p>3A. Similarly, assume that my model already has data and its
already being displayed in the view. This time though the user
forces a refresh. I am thinking that my view mediator would "catch"
the refresh button click, could call a Model.refresh() method,
which would dispatch a JSONRequestEvent/Command with any URL
parameters I might want to pass in the JSONService that would
handle HTTP request.</p>
<p>3B. I suppose I could also have the view mediator bypass the
model and dispatch the JSONRequestEvent/Command directly. Is there
anything wrong with this approach?</p></div>Brucetag:robotlegs.tenderapp.com,2009-10-18:Comment/185951512012-09-08T08:43:11Z2012-09-08T08:43:11ZModels between Services and Mediators<div><p>1a) yes, do that, I would try and avoid injecting models into
mediators.</p>
<p>1b) if you are injecting into the view you want to think about
Presentation Model, and ditch the mediator. Don't put view logic in
mediator it should just act as a relay. If you want to modify view
response maybe create an Adaptor of some sort.</p>
<p>hold on, family calls, back in a sec....</p></div>neiltag:robotlegs.tenderapp.com,2009-10-18:Comment/185951512012-09-08T09:03:57Z2012-09-08T09:04:49ZModels between Services and Mediators<div><p>1c) probably depends on whether you go for Presentation, ie two
way binding data item <=> view renderer or mediation -
sending Events via framework bus.</p>
<p>3b) I would go straight to the command, as the Model should n't
care about refreshing. The JSONService will refresh, then as
requests return will update Model.</p>
<p>any of that help?</p></div>neiltag:robotlegs.tenderapp.com,2009-10-18:Comment/185951512012-09-10T07:35:16Z2012-09-10T07:37:10ZModels between Services and Mediators<div><p>1A First of all I'd advise you to think about the level of
abstraction of your various actors:<br>
Are you sure the model and the view need to be aware of the fact
that it's JSON coming in? They are more reusable if they do
not.<br>
For instance my personal approach is the following: (let's say
we're loading Twitter data, then I have the following setup)</p>
<pre>
<code>interface TwitterRetrievalService
class TwitterLoaderService implements TwitterRetrievalService
interface TwitterFeedParser
class TwitterJSONFeedParser implements TwitterFeedParser
interface TwitterFeedModel
class TwitterFeedModelImpl implements TwitterFeedModel
interface TwitterFeedView
class TwitterFeedPanel implements TwitterFeedView</code>
</pre>
<p>Since I leave the concrete incoming data type up to the feed
parser, it's very easy for me to change data type should that be
necessary. The service, model and view need not know in what format
the data comes in. It decouples them from each other and makes
everything far more flexible.<br>
In the same vein my <code>TwitterRetrievalService</code> returns a
<code>TwitterRetrievalServiceResponseVO</code> with a string value.
It's shouldn't care whether that string contains JSON or XML or
some other exotic format. Only the parser should.</p>
<p>The reason why views (most of the times) don't listen directly
to the service is because they shouldn't care whether the data is
loaded remotely, embedded in a class, or loaded from LocalStorage
for instance. Nor whether it has already been loaded or still is
loading.</p>
<p>3A I'd go for the following approach:<br>
the view dispatches an event picked up by the mediator, which
relays it to the system. This event triggers a command which calls
the appropriate service method. Once the service has done its
thing, it dispatches an event with the raw string data as a
payload, this triggers a command which passes the payload to the
parser and stores the result into the model.<br>
The model dispatches an event which is picked up by the mediator,
which in turn passes the payload (containing concrete objects) to
the view.<br>
This seems convoluted, but actually (once you get used to it and
have a proper IDE or code generator) goes pretty fast. And the
major advantage is that it keeps all of the actors wonderfully
ignorant of each other.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/185951512012-09-10T08:52:36Z2012-09-10T08:53:15ZModels between Services and Mediators<div><p>+1 @creynders if you haven't already check out presentation
model: <a href=
"https://www.google.co.uk/search?q=robot+legs+presentation+model&sugexp=chrome,mod=3&sourceid=chrome&ie=UTF-8">
https://www.google.co.uk/search?q=robot+legs+presentation+model&amp...</a><br>
it might be more applicable to you.</p></div>neiltag:robotlegs.tenderapp.com,2009-10-18:Comment/185951512012-09-10T13:03:59Z2012-09-10T13:04:02ZModels between Services and Mediators<div><p>Thanks all. I am noodling on it now. I want to implement best
practices, but I also don't want to go overboard and end up with 5
times as many classes as I really need (like I have seen in quite a
bit of Java code)</p>
<p>Yes, I could abstract out the JSON stuff, but at this point I am
trying to keep it a little simpler while I get my "robotlegs" under
me ...</p>
<p>So, (1b) is wrong. I meant to say "Does the model being injected
into the view mediator mean ..."</p>
<p>@neil, why not inject models into mediators? That seems to be
the common pattern I see. Are you saying you would rather have the
meditator capture a "data" event as its method of getting access to
data?</p>
<p>Yes, I agree. I don't think the view should care where the data
comes from. It should simply ask for data and the logic of how it
is fetched is somewhere else.</p>
<p>So, you seem to be saying that the flow of information is from
the model to the mediator. Are there cases where the flow of
information is from the mediator to the model? What if my view
wants some already existing model data to be"transformed"? Still
implement that as a command that goes to the system and then is
routed back to model?</p>
<p>@neil, understood at 3B</p>
<p>@creynders, your 3A response kind of backs up what I was
thinking would be the "by the book" answer. That's good. I have
read a lot over the last couple weeks and I often feel some of the
more common "use cases" are missing (or maybe I just havent put my
finger on them)</p></div>Brucetag:robotlegs.tenderapp.com,2009-10-18:Comment/185951512012-09-10T14:29:07Z2012-09-10T14:31:38ZModels between Services and Mediators<div><p>@neil, why not inject models into mediators? no not wrong, but
there are other ways that you should consider first.</p>
<p>I would consider what relationship my data and view have. Each
case would have a different implementation</p>
<p>mediator to model comms would usually be through
event/commands.<br>
if you have one point of access, then finding it is easy. if you
are calling a model from many places ( ie many mediators, other
commands, etc ) then it gets harder to find the call you want
(which is one reason not to inject, at least if you do, inject
against a partial interface.</p>
<p>BTW, I would prefer to have many classes with few LOC than fewer
class with many.<br>
while this may seem like a complication, it is in fact a
simplification of the class as a unit. it means that code can be
reused and understood far more easily.</p>
<p>it may increase the initial set up time, but makes it far more
open to change, and speeds up dev in the long term.</p></div>neiltag:robotlegs.tenderapp.com,2009-10-18:Comment/185951512012-09-10T14:34:26Z2012-09-10T14:34:26ZModels between Services and Mediators<div><blockquote>
<p>Yes, I could abstract out the JSON stuff, but at this point I am
trying to keep it a little simpler while I get my "robotlegs" under
me ...</p>
</blockquote>
<p>Roger. But obviously "best practices" and abstraction go
hand-in-hand.</p>
<blockquote>
<p>Are there cases where the flow of information is from the
mediator to the model? What if my view wants some already existing
model data to be"transformed"? Still implement that as a command
that goes to the system and then is routed back to model?</p>
</blockquote>
<p>Basically, yes. The command picks up the mediator's request,
fetches data from the model and/or updates the model with the data
sent through with the request, then delivers the (updated) data to
the mediator by dispatching an event.<br>
The same reasoning applies here: the mediator shouldn't care
whether anything happens with the data it sends through. Maybe it's
used, maybe not. Doesn't matter.</p>
<p>So let's say you want to view the details of a user with uid
value 5. We've got a view with a ComboBox with usernames as label
and uid's as data. The moment the user selects the user with uid 5
the view sends an event with the uid as a payload. The mediator
relays this event or dispatches another event, again with the uid
as a payload.<br>
The command is triggered which directly pulls the user details from
the UserListModel. It then dispatches an event with the user
details as payload, which in turn is picked up by the mediator,
which updates the view accordingly.</p>
<blockquote>
<p>I have read a lot over the last couple weeks and I often feel
some of the more common "use cases" are missing (or maybe I just
havent put my finger on them)</p>
</blockquote>
<p>There are many common use cases and many ways to solve them.
Personal style, but also project context will be deciding factors
to choose between approaches. For instance creating something which
will be deployed to many different platforms will determine your
approach from the get-go. It's always a balancing act between
having an "appropriate" level of abstraction/decoupling and being
pragmatic.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/185951512012-09-10T14:34:55Z2012-09-10T14:34:55ZModels between Services and Mediators<div><p>and what @neil said.</p></div>creynderstag:robotlegs.tenderapp.com,2009-10-18:Comment/185951512012-09-11T05:25:08Z2012-09-11T05:25:08ZModels between Services and Mediators<div><p>obviously like knowledge.robotlegs.org however you need to test
the spelling on several of your posts. A number of them are rife
with spelling problems and I to find it very troublesome to tell
the reality nevertheless I'll definitely come back again. wish you
luck, [url=<a href=
"http://bruteforex.com]outdoor">http://bruteforex.com]outdoor</a>
lighting manufacturers usa[/url]</p></div>Shlapentokh5tag:robotlegs.tenderapp.com,2009-10-18:Comment/185951512012-09-11T06:35:04Z2012-09-11T06:35:04ZModels between Services and Mediators<div><p>oh no getting spam!</p></div>neiltag:robotlegs.tenderapp.com,2009-10-18:Comment/185951512012-09-11T07:56:33Z2012-09-11T07:56:33ZModels between Services and Mediators<div><p>Hi guys,</p>
<p>We've been getting higher than usual amounts of spam email over
the last few weeks. From what I’ve heard, many forums hosting
sites are affected by this spam wave.<br>
We are very sorry for the inconvenience, but we can’t do
anything to prevent this.<br>
This situation is just as annoying for us as it is for you.<br>
Closing the discussion seems to be the only solution, sadly.</p>
<p>So, Bruce, if you want to continue this discussion, you’ll
have to re-open it.</p>
<p>Ondina</p></div>Ondina D.F.