Pull Frequency Parameters in MVC architecture

Question

Assume a simple SPA (Single-page application), maybe a dashboard and these basic conditions:

• The Model contains methods for accessing and displaying data;
• The View contains methods to load templates and apply model.data to template;
• The Controller manages the user commands;
• The Router handles the navigation;

In our example, we will make sure that the user can configure the dashboard to update itself every N seconds pulling new data from back-end (pullFrequency).

In which component is proper set up the pullFrequency parameter:

1. Model?
2. View?
3. Controller?
4. Router?
5. Somewhere else?

• user22815: I would not call this a "global" variable. It will only exist in one location, and really only one object (the one initiating the refresh) would need it anyway.
• kedoska: @JohnGaughan Initializer. good point. In this case, the choice may vary depending on whether I choose to put a button to begin the update, or if the update starts because the view fetches the data prior to rendering. is that correct?
• user22815: Possibly, but the distinction is slim at the abstract level. Either way, you have a single object responsible for requesting updates at a given frequency. Something has to create that object and possibly give it a message to start doing its task, but that is outside the scope of my original point that the frequency is not really global.
• kedoska: Updated the title to avoid confusion

Answer 1

Presumably the pullFrequency parameter is used client-side to set up the polling; if you're happy to restrict yourself to browsers that support HTML5 then the cleanest solution may be to have a sensible default in your page and if the user wants to update it, pop it in Local Storage ( see http://diveintohtml5.info/storage.html ). That way your main application can be completely oblivious to the setting - after all it's not relevant to anything server-side.

The downside of this approach is that it needs to be set separately on each device the user uses - but that's not necessarily bad, a user may want rapid refresh on his desktop with super-fast line, but much less on his tablet / phone when out on the move.

• kedoska: thanks for your reply. It is a solution and restrict to HTML5 might not be a problem. The point is, in that case, the components are not isolated, independent, and basically, they are not reusable modules (per external dependencies).