Advice needed on manipulating store data

[jcamozzi]

Hi All -

I'm still pretty new to ExtJs 4 and I'm trying to get a feel for where and how to manipulate data. Currently I have an example running that pulls issues from an issue tracker (jira) and displays the results in a grid. I have a general understanding of Models and Stores, but now I'm trying to do the following:

Pull all data from the store
Aggregate the data to get specific information, such as the following:

Total estimated hours for the issues returned
Estimated hours remaining of work
Breakdown of issues per assignee
Breakdown of estimates per issue
etc.

Use various form controls to manipulate this data for different scenarios
Now, I'm not asking for help on the "how to do all of the above" but rather, I'm seeking advice on where best to DO this work. Do I:
Put code in the "load" function of the store to aggregate / prepare the data?
Add a function to the model (seems wrong, as I think a model in this context is a single record)
Create a controller and add logic to aggregate after the store loads?
There seem to be many places I can do this, but I'm trying to figure the "best" place. Whatever the results of the aggregation I will need to store data somewhere. It could be that I'm actually manipulating the data (i.e. adding extra fields) or even needing a separate "store" for the new data to go to.

In theory I suppose I can also do the manipulations "on the fly" based on some kind of "process" button. That would lead me to think I should do it in the controller.

Has anyone needed to do something similar? Any thoughts / advice on the best place to put such aggregation code?

Thanks in advance!

-Jeff

[arthurakay]

My first thought is to ask if you've seen the "grouping" and "summary" features of the ExtJS grids:
- http://docs.sencha.com/ext-js/4-0/#!/api/Ext.grid.feature.GroupingSummary
- http://docs.sencha.com/ext-js/4-0/#!/api/Ext.grid.feature.Summary

I don't know if those offer help in your situation or not.

But to answer your question... (assuming the grouping/summary don't solve the problem at hand)

I would personally choose to do much of this work in the Controller. My opinion is that most of your application logic should reside in the Controller... and that views and models are (for the most part) dumb.

I don't know if there is a "right" or "best" answer - every application is different.

[jcamozzi]

Thanks Aurthur.

I think I want to do this calculation separate from the grid. The grid was really for me to "get my feet wet" on pulling json data. So the thing is that I want to do a significant amount of data manipulation (more so than I listed). Basically I want to create a whole new data set that I can use to do my calculations with. So if I process this data in the controller, where do I save it? Is it prudent / customary to manually save data into another store (like using a memory proxy or local storage proxy)? Would I just load one from the controller, then save the data to another? I imagine my new data set may be quite complex so I'm not certain this is best.

One other thought I had was to do all the processing on the PHP side. Currently I "wrap" the REST calls to jira in a small PHP script (to make up for limitations in their REST api). I could manipulate the JSON returned so that it provides the aggregation there instead of me doing it on the ExtJs side.

Maybe for now I'll focus on trying things in the controller. If you have any other thoughts I'd appreciate it.

Thanks!

[arthurakay]

So knowing a bit more about what you're trying to do... I think you are better served processing the data on the server. It will be faster, and IMO the client's job is to display/edit data - not to completely reformat it for arbitrary local calculations as you describe.

With regards to your data store, the ExtJS Store class isn't designed to handle things that way (as you've noticed). You certainly can hack the edited data into a separate store... But as I said above, it makes more sense to have a server-side controller handle your data manipulation. The API would be infinitely more clear.

[jcamozzi]

I think I have the idea now on the approaches to try out. Thanks for all your advice Aurther. Now.. how do I mark a thread as "answered?"