Models between Services and Mediators

Bruce's Avatar

Bruce

07 Sep, 2012 08:36 PM

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.

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?

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?

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.

  1. 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?

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.

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?

  1. 1 Posted by neil on 08 Sep, 2012 08:43 AM

    neil's Avatar

    1a) yes, do that, I would try and avoid injecting models into mediators.

    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.

    hold on, family calls, back in a sec....

  2. 2 Posted by neil on 08 Sep, 2012 09:03 AM

    neil's Avatar

    1c) probably depends on whether you go for Presentation, ie two way binding data item <=> view renderer or mediation - sending Events via framework bus.

    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.

    any of that help?

  3. Support Staff 3 Posted by creynders on 10 Sep, 2012 07:35 AM

    creynders's Avatar

    1A First of all I'd advise you to think about the level of abstraction of your various actors:
    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.
    For instance my personal approach is the following: (let's say we're loading Twitter data, then I have the following setup)

    interface TwitterRetrievalService  
    class TwitterLoaderService implements TwitterRetrievalService  
    interface TwitterFeedParser  
    class TwitterJSONFeedParser implements TwitterFeedParser  
    interface TwitterFeedModel  
    class TwitterFeedModelImpl implements TwitterFeedModel  
    interface TwitterFeedView  
    class TwitterFeedPanel implements TwitterFeedView
    

    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.
    In the same vein my TwitterRetrievalService returns a TwitterRetrievalServiceResponseVO 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.

    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.

    3A I'd go for the following approach:
    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.
    The model dispatches an event which is picked up by the mediator, which in turn passes the payload (containing concrete objects) to the view.
    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.

  4. 4 Posted by neil on 10 Sep, 2012 08:52 AM

    neil's Avatar

    +1 @creynders if you haven't already check out presentation model: https://www.google.co.uk/search?q=robot+legs+presentation+model&amp...
    it might be more applicable to you.

  5. 5 Posted by Bruce on 10 Sep, 2012 01:03 PM

    Bruce's Avatar

    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)

    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 ...

    So, (1b) is wrong. I meant to say "Does the model being injected into the view mediator mean ..."

    @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?

    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.

    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?

    @neil, understood at 3B

    @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)

  6. 6 Posted by neil on 10 Sep, 2012 02:29 PM

    neil's Avatar

    @neil, why not inject models into mediators? no not wrong, but there are other ways that you should consider first.

    I would consider what relationship my data and view have. Each case would have a different implementation

    mediator to model comms would usually be through event/commands.
    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.

    BTW, I would prefer to have many classes with few LOC than fewer class with many.
    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.

    it may increase the initial set up time, but makes it far more open to change, and speeds up dev in the long term.

  7. Support Staff 7 Posted by creynders on 10 Sep, 2012 02:34 PM

    creynders's Avatar

    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 ...

    Roger. But obviously "best practices" and abstraction go hand-in-hand.

    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?

    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.
    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.

    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.
    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.

    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)

    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.

  8. Support Staff 8 Posted by creynders on 10 Sep, 2012 02:34 PM

    creynders's Avatar

    and what @neil said.

  9. 9 Posted by Shlapentokh5 on 11 Sep, 2012 05:25 AM

    Shlapentokh5's Avatar

    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=http://bruteforex.com]outdoor lighting manufacturers usa[/url]

  10. 10 Posted by neil on 11 Sep, 2012 06:35 AM

    neil's Avatar

    oh no getting spam!

  11. Support Staff 11 Posted by Ondina D.F. on 11 Sep, 2012 07:56 AM

    Ondina D.F.'s Avatar

    Hi guys,

    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.
    We are very sorry for the inconvenience, but we can’t do anything to prevent this.
    This situation is just as annoying for us as it is for you.
    Closing the discussion seems to be the only solution, sadly.

    So, Bruce, if you want to continue this discussion, you’ll have to re-open it.

    Ondina

  12. Ondina D.F. closed this discussion on 11 Sep, 2012 07:56 AM.

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

Keyboard shortcuts

Generic

? 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