FDS2: default refreshFill() behaviour
To test this I used the CRM sample that ships with FDS.
Problem: An arraycollection that had previously been fill()'ed using query parameters would not update if CreateItem() was called. If no query parameters were used it worked fine. UpdateItem() and DeleteItem() worked fine as well.
Solution: If you DO NOT implement your own refreshFill() in your custom Assembler class, then the default behavior of refreshFill() might be the cause of the problem.
The refreshFill() method proactively queries on whether or not data needs to be pushed out to clients. It checks to see if the newly created record would fall within the query parameters of the LAST Fill() requested.
Example: Let's say you retrieve all Roles for System ID 12 - this creates a unique fill situation for your flex app/session. DataService1.fill(roles, "12")
Let's say Jim, another user, is currently viewing all Roles for System ID 8 - he too has his own unique fill situation. DataService1.fill(roles,"8")
Now you go and add a new Role for System ID 8. Here's what happens:
FDS recognizes the fact that you are not currently looking at a list that would include this record... so you get no update (DO_NOT_EXECUTE_FILL)
FDS also 'knows' that Jim is looking at a list that should be updated, so it pushes out an update to him, EXECUTE_FILL
This keeps updates pushed out to a minimum I guess.
To test: in CRM project modify the CompanyAssembler by commenting out the RefreshFill() method completely. Run CompanyApp.mxml in debug mode with a breakpoint in companyResultHandler(). Change industry to filter by health care, add a new record with a different industry. When breakpoint kicks in, check the companies arraycollection... you should NOT see your recently added company.
No comments:
Post a Comment