Thanks for the feedback Colin,We should make sure we remove this directory from the release, since we are not going to be using it. I can do that in the cleanup target, or simply remove the files from the svn entirely. What is your preference?
Other thoughts below. Colin Clark wrote:
Hi Laurel, I took a look at your preliminary primer code. Here are some comments:* I'm not sure you should parameterize all your Ajax request options like you have. Here's a question to ask yourself when parameterizing things: If someone were to change any of these options, would the code still work? For example, changing the type of request from POST to GET; wouldn't that just be wrong?
Good point. Just got carried away with the fun of parameterizing!
* It might be a better idea to chain Ajax requests asynchronously, rather than doing the requests synchronously in a loop. In some browsers, synchronous requests will cause things to lock until everything is done. To be more concrete, chaining Ajax requests will involve calling the prime() function in the success callback of the request.I like this idea. I do know from my testing that performing two asynchronous calls one right after the other caused my apache to fail/hang. The synchronous solution solved that problem. Will try out your idea next.
* You've certainly got the mechanics of making Ajax requests in place, but I'll be interested to see how you'll do the bigger picture stuff--deciding on how to represent "profiles" of stuff to build, etc.Michelle and I went through a list of ideas about what we might try to "prime" if we were to do it manually, and had concluded that a first step would be to simply recreate those profiles in the code by manually listing the module combinations. The two examples I used and checked in were not at all typical. I'm not exactly clear on the technique you described above, but we can talk about it later.* Your question about how to obtain the model: it seems to me that you can make a request to the Builder itself to get a model of all the available modules. Along with this, you'll probably want a separate model--perhaps defined in the component's options--to specify the list of "profiles" that will need to be built in order to prime the cache.
Minor, nitpicky details:* The primer() function should probably be named as a verb: prime(), maybe? * You need to run JSLint on this code: missing semicolons, whitespace issues, a few details. * Real minor: consider consistent use of quotation marks--use " or ' appropriately * You might want to name your button in the dom binder a bit more clearly--maybe "primeButton" instead of "initiatePrime," for example
Will address these immediately.
This is a good start, but I'm thinking that we probably won't have the primer in place for the Builder 1.1.2 release. I think that's probably fine for this release, it just means that we'll have to manually prime the cache. Thoughts?Colin On 14-Dec-09, at 9:48 PM, Laurel Williams wrote:Would really appreciate your eyes on http://issues.fluidproject.org/browse/FLUID-3399. I checked in further code today and it seems to work...just need to figure out how to populate the model. But any comments on the code and technique would be appreciated.Laurel--- Colin Clark Technical Lead, Fluid Project Adaptive Technology Resource Centre, University of Toronto http://fluidproject.org
<<attachment: laurel_williams.vcf>>
_______________________________________________________ fluid-work mailing list - [email protected] To unsubscribe, change settings or access archives, see http://fluidproject.org/mailman/listinfo/fluid-work
