From Ajax Patterns
|Revision as of 16:36, 22 July 2012
18.104.22.168 (Talk | contribs)
Some research results...
← Previous diff
22.214.171.124 (Talk | contribs)
|Line 32:||Line 32:|
|= Real-World Examples =||= Real-World Examples =|
|== NumSum ==||== NumSum ==|
|The Ajax spreadsheet NumSum, continuously recalculates cell values, using [[Pseudo-Multithreading]].||The Ajax spreadsheet NumSum, continuously recalculates cell values, using [[Pseudo-Multithreading]].|
This a stub page for a pattern about pseudo-multithreading. Please enhance it if you know more about this pattern.
- Most Ajax Apps accept user input.
- Some Ajax Apps require complex processing in the browser. If the thread of execution is busy performing such processing, users won't be able to perform input.
- Many times code must pause to wait for asyncronous event (remote call, user interaction, or timeout) to finish, which setups pseudo alternative lines of execution.
Using Scheduling, a processing function is called once in a while, incrementally processes a bit more of the problem, before yielding. Instead of solving the entire problem at once and returning, the function maintains a "blackboard" object and continuously works on it until the problem has been solved. This "blackboard" object is optional and may be something that forms the eventual solution, or just a copy of the original problem and an indication of what to do next.
For example, imagine you're implementing a Portlet, a real estate advertisement providing a mortgage rate calculation. The calculation requires you to run a simulation, calculating the value at the end of each day for a year - a loop of 365 calculations. If you do it all at once, the user won't be able to do anything during that long period. So instead, you break it into chunks of 10 days at a time. At the end of the first chunk, the blackboard indicates the situation after 10 days. At the end of the second chunk, the blackboard indicates the situation after 20 days. At some point, it will reach its target, 365 days, at which point it will probably call a callback function or just handle the result directly, e.g. paint the result on the user-interface.
It's convenient to handle this in an object-oriented fashion, where the blackboard data and the processing function belong to the same object. The object is basically a Strategy or Command object (Gamma et al) - it has a "run()" method that does a little bit of processing, and sets values as attributes of itself. In the above example, we have a Calculator object with a run() function that performs the 10-day simulation. calculator.run() begins by reading the daysSoFar attribute, calculator.daysSoFar and the valueSoFar value, calculator.valueSoFar. It then simulates the next 10 days, and updates those attributes. Calculator might also include additional attributes too, such as: the number of days to simulate per run() invocation; the completion condition (which could be a function itself, or just a value such as number of days); a callback function to call upon completion.
Alternatively JWACS provides similar continuations capabilities.
"Thin Client" Ajax Apps delegate any complex processing to the server. Probably more network and server overhead, but less CPU cycles devoted to processing and more to user input.
(TODO Patterns like Live Search, Portlet, and Live Form should point here.)
The Ajax spreadsheet NumSum, continuously recalculates cell values, using Pseudo-Multithreading.