Loading data for a specific view instance?

Shawn's Avatar

Shawn

13 Jun, 2011 09:12 PM

Hey guys.

I'm wondering what the recommended approach is for loading data from a service, and injecting that into a specific view instance, which may, or may not be still on the stage when the load completes. If the instance ever does happen to land back on the stage, it should contain the data that was previously fetched.

Use case:
- User clicks a button and the app puts a "commentView" on stage, and starts a service call to fetch data for that view. - Before the service has completed, the user clicks another button, a new commentsView is added to stage, and the old commentsView is removed. A new service call is started to load the 2nd set of comments data. - At this point 2 service calls are running, lets say they both complete. Call #1 should be injected into view #1, #2 should be injected into the view#2.

Solutions i'm humming and hawing over:

  1. In the payload for the LoadCommentsCommand, I can pass the current view. The command can load the service, and inject the data directly into the view. Essentially bypassing the mediator.
  2. Have a bunch of CommentsData instances, mapped by the view instance. When the model is changed, it can include the view instance in it's CHANGE event, and a mediator can check event.view to see whether this is data for it's view. (When landing on stage, mediator would also request the model for it's view in case it's already been loaded)

Number 1 is attractive since it's easy, but it sort of breaks the mediator paradigm.
Number 2 seems clean. Is there a better way?

Basically, it comes down to mapping of a service call, to a view instance, and the best way to achieve that.

  1. 1 Posted by Shawn on 13 Jun, 2011 09:12 PM

    Shawn's Avatar

    Ugh, my formatting got massacred...

  2. Support Staff 2 Posted by Stray on 13 Jun, 2011 09:20 PM

    Stray's Avatar

    I fixed your formatting :)

    So... one option is simply to put false for the autoRemove parameter for this mediator mapping.

    Stray

  3. Support Staff 3 Posted by Stray on 13 Jun, 2011 09:22 PM

    Stray's Avatar

    Actually, on top of that I would combine it with a request-response pattern of signals - where you pass a signal to be used for the response, so you don't have to mess about with ids and such on your responses.

    If you're interested in that approach then if you search for request and response in this forum you'll find a few discussions of it.

    Stray

  4. 4 Posted by Shawn on 13 Jun, 2011 09:29 PM

    Shawn's Avatar

    Thanks Stray!

    I don't think that wouldn't fix the problem, as then we would just have both mediators picking up the event. So both views would end up with data from Service Call 2. I want the proper view to end up with the proper data.
    (Not to mention, the app is basically one big view stack, views are added/removed at the user's will, and it has a "Back" button. So that would mean essentially disabling autoRemove for every view)

    Either way, I need to pass the view to the command right? I don't see anyway to avoid this...

    I have to pass the view to the command, and when the service completes, the command needs to update the model, and pass the view in, so the model can map view > data.

    Also, I don't see anyway I can do this without having my command listen to the service directly...is there a design pattern I'm just missing?

  5. 5 Posted by Shawn on 13 Jun, 2011 09:32 PM

    Shawn's Avatar

    Could you expand on the signals approach? I've never used signals. (I can't switch this project to signals, we're stuck with events, but maybe the general approach would work?)

    Would this be essentially passing a callback to the Command, so when the service has completed, it just calls the callback? And this callback would be view.setData() or something?

  6. 6 Posted by Stray on 13 Jun, 2011 09:54 PM

    Stray's Avatar

    Hi Shaun, no problem,

    You'd need to put an ID on the mediator obviously and have each mediator filter which call backs it responds to based on whether the ID matches its ID.

    I wasn't clear from your question how many of these things there are - I'm not talking about disabling autoRemove for all views, just for the class that the comments need to be fed back into.

    Like I said - if you search around request/response+signal on the forum you'll get quite a few hits.

    Signals isn't a 'switch' really - it's just a library, most people use them in combination with events. It's no different to adding TweenLite or something similar to your project.

    So, yes - basically signals are kind of like callbacks but with intelligent error checking so you can't send something that hasn't been expected and you can do 'addOnce' so that the callback is unwired as soon as it has been used.

    The other option would be a Promise. Check out Shaun's oil utils repository on github.

    And finally, you could maintain a history by view reference, and just request the latest data when the mediator does onRegister.

    All of these should be viable solutions.

    Stray

  7. 7 Posted by Shawn on 13 Jun, 2011 10:06 PM

    Shawn's Avatar

    Ok, cool I'll look into Promise, and see how that might fit the bill. I see what you mean about signals not being all-in or all-out.

    Regarding mediator id, well that is sorta the crux of the issue, seems like the id needs to be the view instance...

    I "get" the history mapping approach, I'm a little less clear on how this would work with a promise.

  8. Support Staff 8 Posted by Ondina D.F. on 01 Nov, 2011 02:27 PM

    Ondina D.F.'s Avatar

    Thank you for posting.
    Feel free to reopen this discussion if you feel the answer(s) to be dis-satisfactory or if you need more help with this issue, otherwise we'll consider the thread closed. Please open new threads for new issues.
    Ondina

  9. Ondina D.F. closed this discussion on 01 Nov, 2011 02:27 PM.

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