Should data access always be in a Proxy or are there exceptions?

[jpwrunyan]

I have a challenging view implementation to convert into the PureMVC architecture.  First I will describe the specifications and then get into what my problem is and then address why I am now asking myself the above question.

Requirements and background:

1 The view class shows a scatter plot of identical icons.
2 Each icon is linked to a set of images that are updated on the server in real time.
3 When the user moves the mouse over an icon, a small panel "tool tip" with a thumbnail image appears (via Image.source = url).  The thumbnail url is static, but its image on the server gets overwritten periodically.  This is nice.
4 When the user clicks the icon, the thumbnail "tool tip" gets tacked down, enlarged, and remains visible even when the user moves the mouse away from the icon.
5 If the user moves the mouse over an icon whose "tool tip" has been tacked down as above, then the tacked down panel simply gets highlighted (ie, it doesn't display a second tool tip).
6 When a "tool tip" has been tacked down buttons appear in the panel allowing the user to display images previous to the most current one.  These images are *not* the thumbnail.
7 All tacked down "tool tips" should poll the server for the updated list of image urls for that icon.  These image urls are cycled through by the user and their image displayed in the tacked down "tool tip".  These images on the server are not updated.  Only the list of urls to be cycled through is.  This is not nice.

The data model consists of a master xml list that simply gives information for the scatter plot.  Inside the master list is a url pointing to the thumbnail image as well as a url pointing to another xml file containing information about the list of viewable images for that icon (necessary for cycling through past images when the user interacts with a tacked down "tool tip").

eg:

:

<master>
  <icon>
    <thumbnail>www.mydomain.com/imageId/thumbnail.jpg</thumbnail>
    <imageList>www.mydomain.com/imageId/imageList.xml</thumbnail>
    <!-- and additional assorted data for the scatter plot -->
  </icon>
  ...
</master>
and

:

<!-- www.mydomain.com/imageId/imageList.xml -->
<!-- this content is constantly changing -->
<imageList>
  <image index="1" filename="11.jpg" time="2010/01/01 10:10" />
  <image index="2" filename="14.jpg" time="2010/01/01 10:17" />
  <image index="3" filename="01.jpg" time="2010/01/01 10:21" />
  <!-- and more, of variable length -->
</imageList>

The master.xml file is loaded once at application start.  However, imageList.xml updates constantly.
Performance issues mandate that I only query and poll imageList.xml files when there is a tacked down tool tip that requires it (remember, when an icon is hovered over, the thumbnail image url will do).  I cannot simply get all the data all at once constantly.  The previous programmer addressed this problem by having a URLLoader inside the "tool tip" panel class.  The panel and its parent view component both know whether it is tacked down or not.  Each tool tip panel would do its own polling and handle its imageList.xml data on its own.  No proxies.  I have to say that as I am refactoring these classes, I am very tempted to do the same.  Which leads me to...

Why I am asking myself the question:

I cannot come up with a solution using proxies that does not make the implementation (in my mind) vastly more complicated than the previous programmer's approach.  How am I supposed to handle all these imageList.xml queries using proxies?  When the "tool tip" is tacked down, dispatch an event to the scatter plot view's mediator and then send a notification to do... what?  Register a new proxy for that piece of data, start a polling routine, and then send the result back to the scatter plot view's mediator?

icon (click event) > scatter plot (tacks down "tool tip" panel, sends icon click event) > mediator (sends notification) > command logic registers imageList proxy > imageList proxy onRegister() starts url loader server request > url loader receives server result (event) > imageList proxy sets its data to URLLoader result (sends notification) > mediator (handles notification, proxy data is in body) > scatter plot (sets previously tacked down toolTip's imageList property to received data) > toolTip shows updated images when user interacts with it

This seems like a very complicated chain to achieve the same result as what was previously just a simple implementation in the "tool tip" panel's logic.  Let alone the rigamarole I have waiting when the user closes a tacked down "tool tip" and I have to then unregister its imageList proxy.

And finally, when the component programmer is making these classes, how on earth is he going to be able to implement and test functionality with dummy data?  The above process seems to mandate that he also program with the framework logic in front of him (at least) if not actually running on his machine.  Up until now, I have been able to stipulate data setters for a view component, tell the component creator that when testing locally he just needs to plug in certain dummy data I provide and get the component to work sans mediator and sans PureMVC and then when he is finished I can plug it into my mediator source code and it works.  Can't have everything, I know, but still...

For these above reasons I am doubtful about using a proxy for all data interactions.  Maybe there are exceptions?  At least in this case I don't know what to do.  One option is anti-PureMVC pattern.  The other is a convoluted mess.  That said, I am leaning toward prioritizing simple implementation over correct implementation.  Please tell me I am wrong and that I can have both.

I appreciate any suggestions and feedback.

[puremvc]

The encapsulation of this functionality into the component itself seems reasonable in this case. A view component can be as intelligent as it needs to be in order to encapsulate the functionality it needs to exhibit. There is always a balance to be struck between allowing PureMVC to help you not make spaghetti of your code and going to great lengths to implement every use case using the framework and ending up with spaghetti.

Consider the case of taking a complex third-party mapping component and adapting it to your application. Lets say it does something very similar to what you describe, but it's a black box. You just know that the files go on the server, and you give the component a URL and it goes to town. That component can still fit happily into a PureMVC application.

Here it is just that you have a choice of whether to implement everything as a bunch of PureMVC classes supporting the component, or to encapsulate. I try not to write monolithic classes of any type, view components included, but I'm also not afraid to encapsulate where it makes sense. If nothing else in the app needs to react to this information as it comes in then save yourself the hassle and encapsulate. Later if you need to query the component for some of the data it has retrieved on its own, just send it a note or expose a getter for the data on the mediator.

-=Cliff>

[jpwrunyan]

Thanks for the advice, Cliff.  I will indeed stick with the simple implementation in this case then and just make a note along the lines of what you said in the class descriptor.  Back in the day when I used Cairngorm there were times I broke the rules regarding view/helper classes because it made sense from an OOP perspective.  I guess this gave me pause because I perceived it as part of the model tier.

[puremvc]

I guess this gave me pause because I perceived it as part of the model tier.

That's pretty common. Just remember Server != Model.

Images get loaded from a server but they're not really part of the domain model data. Nor are the little XML config files that tell you which images to load. They may be directly related to the data, but can still be thought of as a view construct if they are read-only and the rest of the app doesn't really give a hoot about them.

-=Cliff>